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 <lchiquitto@novell.com> 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.