Re: [strongSwan] Access to local subnet when tunnel up
Dimitrios, That is a brilliant idea, thank you. Out-of-the-box thinking. Or is that out-of-the-table ? :-) Graham. 2009/11/15 Dimitrios Siganos > I can think of another option might might make the whole setup cleaner. > > Introduce another route table (e.g. 219), which has priority over the > table 220, and has the route for the local network. To setup that you > need to look at the "ip rule" commands. > > This way, no matter what charon/pluto do, the route in table 219 will > always have precedence. > > ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Access to local subnet when tunnel up
Hi, > Introduce another route table (e.g. 219), which has priority over the > table 220, and has the route for the local network. To setup that you > need to look at the "ip rule" commands. I agree, this is probably the best solution. This routing policy database is very powerful, just "man ip" for details. > However, depending on how the tunnel was specified (what was specified > in left/rightsubnet) you might have to add xfrm rules for the network > traffic as well, because, I believe that the xfrm rules are applied > after the route table lookup on the way out and before on the way in. If I understand the setup correctly, this is not needed. As you have a virtal IP <=> 0.0.0.0/0 IPsec policy, traffic originating from any other address won't match. Just make sure that your higher priority route for the local net uses the correct source address. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Access to local subnet when tunnel up
I can think of another option might might make the whole setup cleaner. Introduce another route table (e.g. 219), which has priority over the table 220, and has the route for the local network. To setup that you need to look at the "ip rule" commands. This way, no matter what charon/pluto do, the route in table 219 will always have precedence. However, depending on how the tunnel was specified (what was specified in left/rightsubnet) you might have to add xfrm rules for the network traffic as well, because, I believe that the xfrm rules are applied after the route table lookup on the way out and before on the way in. Dimitris Graham Hudspith wrote: > Andreas, > > Thanks for the reply. I'm afraid I'm not an expert on xfrm policies. Could > you please give an example of the add command you had in mind? > > However, as Daniel states, your diagnosis does not sound quite right to me. > > Just going via the ip routing tables (and ignoring xfrm), it seems that > specific routes take precedence over default routes and strongswan uses a > separate table (220) because any default route added there takes precedence > over a default route in the default table. > > However, an unintended consequence is that a default route in table 220 > takes precedence over a specific route in the default table. So, as my > original posting showed, either we need to: > >- get strongswan to add an equivalent specific route to table 220 as >already present in the default table, or >- get strongswan to NOT use table 220 but to manage the routes in the >default table, or >- get strongswan to NOT manage routes at all (via the >charon.install_routes option in strongswan.conf) and manage the routes >ourselves, based on events from charon > > Or, is there a fourth option? > > Daniel, > > Thanks for chipping in! > > 2009/11/13 Daniel Mentz > > > > >> could you please post the output of >> >> ip xfrm policy >> >> >> > Here you go ... > > Regards, > > Graham. > > # *ip xfrm policy* > > src 0.0.0.0/0 dst 1.1.35.49/32 > > dir fwd priority 2000 > > tmpl src segw.somewhere.com dst 192.168.50.154 > > proto esp reqid 1 mode tunnel > > src 0.0.0.0/0 dst 1.1.35.49/32 > > dir in priority 2000 > > tmpl src segw.somewhere.com dst 192.168.50.154 > > proto esp reqid 1 mode tunnel > > src 1.1.35.49/32 dst 0.0.0.0/0 > > dir out priority 1680 > > tmpl src 192.168.50.154 dst segw.somewhere.com > > proto esp reqid 1 mode tunnel > > src 0.0.0.0/0 dst 0.0.0.0/0 > > dir 3 priority 0 > > src 0.0.0.0/0 dst 0.0.0.0/0 > > dir 4 priority 0 > > src 0.0.0.0/0 dst 0.0.0.0/0 > > dir 3 priority 0 > > src 0.0.0.0/0 dst 0.0.0.0/0 > > dir 4 priority 0 > ___ > 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
Re: [strongSwan] Access to local subnet when tunnel up
Andreas, Thanks for the reply. I'm afraid I'm not an expert on xfrm policies. Could you please give an example of the add command you had in mind? However, as Daniel states, your diagnosis does not sound quite right to me. Just going via the ip routing tables (and ignoring xfrm), it seems that specific routes take precedence over default routes and strongswan uses a separate table (220) because any default route added there takes precedence over a default route in the default table. However, an unintended consequence is that a default route in table 220 takes precedence over a specific route in the default table. So, as my original posting showed, either we need to: - get strongswan to add an equivalent specific route to table 220 as already present in the default table, or - get strongswan to NOT use table 220 but to manage the routes in the default table, or - get strongswan to NOT manage routes at all (via the charon.install_routes option in strongswan.conf) and manage the routes ourselves, based on events from charon Or, is there a fourth option? Daniel, Thanks for chipping in! 2009/11/13 Daniel Mentz > > > could you please post the output of > > ip xfrm policy > > Here you go ... Regards, Graham. # *ip xfrm policy* src 0.0.0.0/0 dst 1.1.35.49/32 dir fwd priority 2000 tmpl src segw.somewhere.com dst 192.168.50.154 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 1.1.35.49/32 dir in priority 2000 tmpl src segw.somewhere.com dst 192.168.50.154 proto esp reqid 1 mode tunnel src 1.1.35.49/32 dst 0.0.0.0/0 dir out priority 1680 tmpl src 192.168.50.154 dst segw.somewhere.com proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 dir 4 priority 0 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Access to local subnet when tunnel up
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
Re: [strongSwan] Access to local subnet when tunnel up
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
[strongSwan] Access to local subnet when tunnel up
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. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
