NetBSD Problem Report #50978

From www@NetBSD.org  Fri Mar 18 13:29:41 2016
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id C32D67A212
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 18 Mar 2016 13:29:41 +0000 (UTC)
Message-Id: <20160318132940.5BEE67ACA1@mollari.NetBSD.org>
Date: Fri, 18 Mar 2016 13:29:40 +0000 (UTC)
From: frank@phoenix.owl.de
Reply-To: frank@phoenix.owl.de
To: gnats-bugs@NetBSD.org
Subject: Default gateway does not work with IPsec
X-Send-Pr-Version: www-1.0

>Number:         50978
>Category:       kern
>Synopsis:       Default gateway does not work with IPsec
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 18 13:30:00 +0000 2016
>Last-Modified:  Fri Mar 18 15:10:01 +0000 2016
>Originator:     Frank Wille
>Release:        NetBSD 7.0_STABLE after 06-mar-2016
>Organization:
Wendik Pumpen-Service GmbH
>Environment:
NetBSD enceladus 7.0_STABLE NetBSD 7.0_STABLE (GENERIC) #0: Mon Mar 14 12:26:10 CET 2016  frank@tethys:/home/frank/netbsd/7/src/objx64/sys/arch/amd64/compile/GENERIC amd64
>Description:
I'm running IPsec in a "Roadwarrior" configuration, i.e. my host
receives a VPN-LAN address from a VPN gateway, making it part of the
remote LAN by setting an IP-address alias for my network interface.

My system is 192.168.45.21 and part of the network 192.168.45.0/24
with default gateway 192.168.45.254. The VPN-LAN is 192.168.0.0/24
with default gateway 192.168.0.1. The VPN-gateway is at 1.2.3.4.

I'm using Racoon to set up my IPsec connection. It assigns me the
VPN client address 192.168.0.213 and calls a Phase1-up script, which
sets 192.168.0.213 as alias to my network interface re0 and enters
the following policies into the database:

spdadd 192.168.0.213/32[any] 192.168.0.0/24[any] any
       -P out ipsec esp/tunnel/192.168.45.21-1.2.3.4/require;
spdadd 192.168.0.0/24[any] 192.168.0.213/32[any] any
       -P in ipsec esp/tunnel/1.2.3.4-192.168.45.21/require;

After Phase2 has been established (by accessing any address from
192.168.0.0/24) the default routing no longer works. I have access
to all hosts in the VPN LAN 192.168.0.0/24 and to my local net
192.168.45.0/24, but no address which requires routing over the
default gateway works any longer. Example:

# ping 8.8.8.8
PING google-public-dns-a.google.com (8.8.8.8): 56 data bytes

The nameserver from the VPN (192.168.0.251) works, but there is no
reply, as tcpdump confirms. It also shows that the source address
for the ping became 192.168.0.213, which is my VPN address:

# tcpdump -n
14:55:49.410338 IP: IP 192.168.0.213 > 8.8.8.8: ICMP echo request, id 34226,
seq 0, length 64
14:55:50.414873 IP: IP 192.168.0.213 > 8.8.8.8: ICMP echo request, id 34226,
seq 1, length 64

It works with either of the following methods:

1. Use the correct source interface 192.168.45.21 instead of
   192.168.0.213:
   # ping -I 192.168.45.21 8.8.8.8

2. Add a route for the WAN address to reach over the default gateway:
   # route add 8.8.8.8 192.168.45.254
   # ping 8.8.8.8

It looks like there is a bug in the kernel, which doesn't select the
correct source address when routing over the default gateway and
IPsec is enabled.

>How-To-Repeat:
See above. In short:

1. IPsec connection in Roadwarrior configuration required.

2. Add VPN client address as an alias to your network interface.

3. SPD:
   spdadd 192.168.0.213/32[any] 192.168.0.0/24[any] any
          -P out ipsec esp/tunnel/192.168.45.21-1.2.3.4/require;
   spdadd 192.168.0.0/24[any] 192.168.0.213/32[any] any
          -P in ipsec esp/tunnel/1.2.3.4-192.168.45.21/require;

4. Try to connect to a WAN address, which is routed over the
   default gateway and not covered by any SPD.

Note: NetBSD-current or NetBSD-7 after the 6th of March 2016 is required
to make a Roadwarrior IPsec configuration work with NAT-T.

>Fix:

>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org, 
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc: 
Subject: Re: kern/50978: Default gateway does not work with IPsec
Date: Fri, 18 Mar 2016 09:49:13 -0400

 On Mar 18,  1:30pm, frank@phoenix.owl.de (frank@phoenix.owl.de) wrote:
 -- Subject: kern/50978: Default gateway does not work with IPsec

 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). 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. This probably has
 to do with the weak vs. strong host model:

 https://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx
 http://osdir.com/ml/netbsd.devel.network/2005-12/msg00080.html

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

 christos

From: Frank Wille <frank@phoenix.owl.de>
To: gnats-bugs@NetBSD.org,
	kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
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

Home	PR Database Search