Well, not saying i am total expert here either. I've done a bit of weird stuff like per user routing and so on but it's not like i deal with this on a regular basis. Still to my best knowledge the kernel doesn't care where a packet was received when sending a reply. It just goes by what the routing table says. The reply packets disappearing from eth0 as soon as the tunY default route is up imo underlines this. Also when you look into reverse path filtering you'll see that it deals with exactly such cases (seems it's not used by default in Devuan - Ubuntu for example does use it by default i think - otherwise OP would have to disable it to not have the kernel outright drop the incoming packets).

Sure but if his internal VPN server gets a connection from the internet that won't be from 192.168.x.0/24 or any kind of local address but a random WAN IP (which OP doesn't know beforehand so no chance to set a conventional route for it) and when the server attempts to answer the only route matching the destination IP will be the default route pointing at tunY.

It's a bit of a weird setup to actually have a need for routing based on source port (well, at least that's how i'd single out traffic originating from his internal VPN server) rather than destination IP but in this case i don't see how it could work otherwise. Well, i guess he might get away with source based routing also but in that case all traffic originating at eth0 (or rather it's IP) would get routed through eth0 (his normal internet connection). That might spare him the tagging of individual packets but it's not exactly (as i understand it) what he is asking for and imo it wouldn't be all that much simpler.

Well, it's not 100% sure but it pretty much implies that the routing "works". Sadly not "works" as in does what you but rather does what it says though. I am quite certain the missing replies aren't really missing but just exit on the wrong interface as the default route that's in place when you remove route-nopull tells them. I guess you could see them when point tcpdump to tunY rather than eth0. That's basically what i was aiming at with the custom routing table but it seems that didn't work for some reason. I am quite sure that would be the way to go though.

could you post outputs of the following commands

ip route show table isp

ip rule show

iptables -vnL

iptables -t mangle -vnL

before and after running

iptables -A PREROUTING -i eth0 -t mangle -p udp --sport [YOUR-INTERNAL-VPN-SERVER-PORT] -j MARK --set-mark 1
ip rule add fwmark 1 table isp
ip route add default via 192.168.x.1 dev eth0 table isp

I know this is going to be a lot of output but i am trying to wrap my head around where it could go wrong and it's nothing i can easily test locally. Also your internal OpenVPN server uses UDP and when looking at tcpdump it's reply packets used [YOUR-INTERNAL-VPN-SERVER-PORT] as source port, right? Otherwise the iptables rule that should mark the packets would be wrong.

Kinda funny how such a mostly cosmetic change draws so much attention

I've looked into this and found absolutely nothing. Even the KVM related wiki pages only talk about being able to mount a remote ISOs using CIFS and cloud documentation just seems to go on about selecting an ISO from the list. No mention of any upload option. I guess this doesn't exist after all but it it does some kind of pointer would be neat.

Edit: Thinking about this i'll just ask Hetzner if they can add Ascii. I need to get off the PC and make some jelly before my cherries go bad. No point in wasting time with all this grumpyness

Well, tbh i have a bit of an aversion to making support requests for stuff i don't actively use but i figure i'll probably want to move my legacy VPS to their cloud at some point so i guess that justifies it. I'll write them later. It's probably not going to get answered during the weekend anyways.

OK, so after working my way through the setup here is a couple of screenshots (sorry about those being in german - i don't know how to switch the panel to english but there is an international version i am sure) and some notes:

After creating the VM which allows just a handful of operating systems (i choose Debian 9 but i don't think it matters) you have something like this:

If you click the servername there you'll get an overview like this:

From there you select 'Power':

and shut the VM down (it's labeled 'Herunterfahren' here) but i guess since we don't care about a clean shutdown 'Power Off' would equally work. Now you can select ISO-Images and mount ('Einbinden') Devuan Jessie netinst (it's even on the first page, nice!):

Now turn the VM on again (using 'Power') and and go to the server menu to launch the web console (labeled 'Konsole' here):

You should be greeted by the Devuan installer asking to select graphical or text install. I choose text which likely doesn't matter again but as the installation has some quirks it might be the better option. Speaking of quirks, this is what i encountered during the actual installation:

After detecting the network the installer complains about not being able to detect the default gateway. This can be easily fixed by following the instructions in Hetzners wiki at https://wiki.hetzner.de/index.php/Cloud … Gateway/en. Basically you hit ALT + cursor right to get to a shell then enter the following commands:

ip r ad 172.31.1.1 dev eth0
ip r ad default via 172.31.1.1

To switch back use ALT + cursor left. Choose to continue without the gateway (not really true since we have just configured it). The setup then asks for a nameserver which can be found at https://wiki.hetzner.de/index.php/Hetzn … _Server/en. I've just used the first one.

When it came to selecting a HTTP mirror there was something i am not entirely sure about: When i tried to select a mirror from the list neither the localized URL nor auto.mirror.devuan.org seemed to work so i choose manual selection and entered deb.devuan.org for the address and /merged/ for the directory which worked fine.

One final problem that had me stuck for a bit was then when trying to install software the installer would fail with a huge message on a red screen. Trying around a bit it came down to the installer having problems with authenticating packages (outdated ISO?) and it's possible to fix this by again switching to a terminal (ALT + cursor right) and running the following commands:

chroot /target apt-get -y --force-yes devuan-keyring
chroot /target apt-get update

After that you can just hit OK on the error message and retry the software installation step.

When the installer is finsihed you have to unmount the ISO:

The huge orange box at the top basically says "You have an ISO mounted" and the link at the end allows you to unmount it. I am quite sure you could archive the same using the ISO-Images menu entry also though.

At this point your Devuan VM is ready to go. I found IPv6 wasn't configured but i guess it's easy to fix that by following the post installation instrcutions at https://wiki.hetzner.de/index.php/Cloud … Gateway/en.

That's it. I hope it's somewhat useful. Wonder when Hetzner will add an Ascii ISO though. I am not using any cloud instances otherwise i'd pester the support about it. Guess they'll sooner or later add it anyways given they allready have Jessie.

Ouch. Should have remembered that.

Yeah, Hetzner has no official support. At least not on the normal VPS/dedis and is imo unlikely to add it (my servers all run voodoo'd Devuan installs) but their cloud VPS seem to be able to install from a user supplied ISO. At least i had a friend tell me he had installed Devuan on it and he is not the guy to go through the voodoo steps. I was like: "Nice. How did you do it?" and he replied "I selected custom ISO".

Edit: Hmm now i am getting curious. Might check this out tommorow. Maybe there actually is something that lets you directly select Devuan? I'd be seriously surprised but who knows? That'd be massive. Hetzner is damn huge.

The only abuse potential i could come up from the top of my head is registering lots of sock puppets and having each mark user X as a troll thereby making X look like, well, a troll.

Anyways, are there even trolls here yet? No, don't look at me... I am just confused sometimes

Yeah though about this too but then it seems he has already used the service with other OSs and i have a feeling the host will argue they don't support anything not listed in their panel. Still a full virtualization environment that relies on code running on the guest is a pretty sad thing and i'd let the host know quite well what i think of it. These days it's not even all that uncommon to be able to just use a custom ISO for installing. In any case i agree this is really borderline to being a broken product in my opinion.

acpid will not do much on it's own. You need to configure it. You can run acpi_listen as root to see if your keys trigger any event. I figure you want to bind brightness control to your brightness keys? As long as your keys trigger events binding 2 tiny scripts that change brightness by adjusting /sys/class/backlight/*/brightness using acpid (see http://www.thinkwiki.org/wiki/How_to_configure_acpid for how to bind them) should work.

On my thinkpad brightness keys work out of the box though so there might be an easier way for your laptop (not necessarily a thinkpad) too. Sadly i am not entirely sure what makes the keys work for me. Might be the thinkpad modules i've installed or it might be the bios. If it's the bios and that doesn't work in your case acpid might indeed be the best approach.

Well, as long as you have to default route on tunY VPN config should be fine. What i'd do at this point is fire up tcpdump to debug:

tcpdump -ni eth0

Do you see the packets from your client connecting to your internal VPN server? If yes do also see the replies going from the server to the client? If you see the packets from the client but don't see any replies can you see replies when running

tcpdump -ni tunY

Edit: You can add

port [YOUR-INTERNAL-VPN-SERVER-PORT]

to the tcpdump commandline to filter traffic. Might be a bit hard to spot anything otherwise.

Edit2: It not working with nopull (as that should have eliminated the default route toward tunY) seems a bit fishy to me. If it worked and the default route points towards eth0 i don't see how it could stop you from connecting from outside. Are you sure the packets aren't getting blocked by iptables?