https://bugzilla.novell.com/show_bug.cgi?id=422918
User lchiquitto@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=422918#c1
--- Comment #1 from Leonardo Chiquitto 2008-09-05 06:47:34 MDT ---
First debugging session points to endianness problems. When connecting to
the VPN from a x86_64 machine, the following traffic is observed:
IP 192.168.1.56.4500 > 130.57.1.243.2002: UDP-encap:
ESP(spi=0x02013a90,seq=0xd), length 92
IP 130.57.1.243.2002 > 192.168.1.56.4500: UDP-encap:
ESP(spi=0x0e1e7a2a,seq=0xa), length 92
IP 192.168.1.56.4500 > 130.57.1.243.2002: UDP-encap:
ESP(spi=0x02013a90,seq=0xe), length 84
IP 130.57.1.243.2002 > 192.168.1.56.4500: UDP-encap:
ESP(spi=0x0e1e7a2a,seq=0xb), length 140
When connecting from a ppc machine, there's just the outcoming traffic:
IP 10.1.1.4.4500 > 130.57.7.242.53767: UDP-encap: ESP(spi=0xd5dd3b43,seq=0x3),
length 92
IP 10.1.1.4.4500 > 130.57.7.242.53767: UDP-encap: ESP(spi=0xd5dd3b43,seq=0x4),
length 92
We can observe that the destination port is different (53767) and should be the
same as above (2002). On little endian architectures, htons(2002) == 53767.
We can also observe that IPsec's NAT-Traversal feature is being used. The
endpoints (client:4500 - server:2002) are probably negotiated on Phase 1.
I still have to figure out if the problem lies in the server, transmitting
the port number with the incorrect byte order, or in the client, forgetting
to convert the received port number to the correct byte order.
I'll try to discover whether our VPN servers are big or little endian.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.