[Openswan Users] openswan multi subnet routing problem

Tue Jan 28 20:04:15 EST 2014

Rescued from the Spam bucket.  Please remember to subscribe to the mailing list before posting to it.

From: Bo Jin <benson.jin at jwcorp.ca>
Subject: openswan multi subnet routing problem
Date: January 28, 2014 at 8:04:07 PM EST
To: users at lists.openswan.org

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/71a6bd60/attachment.html>