[Openswan Users] Fwd: openswan multi subnet routing problem

[Bo Jin]

Hi All,

I am having some difficulties in routing traffic on an openswan box. below
is my setup:
(10.43.4.0/24) <-> router <-> (10.43.6.0/24) <->Openswan box <- IPSec VPN
Tunnel -> Amazon VPC <-> (10.43.7.0/24)

The tunnels are up. I can ping back and forth between 10.43.6.0/24 <->
10.43.7.0/24. Internally, I can ping between 10.43.4.0/24 <-> 10.43.6.0/24.
However, when I ping from 10.43.4.0/24 to 10.43.7.0/24, I can see the
traffic flowing from 10.43.4.0 -> router -> 10.43.6.0/24 -> VPN tunnel ->
10.43.7.0/24 -> VPN tunnel (stops here). The OpenSwan box on my side does
not route the return traffic out of its internal interface to the next hop
(the internal router to 10.43.4.0/24 network).

Here is my routing table:
206.****.***.64/27 dev eth1  proto kernel  scope link  src 206.***.***.83
10.43.6.0/24 dev eth0  proto kernel  scope link  src 10.43.6.128
10.43.4.0/24 via 10.43.6.4 dev eth0
10.43.1.0/24 via 10.43.6.1 dev eth0
192.168.11.0/24 via 10.43.6.1 dev eth0
169.254.0.0/16 dev eth0  scope link  metric 1002
169.254.0.0/16 dev eth1  scope link  metric 1003
default via 206.***.***.65 dev eth1

I disabled firewall on the Openswan box, just to roll out the firewall. So
there is *no* NAT, no filters, just straight routing.

Here is my Openswan configuration:
conn aws-vpc-10.43.6.x-10.43.7.x
        leftsubnet=10.43.6.0/24
rightsubnet=10.43.7.0/24
 auto=start
        left=206.***.***.83
        right=72.***.***.225
        authby=secret
        ike=aes128-sha1;modp1024
        phase2=esp
        phase2alg=aes128-sha1;modp1024
        aggrmode=no
        ikelifetime=8h
        salifetime=1h
        dpddelay=10
        dpdtimeout=40
        dpdaction=restart
        type=tunnel

conn aws-vpc-10.43.4.x-10.43.7.x
        leftsubnet=10.43.4.0/24
        rightsubnet=10.43.7.0/24
        auto=start
        left=206.***.***.83
        right=72.***.***.225
        authby=secret
        ike=aes128-sha1;modp1024
        phase2=esp
        phase2alg=aes128-sha1;modp1024
        aggrmode=no
        ikelifetime=8h
        salifetime=1h
        dpddelay=10
        dpdtimeout=40
        dpdaction=restart
        type=tunnel


After started the IPsec tunnel:
# service ipsec status
IPsec running  - pluto pid: 38390
pluto pid 38390
2 tunnels up
some eroutes exist

# ip xfrm policy
src 10.43.4.0/24 dst 10.43.7.0/24
dir out priority 2344 ptype main
 tmpl src 206.191.2.83 dst 72.21.209.225
proto esp reqid 16389 mode tunnel
src 10.43.6.0/24 dst 10.43.7.0/24
 dir out priority 2344 ptype main
tmpl src 206.191.2.83 dst 72.21.209.225
proto esp reqid 16385 mode tunnel
src 10.43.7.0/24 dst 10.43.6.0/24
dir fwd priority 2344 ptype main
tmpl src 72.21.209.225 dst 206.191.2.83
 proto esp reqid 16385 mode tunnel
src 10.43.7.0/24 dst 10.43.6.0/24
dir in priority 2344 ptype main
 tmpl src 72.21.209.225 dst 206.191.2.83
proto esp reqid 16385 mode tunnel
src 10.43.7.0/24 dst 10.43.4.0/24
 dir fwd priority 2344 ptype main
tmpl src 72.21.209.225 dst 206.191.2.83
proto esp reqid 16389 mode tunnel
src 10.43.7.0/24 dst 10.43.4.0/24
dir in priority 2344 ptype main
tmpl src 72.21.209.225 dst 206.191.2.83
 proto esp reqid 16389 mode tunnel
(not sure why there are duplicates??)

when try to capture openswan internal interface while I am pinging from
10.43.4.0/24 to 10.43.7.0/24, I got request traffic only. This matches what
I see on the internal router side, which sees request traffic only.

# tcpdump -i eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:22:19.461204 IP 10.43.4.31 > 10.43.7.235: ICMP echo request, id 39768,
seq 1322, length 64
12:22:20.468601 IP 10.43.4.31 > 10.43.7.235: ICMP echo request, id 39768,
seq 1323, length 64
12:22:21.474766 IP 10.43.4.31 > 10.43.7.235: ICMP echo request, id 39768,
seq 1324, length 64
12:22:22.475330 IP 10.43.4.31 > 10.43.7.235: ICMP echo request, id 39768,
seq 1325, length 64


this is what I got when capture traffic on external interface of the
openswan:
# tcpdump -n -i eth1 esp
12:22:26.502736 IP 206.191.2.83 > 72.21.209.225:
ESP(spi=0x1a303937,seq=0x569), length 132
12:22:26.534199 IP 72.21.209.225 > 206.191.2.83:
ESP(spi=0x7a9d5b06,seq=0x13132a6), length 132
12:22:27.512736 IP 206.191.2.83 > 72.21.209.225:
ESP(spi=0x1a303937,seq=0x56a), length 132
12:22:27.544249 IP 72.21.209.225 > 206.191.2.83:
ESP(spi=0x7a9d5b06,seq=0x13132a7), length 132
12:22:28.521535 IP 206.191.2.83 > 72.21.209.225:
ESP(spi=0x1a303937,seq=0x56b), length 132
12:22:28.552389 IP 72.21.209.225 > 206.191.2.83:
ESP(spi=0x7a9d5b06,seq=0x13132a8), length 132
12:22:29.520932 IP 206.191.2.83 > 72.21.209.225:
ESP(spi=0x1a303937,seq=0x56c), length 132
12:22:29.552522 IP 72.21.209.225 > 206.191.2.83:
ESP(spi=0x7a9d5b06,seq=0x13132a9), length 132

This suggest the ping traffic was encrypted and sent, and the return
traffic was received at the openswan box external interface. However, it
doesn't send out the return traffic to 10.43.4.0/24 network.

I am not sure if this is openswan who failed to decrypt the traffic or
simply a routing problem. I could not figure out what was incorrect. Can
someone please help? Any hints would be much appreciated!

Cheers,

Bo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20140128/57f209ee/attachment.html>