Hello Graham, this is a well known problem when all Internet traffic is going to be tunnelled via IPsec (rigthsubnet=0.0.0.0/, i.e. no split-tunneling) but local traffic should not go through the tunnel.
The correct way to handle this is to define a passthrough IPsec policy for the local network 192.168.50.0/24 thus exempting it from IPsec. Since the IKEv2 charon daemon cannot set up passthrough policies [yet] I recommend to use the ip xrfrm policy command. Best regards Andreas Graham Hudspith wrote: > Hello All, > > We're grappling with an access-to-local-subnet-when-the-tunnel-is-up > problem. > > After a tunnel is brought up, the routing table is thus: > > *# ip route show* > > 192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.154 > default via 192.168.50.1 dev eth0 > > *# ip route show table 220* > > default via 192.168.50.1 dev eth0 proto static src 1.1.35.49 > > where 1.1.35.49 is the tunnel's inner IP address. > > What we want is traffic destined for the local subnet (192.168.50.xx) goes > via eth0 from the unit's IP address (192.168.50.154) and everything else to > go via the tunnel. > > Unfortunately, that does not happen. If I ping something on the local > subnet, it gets sent via the tunnel. The default route added in table 220 > seems to take precedence over the subnet route in the default table. > > I've found two different ways to fix this. > > (1) Add the equivalent subnet route to table 220 ... > > ip route add 192.168.50.0/24 dev eth0 proto kernel scope link src > 192.168.50.154 table 220 > > or > > (2) (Quickly) delete the default routes from table 220 and the default table > and then add in a new default route to the default table that is equivalent > to the old one on table 220 ... > > ip route del default via 192.168.50.1 dev eth0 proto static src 1.1.35.7 > table 220 > ip route del default via 192.168.50.1 dev eth0 > ip route add default via 192.168.50.1 dev eth0 proto static src 1.1.35.7 > > and then pings to the local subnet go via the local subnet and pings down > the tunnel go via the tunnel. > > This is with strongSwan 4.3.5. > > Is this a bug in strongSwan ? > > Or, is this the expected (desired?) behaviour ? > > Or, am I misconfiguring something ? > > If this is the expected behaviour, how can I make strongSwan behave the way > I want it too ? Recompile without support for table 220 ? > > Any hints gratefully received ! > > Regards, > > Graham. ====================================================================== Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]==
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
