[Openswan Users] Debian openswan Nat-t problem (ESP packets)

[Marco Perrando]

The scenario is: Windows box behind NAT that make L2TP/ipsec
connection to linux box with public address.

Key exchange establishes a ESP connection through some packets on port 
500 and
some encapsulated traffic on port 4500. Then I think pluto did its work
correctly.

The problem araise when ESP packets start to flow.
They are received uncorrectly on the linux box.

I tested with different kernels.

Software on linux box:
+ linux debian sarge
| +- 2.4.27 kernel
| +- 2.4.27 kernel + openswan module (ipsec.o)
| +- 2.4.27 kernel + openswan patches
| +- 2.6.7 kernel
+ Openswan 2.1.3

The results are exactly the same with the four kernels.

To show the problem I captured packets both onlinux box and on another 
box to
see the REAL packets on-the-wire.
I attach the two captures of the first ESP packet.

The bytes of both packets are identical after the IP header, but the packet
captured on the linux box shows a ESP protocol instead of UDP as it is 
on the
wire (note that IP seq number, IP checksum and the rest is IDENTICAL)..
Then, being the rest of the bytes unaltered, the UDP part, i.e.

hex    : 11 94 11 94 00 94 00 00
dec    : 4500  4500  148   0
meaning: sp    dp    lth   chsm

is interpreted as the ESP packet resulting in

hex    : 11 94 11 94 00 94 00 00
dec    : ??          9699328
meaning: SPI         sequence

Then packet is discarded beacuse, as you can see looking at the on-the-wire
packet, the real SPI number is 0x7b4c2d6c, and its sequence is 1 
(actually it is
the first packet sent to the server for L2TP authentication).

It appears that the linux box mangles such packets, and they are 
misunterstood
by the IPSEC software.

Does someone know what's going on?

Marco.

PACKET on-the-wire
===================
...other headers...
Internet Protocol, Src Addr: 213.92.104.69 (213.92.104.69), Dst Addr: 
80.16.219.232 (80.16.219.232)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 168
    Identification: 0x793e (31038)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 117
    Protocol: UDP (0x11)
    Header checksum: 0x626c (correct)
    Source: 213.92.104.69 (213.92.104.69)
    Destination: 80.16.219.232 (80.16.219.232)
User Datagram Protocol, Src Port: 4500 (4500), Dst Port: 4500 (4500)
    Source port: 4500 (4500)
    Destination port: 4500 (4500)
    Length: 148
    Checksum: 0x0000 (none)
UDP Encapsulation of IPsec Packets
Encapsulating Security Payload
    SPI: 0x7b4c2d6c
    Sequence: 1
    Data (132 bytes)

PACKET at server
=================
...other headers...
Internet Protocol, Src Addr: 213.92.104.69 (213.92.104.69), Dst Addr: 
80.16.219.232 (80.16.219.232)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 160
    Identification: 0x793e (31038)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 117
    Protocol: ESP (0x32)
    Header checksum: 0x626c (incorrect, should be 0x6253)
    Source: 213.92.104.69 (213.92.104.69)
    Destination: 80.16.219.232 (80.16.219.232)
Encapsulating Security Payload
    SPI: 0x11941194
    Sequence: 9699328
    Data (54 bytes)