[Openswan Users] Peer-to-NAT-to-NAT-to-Peer Configuration Question

[Kevin Hall]

Hello all,

I believe this scenario should work but have yet to be successful.  I 
may be making some foolish mistake but I've been at it for a week so I 
beg your pardon!

The network is two private subnets connected through a larger public 
network.  Each subnet is served by its own router.  The routers provide 
NAT function for the subnets and are linked directly via the public network.

Device-A:eth0 --> NAT_Router-A --> Public <-- NAT_Router-B <-- Device-B:eth0
192.168.110.100 -- 192.168.110.1 NAT 172.16.1.251 -- 172.16.1.253 NAT 
192.168.130.1 -- 192.168.130.100

Both Device ipsec.config have 'nat_traversal=yes' set.  Both Device 
indicate NAT support via "ipsec verify" output.  I have had several 
Openswan versions in use, in particular 2.4.7 and 2.6.16.  My Linux 
kernel has been version 2.6.12 with the native netkey stack.

Device-A conn section:

conn deviceA-deviceB-0-0
     type=tunnel
     left=192.168.110.100
     leftid=172.16.1.251
     leftnexthop=192.168.110.1
     leftsubnet=192.168.110.100/32
     leftrsasigkey=<KEY A>
     right=172.16.1.253
     rightid=172.16.1.253
     rightnexthop=172.16.1.1
     rightsubnet=192.168.130.100/32
     rightrsasigkey=<KEY B>
     auto=start
     keyingtries=%forever
     authby=rsasig
     compress=no

Device-B conn section:

conn deviceA-deviceB-0-0
     type=tunnel
     left=192.168.130.100
     leftid=172.16.1.253
     leftnexthop=192.168.130.1
     leftsubnet=192.168.130.100/32
     leftrsasigkey=<KEY B>
     right=172.16.1.251
     rightid=172.16.1.251
     rightnexthop=172.16.1.1
     rightsubnet=192.168.110.100/32
     rightrsasigkey=<KEY A>
     auto=add
     keyingtries=%forever
     authby=rsasig
     compress=no

The left/right specific numbers were derived from 
http://wiki.openswan.org/index.php/Openswan/NatTraversal.  I've picked 
up some of the others along the way.  I can verify that the <KEY A> 
values in both files match along with the <KEY B> values.

The farthest I have gotten from "ipsec auto --status" output is MI3 sent 
from Device-A and Device-B waiting on MI3.  From tcpdump I can see that 
this is up to the first UDP encapsulated packet.  It is received at 
Device-B but not processed.

For comparison: These devices have a second interface that I've 
networked directly.  I can bring up an IPSec tunnel between these second 
interfaces (using the same key values).

My only other outlet will be trying a newer kernel which I hope to try soon.

Any ideas are greatly appreciated.  Thank you for your time!

-- 
Kevin Hall
Software Engineer
khall at pt.com