Re: updated win2k client with nat-t: RFC3526 support for FreeS/WAN, plus new unsupported IDs

-----BEGIN PGP SIGNED MESSAGE-----


On Tue, 17 Jun 2003, Chris Teachworth wrote:

> 
> 	When I connect to my freeswan gateway with a roadwarrior behind
> a nat box without nat_traversal=yes everything goes fine. However, when
> I enabled nat-t the negotiation fails when trying to setup the ipsec-sa.
> Has anyone successfully used the new nat-t features in win2k? It seems
> like the windows client is sending an ID type that the freeswan gw
> doesn't understand but I'm afraid this is pretty far over my head. 
> 
> I'm running super-freeswan-1.99.7.3.
> 
> Jun 17 12:04:08 router2 pluto[31538]: packet from 123.123.123.123:500:
> ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000002]
> Jun 17 12:04:08 router2 pluto[31538]: packet from 123.123.123.123:500:
> ignoring Vendor ID payload [4048b7d56ebce885...]
> Jun 17 12:04:08 router2 pluto[31538]: packet from 123.123.123.123:500:
> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
> Jun 17 12:04:08 router2 pluto[31538]: "l2tp-roadwarrior-subnet"[3]
> 123.123.123.123 #3: responding to Main Mode from unknown peer
> 123.123.123.123
> Jun 17 12:04:08 router2 pluto[31538]: "l2tp-roadwarrior-subnet"[3]
> 123.123.123.123 #3: only OAKLEY_GROUP_MODP768, OAKLEY_GROUP_MODP1024 and
> OAKLEY_GROUP_MODP1
> 536 supported.  Attribute OAKLEY_GROUP_DESCRIPTION


Interesting - they are sending something we don't support.  Super 
FreeS/WAN supports:

constants.c:
#define OAKLEY_GROUP_MODP768       1
#define OAKLEY_GROUP_MODP1024      2
#define OAKLEY_GROUP_GP155         3
#define OAKLEY_GROUP_GP185         4
#define OAKLEY_GROUP_MODP1536      5

crypto.c:
    { OAKLEY_GROUP_MODP768,  &modp768_modulus,  BYTES(768)  },
    { OAKLEY_GROUP_MODP1024, &modp1024_modulus, BYTES(1024) },
    { OAKLEY_GROUP_MODP1536, &modp1536_modulus, BYTES(1536) },
    { OAKLEY_GROUP_MODP2048, &modp2048_modulus, BYTES(2048) },
    { OAKLEY_GROUP_MODP3072, &modp3072_modulus, BYTES(3072) },
    { OAKLEY_GROUP_MODP4096, &modp4096_modulus, BYTES(4096) },


I'm guessing this is the new RFC3526 stuff, as Pawel Krawczyk posted about 
a month ago:

http://lists.freeswan.ca/pipermail/sfs-dev/2003-May/000223.html

"Because RFC 3526 was published, we probably want to change the MODP 
group identifiers in Super FreeS/WAN?

ftp://ftp.rfc-editor.org/in-notes/rfc3526.txt

constants.h:
#define OAKLEY_GROUP_MODP1536      5
#define OAKLEY_GROUP_MODP2048      42048
#define OAKLEY_GROUP_MODP3072      43072
#define OAKLEY_GROUP_MODP4096      44096

MODP1536 identifier 5 is now standardized, the others are assigned new 
ids:

#define OAKLEY_GROUP_MODP2048      14
#define OAKLEY_GROUP_MODP3072      15
#define OAKLEY_GROUP_MODP4096      16

And there are new groups defined:

6144 17
8192 18"

And later, JuanJo Ciarlante supplied a patch:

http://lists.freeswan.ca/pipermail/sfs-dev/2003-May/000226.html

which I don't believe is integrated into Super FreeS/WAN at this point.

Chris, if you want, give it a shot and let me know.

JuanJo: did this get merged into 1.99.x tree?  If not, we should probably 
do it on both 1.99.x and 2.x trees.


- -- 
Ken Bantoft                Super FreeS/WAN Maintainer
[email protected]            http://www.freeswan.ca
                           PGP Key: finger [email protected]
"It's one of the things we occasionally must do when dealing
with a computer that tries to be smart" -- D.E. Knuth

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPu+rvViWUusaxGxpAQElPQQAme3dlXFLWMzCsCx2xILi08aqWIlceebl
BMbC8tUteLSRiMhoDJh/Hp4nbyz4oSkFFzsokJ6HlMxdkmUp2gOhXBEUWbQKwKsb
OsO6OMyrTRMPc4d30yzTCcifGBUV7+kI9O63aEoaxNpN5SDsLlZ+aQp10nTb4SdK
4sdpSdTIJd0=
=R3Rc
-----END PGP SIGNATURE-----