Hi Graham, could you please post the output of
ip xfrm policy Hi Andreas, I guess that the problem is a different one. Graham uses two different source IP addresses depending on whether the traffic is destined for the local subnet or any other host on the Internet. He uses 192.168.50.154 as the source address for local traffic and 1.1.35.49 as the source address for traffic to all other destinations. So I guess he has to massage the routing table properly so that the kernel picks the correct source address for traffic originated from the local host. The ipsec policy only affects traffic with this pattern 1.1.35.49/32 <=> 0.0.0.0/0 So if the kernel picks 192.168.50.154 as the source address for local traffic then the policy does not match and there's also no need for a passthrough policy. So I guess it's all about setting up the routing table correctly. Please correct me if I'm wrong. -Daniel Andreas Steffen wrote: > 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]== > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > Users@lists.strongswan.org > https://lists.strongswan.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
