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

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

The following reply was made to PR kern/50978; it has been noted by GNATS.

From: Frank Wille <frank%phoenix.owl.de@localhost>
To: gnats-bugs%NetBSD.org@localhost,
	kern-bug-people%netbsd.org@localhost,
	gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/50978: Default gateway does not work with IPsec
Date: Fri, 18 Mar 2016 16:05:14 +0100

 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