[Openswan Users] Problem with PSK Site-to-Site VPN Openswan-CiscoIOS

[Cameron Smith]

Dear List, I write to request assistance with the following problem.

It occurs when attempting to interconnect the following devices via a PSK:
 right:
  Ubuntu 10.04 Server with Kernel 2.6.32-33-server and Openswan 1:2.6.23+dfsg-1ubuntu1.
  Has a single ethernet interface (eth0) with IP Addr 192.168.2.254.
  Connects to public internet via a router with IP Addr 192.168.2.5
  iptables has no special configuration

 left:
  Cisco IOS with public IP 41.76.144.226

 Stack: netkey
 connection spec in /etc/ipsec.conf:
  conn vm-enggms1
    authby=secret 
    ikelifetime=86400s    
    pfs=no
    keylife=86400s
    left=41.76.144.226
    leftsubnet=10.5.0.0/16
    leftid=41.76.144.226
    leftnexthop=%defaultroute
    right=192.168.2.254
    rightsubnet=192.168.2.0/24
    rightid=192.168.2.254
    rightnexthop=192.168.2.5
    auto=add

 PSK in /etc/ipsec.secrets not shown but according to ipsec barf is being matched.

When started with [ipsec auto --up vm-enggms1] the connection appears to establish itself correctly as per the output of [ipsec auto --status] below.
================
000 "vm-enggms1": 192.168.2.0/24===192.168.2.254<192.168.2.254>[+S=C]---192.168.2.5...192.168.2.5---41.76.144.226<41.76.144.226>[+S=C]===10.5.0.0/16; erouted; eroute owner: #518
000 "vm-enggms1":     myip=unset; hisip=unset;
000 "vm-enggms1":   ike_life: 86400s; ipsec_life: 86400s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "vm-enggms1":   policy: PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW+lKOD+rKOD; prio: 16,24; interface: eth0; 
000 "vm-enggms1":   newest ISAKMP SA: #3; newest IPsec SA: #518; 
000 "vm-enggms1":   IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024
000  
000 #1: "vm-enggms1":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 70461s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #616: "vm-enggms1":4500 STATE_QUICK_I1 (sent QI1, expecting QR1); EVENT_RETRANSMIT in 6s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #615: "vm-enggms1":4500 STATE_QUICK_I1 (sent QI1, expecting QR1); EVENT_RETRANSMIT in 18s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #614: "vm-enggms1":4500 STATE_QUICK_I1 (sent QI1, expecting QR1); EVENT_RETRANSMIT in 8s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #613: "vm-enggms1":4500 STATE_QUICK_I1 (sent QI1, expecting QR1); EVENT_RETRANSMIT in 19s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #612: "vm-enggms1":4500 STATE_QUICK_I1 (sent QI1, expecting QR1); EVENT_RETRANSMIT in 18s; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #518: "vm-enggms1":4500 STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 1952s; newest IPSEC; eroute owner; isakmp#3; idle; import:admin initiate
000 #518: "vm-enggms1" esp.5e585563 at 41.76.144.226 esp.a1f9ee81 at 192.168.2.254 tun.0 at 41.76.144.226 tun.0 at 192.168.2.254 ref=0 refhim=4294901761
000 #3: "vm-enggms1":4500 STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 70775s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
================

Monitoring traffic with [tcpdump -i eth0 | grep ESP] shows what I suspect is SA renegotiation and keepalive traffic:
17:13:04.045472 IP 192.168.2.254.4500 > 41.76.144.226.4500: NONESP-encap: isakmp: phase 2/others ? oakley-quick[E]
17:13:04.143155 IP 41.76.144.226.4500 > 192.168.2.254.4500: NONESP-encap: isakmp: phase 2/others ? inf[E]

If I then try to ping an address on the left subnet, from a host on the left subnet which has been configured to route via 192.168.2.254, the ping always times out. However it appears that the ICMPs generated by the ping are in fact being carried over the VPN as I see lines like these in the tcpdump output:
 tcpdump -i eth0 | grep ICMP:
18:04:47.228826 IP 192.168.2.203 > 10.50.0.11: ICMP echo request, id 2824, seq 213, length 64
  
 tcpdump -i eth0 | grep ESP:
18:04:50.579195 IP 41.76.144.226.4500 > 192.168.2.254.4500: UDP-encap: ESP(spi=0xaa0fcb94,seq=0x20), length 100
 (strangely, the above shows traffic coming from left->right, which could be the echo reply, but nothing in the other direction.  Or perhaps they are nothing to do with the ICMP payload?).

Monitoring the ping target's physical interface (10.50.0.11) with wireshark confirms that no ICMP echo requests are being received.

So, the problem appears to be somewhere in the "pseudo-routing" that the netkey stack does.  From everything I have read the only tool to introspect this is tcpdump which is not ideal for this job.

Is there any other diagnosis I can attempt, or should I try and build the KLIPS stack for my server and use that?   Apparently it creates a separate ipsec0 interface which will make diagnosing routing problems easier.

regards,
cameron