The two most annoying responses on Usenet are still with us today:
"Why would you want to do that?"
"You don't want to do that."
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.
(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
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.
3.50 a month is cheap.
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.
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>
iptables -t mangle -A OUTPUT -p udp --dport 64444 -j MARK --set-mark 2
I'll try it later.
I have bookmarked them for later. Might want an off-site server sometime.
What OS are they running on the VMs? I didnt see it listed from a quick glance at the plans.
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 18.104.22.168/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.
Overthinking has burnt us all a few times :)
And that is cool.
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...)
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.