-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello!
I renamed this, since NAT-T is the task at hand.
I found out that the Cisco closed source driver actually establishes a
NAT-traversing connection. The Concentrator does not, however, send the
nat-t Vendor ID, at least not in the first two unencrypted packets as I
understand it should. There are no NAT-D payloads in those two packets
as well. So I'd guess it uses some other method of discovering NAT
traversal and negotiating encapsulation.
Another strange thing is that it uses UDP port 10000 on the Concentrator
for tunneling, as specified somewhere in the manual, but opposed to the
UDP encapsulation drafts. The nat-t draft says to switch to 4500, and
the udp-encaps draft tells us to use that same port for encapsulated ESP
as well. But my connection stays on UDP 500 for all ISAKMP and uses
10000 in parallel for some encapsulated data. At least those packets
seem to follow udp-encaps.
The any Vendor ID common in the first ISAKMP packets was Microsoft
L2TP/IPSec VPN Client, 4048B7D56EBCE88525E7DE7F00D6C2D3C0000000. Maybe
this provides some way of negotiating ESP over UDP. I can find no such
thing in RFC3193, but I don't really know.
Hope someone can shed some light on these mysteries.
Greetings,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFA47wN1uxO6mboU6gRApuyAJ4qr9+Lx70FwA6TaawozuOsxnbKuQCcCSuw
y0TNZSUu86b5gY/WtgbWybs=
=VDR7
-----END PGP SIGNATURE-----
Hash: SHA1
Hello!
I renamed this, since NAT-T is the task at hand.
I found out that the Cisco closed source driver actually establishes a
NAT-traversing connection. The Concentrator does not, however, send the
nat-t Vendor ID, at least not in the first two unencrypted packets as I
understand it should. There are no NAT-D payloads in those two packets
as well. So I'd guess it uses some other method of discovering NAT
traversal and negotiating encapsulation.
Another strange thing is that it uses UDP port 10000 on the Concentrator
for tunneling, as specified somewhere in the manual, but opposed to the
UDP encapsulation drafts. The nat-t draft says to switch to 4500, and
the udp-encaps draft tells us to use that same port for encapsulated ESP
as well. But my connection stays on UDP 500 for all ISAKMP and uses
10000 in parallel for some encapsulated data. At least those packets
seem to follow udp-encaps.
The any Vendor ID common in the first ISAKMP packets was Microsoft
L2TP/IPSec VPN Client, 4048B7D56EBCE88525E7DE7F00D6C2D3C0000000. Maybe
this provides some way of negotiating ESP over UDP. I can find no such
thing in RFC3193, but I don't really know.
Hope someone can shed some light on these mysteries.
Greetings,
Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFA47wN1uxO6mboU6gRApuyAJ4qr9+Lx70FwA6TaawozuOsxnbKuQCcCSuw
y0TNZSUu86b5gY/WtgbWybs=
=VDR7
-----END PGP SIGNATURE-----