Re: kern/50978: Default gateway does not work with IPsec

[Frank Wille <frank%phoenix.owl.de@localhost>]

Christos Zoulas wrote:

>  Now that I think about it more, this is probably "by design". Let's
>  say that you are with your home machine and you want to create an
>  IPSEC tunnel to work. You get assigned an IP address to connect to
>  the work VPN. At this point the assumption is that all traffic
>  should go through that VPN, because you could run into security
>  issues (your machine bridging work with the rest of the internet
>  for example).

Ok, that might be a valid reason. Although in my case the home machine is
behind a router/NAT, so the rest of the internet has never direct contact
with the work VPN.

When it really is designed that way, it would be nice to have an option to
disable it.


> This is also how other VPNs work (routing all traffic
>  through the tunnel)  as opposed to a split horizon approach, where
>  only the traffic destined for the tunnel goes there.

Not all VPNs work like this. The commercial "Lancom Advanced VPN client",
which we use on our Windows machines, creates a virtual interface for the
VPN-LAN 192.168.0.0/24 and routes only that traffic encrypted. I tried to
reproduce the behaviour for the NetBSD machines.


> This probably has to do with the weak vs. strong host model:

I don't think so. Weak/strong host model is about different network
interfaces, e.g. one for the WAN and another one for LAN side. The strong
model makes sure that only packets with the WAN source-IP can be send over
the WAN interface.

In my case I have only a single network interface, re0, which has to route
all traffic. But it has two addresses. The real 192.168.45.21 and the VPN
192.168.0.213. Part of the traffic goes through an ESP tunnel to 1.2.3.4,
but the rest should be sent unencrypted to other destintations.


>  TL;DR net.inet.ip.checkinterface might do what you want.

Unfortunately not. I tried that. No difference.


-- 
Frank Wille