On Mon, Nov 25, 2024 at 07:59:09PM +1000, David Gwynne wrote: > On Sun, Nov 24, 2024 at 05:55:12PM +0000, bsdbsdbsd1 wrote: > > OpenBSD needs an easily implementable killswitch for VPNs. > > i'd argue it has one. or two. maybe more. > > my preferred solution is to put the vpn protected traffic in a separate > rdomain to the vpn transport. for example, let's use wireguard to > protect lan traffic. wg0 is the vpn tunnel, and rge0 is internal lan. > the wireguard traffic go out to the internet over rge1 in rdomain 1. > > a config like this could look like this: > > # cat /etc/hostname.rge1 > description wan > rdomain 1 > inet 192.0.2.2 255.255.255.0 > !route -T1 add default 192.168.2.1 > up > > # cat /etc/hostname.wg0 > description vpn > wgrtable 1 > rdomain 0 > inet 10.0.0.1 255.255.255.255 > wgkey BASE64STUFFS > wgpeer OTHERBASE64PUBKEY \ > wgendpoint VPNSERVER VPNPORT \ > wgaip 0.0.0.0/0 > > # cat /etc/hostname.rge0 > description lan > inet 192.168.0.1 255.255.255.0 > up > > # cat /etc/mygate > 10.0.0.1 > > you can then treat wg0 like you would a normal internet connection. > traffic in rdomain 0 can't leak init rdomain 1 and get out to the > internet unencrypted, even if the vpn connection is down.
Applications started in rdomain 0 could switch themselves into rdomain 1 by calling setrtable(2) (in pledged applications, doing this requires the "id" pledge). Applications started in a non-zero rdomain cannot ever leave their assigned rdomain, provided they are not running as root. For this reason my travel VPN looks basically the same as above, but with the rdomains swapped. I can then start selected applications with route -T 1 exec ... and they won't leak traffic to the local network. For DNS I am using pf to redirect queries to a known DNS server which is reachable via the VPN; match out on rdomain 1 inet proto udp to port domain rdr-to $resolver
