So basically you want to have all all outgoing traffic directed towards the internet go over tunY?

That's kinda strange since tunY still is the default route but i'll wait with drawing any conclusions until i know for sure if you actually want to route traffic to the internet over it or not.

Really, if you want to connect to the internet over tunY is the main question at this point since as is it's configured to do so by these routes (which act as a default route):

0.0.0.0         10.8.y.1        128.0.0.0       UG    0      0        0 tunY
128.0.0.0       10.8.y.1        128.0.0.0       UG    0      0        0 tunY

If you just want packets toward 10.8.y.0/24 to go over tunY this route is enough

10.8.y.0        0.0.0.0         255.255.255.0   U     0      0        0 tunY

and we have to figure out why it even adds the default route or at least stop it from doing so.

Sorry, i am pretty much at loss here as i've never seen something like this before. The only thing i can recommend is checking Xorg.log for anything suspicious in relation the input devices. Maybe the "paused" message i mentioned earlier or if there is any indication of failure to detect the mouse/keyboard. Another thing that comes to mind is if you maybe have an actual X config that might be broken (outdated?) for some reason? This seemingly being related to X in general makes me think it has be somehow fixable by adjusting the config.

Don't worry. People here seem generally very friendly towards other distributions. Haven't seen a single snide remark yet. Not even any jokes regarding the usual stereotypes.

Please someone remind me to add derogatory icons for all other systems to the boot menu if i ever happen to release an OS. I like this idea

I might miss something here but startx exists on Devuan?

You generally should not have to remove packages simply because they are not needed. I admit there is a strong urge to do it for minimalism obsessed people like me but usually it's completely harmless to have a couple superfluous packages. If they are really superfluous and not dependencies - even if useless - of something you want to keep is also another question (you would see it when you try to remove them and your package manager wants to remove some seemingly unrelated packages too).

Yeah, the routing is just one part of the puzzle. Forwarding is the other. I guess the routing is fine beyond the superfluous default route though. The clients-lose-internet symptom is a dead giveaway and lots of OpenVPN server howtos assume the user wants run NAT and have the default route push in their configs which iirc is simply called something like push def1 so it's easy to miss that one doesn't really need this when following those.

Tbh i don't think i fully understood your post but those entries are OpenVPNs way of setting a default route:

0.0.0.0         10.8.y.1        128.0.0.0       UG    0      0        0 tunY
128.0.0.0       10.8.y.1        128.0.0.0       UG    0      0        0 tunY

Since they are more specific they override this route:

0.0.0.0         192.168.x.1     0.0.0.0         UG    0      0        0 ethX

As for this route:

xx.xx.xxx.xx    192.168.x.1     255.255.255.255 UGH   0      0        0 ethX

I guess xx.xx.xxx.xx is actually the IP of the VPN server you are connecting to, right? It's added by OpenVPN to keep routing packets to the VPN server over the external interface. Otherwise the new default route would break the connection to the server.

Bottom line: Unless you want to route packets to the internet over tunY (in which case you should give your VPN server some NAT ability) you should adjust your OpenVPN client config to ignore the default route pushed by the server. https://community.openvpn.net/openvpn/w … ectGateway has some information on how to ignore it. Of course if you control the server you could edit it's config to not push a route (or at least not such a broad one) also.

I have a feeling the VPN server you are connecting to might be pushing you a default route and thereby killing your internet connection by taking packets that should really go to eth0. I'd inspect the output of route -n before and after connecting to the VPN. If the default route gets taken over you might have your culprit and you can adjust your VPN client config to ignore the pushed route.

Edit: Iirc OpenVPN does not actually replace the default route but adds 2 /1 routes and thereby takes precedence (should show up as 0.0.0.0 and 128.0.0.0) so it might not be obvious what is happening.

No direct experience with live build, sorry. But from trying to build a custom debian installer ages ago i vaguely remember having to create a gpg keypair that would become the default key. Just look at the gpg man page iirc it's pretty easy.

Wow! Great read. Don't think this can be expressed much better.

I am not entirely sure if that helps in your situation but adding

-o Acquire::Check-Valid-Until=false

to your apt-get update command would ignore the TTL i think.