[Openswan Users] NAT-T: strange UDP port numbers

Marcus Better marcus at better.se
Sun Dec 11 13:23:11 CET 2005


I am suddenly having problems with some NAT-T connections which used to
work just recently.

The initiator is on a public IP address and the responder is behind NAT.
The connection is brought up correctly with UDP on port 4500. However I
cannot ping any of the sides.

If I ping from the initiator, tcpdump on the sending side shows UDP
packets with source port 4500 but a different destination port. I would
expect the destination port to be also 4500.

This is a host-to-net setup, where the responder aa.bb.cc.dd is a
security gateway for the subnet 192.168.1.0/24.

Here is the result of tcpdump on the initiator when the connection is
first brought up:

-------------------------
initiator# tcpdump -i eth1 -n udp and host responder.example.com
11:40:09.546892 IP 213.113.200.40.500 > aa.bb.cc.dd.500: isakmp: phase 1
I ident
11:40:09.599939 IP aa.bb.cc.dd.500 > 213.113.200.40.500: isakmp: phase 1
R ident
11:40:09.648886 IP 213.113.200.40.500 > aa.bb.cc.dd.500: isakmp: phase 1
I ident
11:40:09.728657 IP aa.bb.cc.dd.500 > 213.113.200.40.500: isakmp: phase 1
R ident
11:40:09.745487 IP 213.113.200.40.4500 > aa.bb.cc.dd.4500: NONESP-encap:
isakmp: phase 1 I ident[E]
11:40:09.833343 IP aa.bb.cc.dd.4500 > 213.113.200.40.4500: NONESP-encap:
isakmp: phase 1 R ident[E]
11:40:09.848135 IP 213.113.200.40.4500 > aa.bb.cc.dd.4500: NONESP-encap:
isakmp: phase 2/others I oakley-quick[E]
11:40:09.930028 IP aa.bb.cc.dd.4500 > 213.113.200.40.4500: NONESP-encap:
isakmp: phase 2/others R oakley-quick[E]
11:40:09.984025 IP 213.113.200.40.4500 > aa.bb.cc.dd.4500: NONESP-encap:
isakmp: phase 2/others I oakley-quick[E]
11:40:28.268313 IP aa.bb.cc.dd.4500 > 213.113.200.40.4500:
isakmp-nat-keep-alive
--------------------------------

Now I run "ping 192.168.1.2" on the initiator:

---------------------------------
initiator# tcpdump -i eth1 -n udp and host responder.example.com
12:19:54.418570 IP 213.113.200.40.4500 > aa.bb.cc.dd.58378: UDP-encap:
ESP(spi=0x203d7555,seq=0x66), length 132
12:19:55.418819 IP 213.113.200.40.4500 > aa.bb.cc.dd.58378: UDP-encap:
ESP(spi=0x203d7555,seq=0x67), length 132
----------------------------------

As you see the destination port is suddenly 58378. It changes for every
run of "ping". Is this good? I don't recall having seen this before, and
it would also make firewalling somewhat more complicated.

And here's the same ping seen from the responder side:

----------------------------------
responder# tcpdump -n udp and host 213.113.200.40
12:19:57.425645 IP 213.113.200.40.4500 > 192.168.1.2.58378: UDP, length
11789
12:19:58.426183 IP 213.113.200.40.4500 > 192.168.1.2.58378: UDP, length
11789
----------------------------------
The packets look suspiciously large here.

The responder does not reply to the pings.

Both hosts are i386 machines running kernel 2.6.14 and Openswan 2.4.4. I
can send more configuration details if necessary.

Regards,

Marcus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3489 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.openswan.org/pipermail/users/attachments/20051211/6b2af987/smime.bin


More information about the Users mailing list