[Openswan Users] Bug 677 - NAT-T with NETKEY not working (2.6.19 kernel)

[Mike Horn]

Hi,

We are using Openswan 2.4.6 with a 2.6.19 kernel with NETKEY.  We are seeing
the same behavior as that reported in bug 677 where there is a NAT device
between the two Openswan gateways.  The endpoints detect the NAT and setup a
UDP encapsulated tunnel, but when traffic is sent over the tunnel it is
encrypted on the sender's side and arrives at the receivers side, but the
packets are not decrypted.

 -----------        -------------             ---------
------------           ----------
 | PC-1 |--------| VPN-1 |-------------| NAT |------------| VPN-2
|----------| PC-2 |
 -----------        -------------             ---------
------------           ----------

In the output below PC-1 is sending traffic to PC-2:

>> From VPN-1

[root at uml-11 tunnels]# setkey -D
172.3.3.12[4500] 172.4.4.11[4500]
        esp-udp mode=tunnel spi=218697724(0x0d090ffc)
reqid=16389(0x00004005)
        E: aes-cbc  e573ff6a 20b87b20 2b657ef5 d7695441 5bf2e9e2 7c2c4c18
1c1e8829 16cc125d
        A: hmac-sha1  583996f4 97387d9f 5428c008 2c9af378 ce6301f3
        seq=0x00000000 replay=32 flags=0x00000000 state=mature
        created: Feb 13 10:13:59 2007   current: Feb 13 10:30:13 2007
        diff: 974(s)    hard: 0(s)      soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=3 pid=3105 refcnt=0
172.4.4.11[4500] 172.3.3.12[4500]
        esp-udp mode=tunnel spi=2583668198(0x99ffa5e6)
reqid=16389(0x00004005)
        E: aes-cbc  321f9919 105fa309 efa7f435 ec0b0664 715291e0 b9ca8816
9ff41b94 071ebf2f
        A: hmac-sha1  ad781b92 556f5f1f f7933127 c7ec7af6 6b45fa55
        seq=0x00000000 replay=32 flags=0x00000000 state=mature
        created: Feb 13 10:13:59 2007   current: Feb 13 10:30:13 2007
        diff: 974(s)    hard: 0(s)      soft: 0(s)
        last: Feb 13 10:14:00 2007      hard: 0(s)      soft: 0(s)
        current: 152800(bytes)  hard: 0(bytes)  soft: 0(bytes)
                    ^ ** traffic is being encrypted using this outbound SA

        allocated: 955  hard: 0 soft: 0
        sadb_seq=1 pid=3105 refcnt=0
[root at uml-11 tunnels]#

>> From VPN-2

[root at uml-12 eth1]# setkey -D
172.3.3.101[4500] 172.3.3.12[4500]
        esp-udp mode=tunnel spi=2583668198(0x99ffa5e6)
reqid=16393(0x00004009)
        E: aes-cbc  321f9919 105fa309 efa7f435 ec0b0664 715291e0 b9ca8816
9ff41b94 071ebf2f
        A: hmac-sha1  ad781b92 556f5f1f f7933127 c7ec7af6 6b45fa55
        seq=0x00000000 replay=32 flags=0x00000000 state=mature
        created: Feb 13 10:13:59 2007   current: Feb 13 10:32:40 2007
        diff: 1121(s)   hard: 0(s)      soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
                    ^ ** No traffic being decrypted on this inbound SA

        allocated: 0    hard: 0 soft: 0
        sadb_seq=1 pid=2863 refcnt=0
172.3.3.12[4500] 172.3.3.101[4500]
        esp-udp mode=tunnel spi=218697724(0x0d090ffc)
reqid=16393(0x00004009)
        E: aes-cbc  e573ff6a 20b87b20 2b657ef5 d7695441 5bf2e9e2 7c2c4c18
1c1e8829 16cc125d
        A: hmac-sha1  583996f4 97387d9f 5428c008 2c9af378 ce6301f3
        seq=0x00000000 replay=32 flags=0x00000000 state=mature
        created: Feb 13 10:13:59 2007   current: Feb 13 10:32:40 2007
        diff: 1121(s)   hard: 0(s)      soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=0 pid=2863 refcnt=0
[root at uml-12 eth1]#

>> From VPN-2 we can see the packets arriving with SPI 0x99ffa5e6

[root at uml-12 eth1]# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
10:34:34.733830 IP 172.3.3.101.ipsec-nat-t > 172.3.3.12.ipsec-nat-t:
UDP-encap:
ESP(spi=0x99ffa5e6,seq=0x4bc), length 132
10:34:35.753778 IP 172.3.3.101.ipsec-nat-t > 172.3.3.12.ipsec-nat-t:
UDP-encap:
ESP(spi=0x99ffa5e6,seq=0x4bd), length 132
10:34:36.773966 IP 172.3.3.101.ipsec-nat-t > 172.3.3.12.ipsec-nat-t:
UDP-encap:
ESP(spi=0x99ffa5e6,seq=0x4be), length 132

It appears that there were no fixes for bug 677, the user just used a
different kernel (2.6.18.1).  Is there some additional debugging information
that I can provide to try and get to the bottom of why this seems to only
happen with some kernels?  I looked at the 2.6.18.1 ChangeLog and didn't see
anything that appeared to provide a fix for any NETKEY type issues.
Non-NAT'ed tunnels between these two VPN gateways work properly.

-mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20070213/966d1fe3/attachment.html