Hello, A while ago I asked about Linux Ipsec/Route interactions (https://lists.strongswan.org/pipermail/users/2008-March/002320.html). Andreas's response was very informative and I have put it under my pillow at night and think I understand most of it.
One thing really doesn't make sense yet. My lack of knowledge is best illustrated with the following example (based off of http://www.strongswan.org/uml/testresults43/ikev1/net2net-psk/). I have the following setup: 10.201.0.0/16===192.168.1.1...192.168.1.2===192.168.2.0/24 Using ipsec.conf: version 2.0 config setup plutostart=yes charonstart=no strictcrlpolicy=no conn host-host-1 leftupdown=/usr/lib/ipsec/sel_updown keyingtries=%forever right=192.168.1.2 left=192.168.1.1 auto=start authby=secret keyexchange=ikev1 rightsubnet=192.168.2.0/24 leftsubnet=10.201.0.0/16 # ip route show table all 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1 10.201.0.0/16 dev eth1 proto kernel scope link src 10.201.98.1 local 192.168.1.1 dev eth0 table local proto kernel scope host src 192.168.1.1 broadcast 192.168.1.0 dev eth0 table local proto kernel scope link src 192.168.1.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 local 10.201.98.1 dev eth1 table local proto kernel scope host src 10.201.98.1 broadcast 10.201.255.255 dev eth1 table local proto kernel scope link src 10.201.98.1 broadcast 192.168.1.255 dev eth0 table local proto kernel scope link src 192.168.1.1 broadcast 10.201.0.0 dev eth1 table local proto kernel scope link src 10.201.98.1 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 # ip xfrm state src 192.168.1.1 dst 192.168.1.2 proto esp spi 0x5192db71 reqid 16385 mode tunnel replay-window 32 auth hmac(sha1) 0x178f5e50afcef5a62894b0594dfc5415f6b97836 enc cbc(aes) 0xb6d64b000b6e6d7ba284efa82a8f955c sel src 0.0.0.0/0 dst 0.0.0.0/0 src 192.168.1.2 dst 192.168.1.1 proto esp spi 0x1f4bcfb7 reqid 16385 mode tunnel replay-window 32 auth hmac(sha1) 0x1abb5c546b50c2237ad1c08790fbf94356138617 enc cbc(aes) 0xb47f5395b93137961e627cef9d28636f sel src 0.0.0.0/0 dst 0.0.0.0/0 # ip x p src 10.201.0.0/16 dst 192.168.2.0/24 dir out priority 2600 tmpl src 192.168.1.1 dst 192.168.1.2 proto esp reqid 16385 mode tunnel src 192.168.2.0/24 dst 10.201.0.0/16 dir fwd priority 2600 tmpl src 192.168.1.2 dst 192.168.1.1 proto esp reqid 16385 mode tunnel src 192.168.2.0/24 dst 10.201.0.0/16 dir in priority 2600 tmpl src 192.168.1.2 dst 192.168.1.1 proto esp reqid 16385 mode tunnel 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 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 src 0.0.0.0/0 dst 0.0.0.0/0 dir 3 priority 0 #uname -a Linux box 2.6.29.3 #1 PREEMPT Tue Aug 25 02:11:35 UTC 2009 ppc GNU/Linux The peer is a clone setup (left<->right, auto=add, etc). Iptables is turned off everywhere. It would seem from the previous communications referenced above that this should be sufficient for 10.201.98.2 to reach 192.168.2.3. Packets would leave 10.201.98.2, hit the router on 10.201.98.1, match the policy of src 10.201.0.0/16 dst 192.168.2.0/24, get associated with the appropriate security association, get wrapped in a new ESP packet with a source of 192.168.1.1 and a destination of 192.168.1.2, and fly out to the peer to be decrypted. Unfortunately this doesn't work. However, if I add a route to the gateway like: ip route add 192.168.2.0/24 via 192.168.1.2 (and a symmetric on the other gateway) packets start flowing. Or if I add a default route on the gateway packets start flowing. The interesting thing is, the default gateway doesn't have to exist nor do packets ever get sent to it! IE I can add a default gateway of 192.168.1.50 (no such device on my network) and packets start flowing. It appears that the Linux kernel rejects the packets (Destination Net Unreachable) before they reach the policy if the destination address is not reachable (even though policy template destination would be reachable). Has anyone else seen this? http://www.strongswan.org/uml/testresults43/ikev1/net2net-psk/ lists the output of ip route list table 220, but not ip route list table all, so I am not sure if this test contains any static or default routes that would make the rightsubnet "reachable" from the local gateway. Thanks for any input, Barry _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
