It's ok, I think my motive for wanting to do that needed to be justified.

When I set up VPN connections like that, I usually just route only our internal subnet over the tunnel. Except when I have a strong need to appear as if I'm coming from a different IP address.

Right -- that's a split tunnel and it's the most efficient way of making things work. Security theater people do non split tunnel because they believe it's more secure to have your Internet traffic go through "their" firewall (and captive DNS and security scanners etc etc) while you're connected to the corporate network.

(Side note: this makes it impossible to use your own network printer, and I can't bypass that on my work machine even with admin access. I actually had to publish a hidden port on my home router, resulting in print jobs taking a 600+ mile round trip to the VPN location and back, when the printer is actually six feet away from the computer.)

As for my setup though, it's non split tunnel because the /29 routed in by my VPN provider is hosting services on the public Internet (including this site) so split tunnel isn't an option; it has to reach the entire Internet.

The reason I want to change things up is because I want to *add* another VPN -- this time to just connect my home network to the server network. And I don't want one VPN to run over the other.

(Side note: this makes it impossible to use your own network printer,

I CAN'T PRINT!!!!!1

As for my setup though, it's non split tunnel because the /29 routed

in by my VPN provider is hosting services on the public Internet
(including this site) so split tunnel isn't an option; it has to reach

the entire Internet.

there might be a DNS domain-route workaround for that

You mean like looking for the dynamic DNS name of the other end and then setting the route appropriately? That could work, as ugly as it might be. There is also the possibility of playing around with route tables and trying to find a way to set a different routing table for a single program. I suspect there's a way to do it.

From home I have two things that need to reach the hosting network directly.
One is me; i.e. connecting to the servers from my desk at home. I've largely solved this by setting up ProxyJump directives in my .ssh/config file. Anything in that range of addresses, SSH automatically tunnels through the machine that runs the VPN VM, and then through the VPN VM itself, and then to the host. It works for regular SSH; it even works from (gasp!) VS Code.

The second is my I2P router. I really want I2P connections to reach the hosted services out-of-band from the normal path. I think I have a solution for this. I bought a $3.50/month server from OVHcloud and I'm going to move my router there. Since it has a static IP address, I can set a host route on the other end and run WireGuard between them.

It sure is. One of the people here via I2P mentioned it to me. They're having a summer promo and I took advantage of it. It's the perfect place for running a tiny little darknet router. Also they don't charge for transfer, they set the service price based on a bandwidth cap (in this case 250 Mbps which I consider pretty generous; Ace only gives 5 Mbps). You could totally use that for an Internet-facing presence and then use a VPN back to the origin servers.

Back to the previous discussion: I think I might see a way to do what I need.
Let's say the VPN is running on port 64444 (that's in a good range for WireGuard; substitute 1701 for L2TP or 443 for SSLVPN or whatever). We want traffic from the VPN program to use the host system's default gateway, while all remaining traffic is entered into the tunnel. The tunnel, again, is the default gateway once the VPN is established.

So...

ip route add table 100 default via <the real default gateway for the host> dev ens0
ip rule add fwmark 0x2 table 100
<various rules to flush out old tables and set local metrics etc>

Followed by...

iptables -t mangle -A OUTPUT -p udp --dport 64444 -j MARK --set-mark 2

I'll try it later.

I'll try it later.

Turns out I was thinking too much. I do that sometimes.

It was easy. Instead of playing around with fwmark and other such incantations, the solution was to start understanding Linux's multiple routing table capabilities and how they can be used outside of containers and namespaces etc.

Step 1: create a routing table, in this case table 100, and make its default the tunnel:
ip route add default dev $1 table 100

Step 2: use that table to route all traffic originating from the origin server network:
ip rule add from 72.0.224.88/29 table 100

That's all it took. None of the other nonsense worked. This worked elegantly and beautifully. Now, traffic being forwarded *through* the host goes into the tunnel, while traffic to/from the host stays on the main routing table.

This of course gets me right back to where I started, but now I can add more VPNs without needing to know the IP address of the other end. I intend to create a Wireguard VPN from my home router to this router, but I have dynamic IP at home. WireGuard supports one end being dynamic. So now when I get a WireGuard connection I simply add the route to my home network (192.168.1.0/24) to table 100 instead of table main. Easy fo'sheezy and everything just works.

2022-09-03 13:33 from IGnatius T Foobar
You mean like looking for the dynamic DNS name of the other end and
then setting the route appropriately? That could work, as ugly as it

what I mean is, systemd-resolved has a mode where you can tell it which TLD/suffix to route to which interface. And each interface has its own DNS servers.

So if you use a TLD like .internal or anything else specific to your org, you can configure the routing so that those names will only ever be queried against the nameservers associated with your VPN interface.

In the absense of this config, the default behavior of systemd-resolved is to send the DNS query on all interfaces at once, and return the first positive response it receives. This mostly works OK, but it has two drawbacks:

1) DNS queries for your internal hosts are sent to the public internet, and might be observed by an attacker who can then gather intel about your internal topology
2) If the address resolves differently when it's queried on your internal nameserver, the result you get is the luck of the draw.

OpenVPN has a config option `dhcp-option DOMAIN-ROUTE foo` which can be used to communicate this config to systemd-resolved (assuming it's not broken at the moment...)

Oooooh, that explains the output of "resolvectl dns" and how it spits out interface-specific resolvers. I was playing around with that yesterday in search of a better way to say "tell me this system's resolvers" other than scanning through /etc/resolv.conf and /etc/systemd/resolved.conf and /etc/netplan/* etc etc etc.

systemd is good at that sort of thing, which is one of the reasons I like it.

For this purpose I'm not sure I could cleanly map a domain to it, because it's acting as a router, and also it's got servers rather than clients behind it. What you are describing sounds like just the thing for split tunnel client VPN though. And that's probably why they did it.

The solution I described earlier feels pretty clean at the moment. One routing table for input/output and another for forwarding.

I quite enjoy playing with plan9 (esp 9front) but the challenge I have is finding a good 3 button rodent. 2 button plus scroll wheel doesn't work for me, because I'm constantly scrolling the wheel when I try to press the middle button. Any recommendations for not-20-years-old 3 button mice? Wired or wireless, I am not picky.

BSD! BSD! BSD!

You might be interested in knowing that SCO Unix (OpenServer) 10 is built on 64-bit FreeBSD.

[ https://www.xinuos.com/products/openserver-10/#os10-features ]

And it can "support legacy SCO products in a virtualized environment" ! Wowzers!!!

For those of you who weren't paying attention ... there are TWO successors to SCO after they went bankrupt trying to sueball their open source competitors out of existence. TSG Group, a legal entity representing SCO's debtors, settled with IBM last year. IBM basically paid them USD$14,250,000 to go away and give up all current and future litigation claims. Xinuos, a company that bought SCO's name and intellectual property back in 2011, continues to hurl lawsuits at IBM, while selling FreeBSD and pretending that it's SCO Unix.

I'm not sure why anyone would want to pay Xinuos for FreeBSD when the downloadable version is perfectly good by itself, but whatever...