List Info

Thread: nat-t openswan interop problem Win2003




nat-t openswan interop problem Win2003
user name
2006-01-03 16:29:45
I have nated client windows server 2003 (Ent) with sp1 and
have NO problem 
with 2.4.0, kernel 2.6.13-server connection on l2tp vpn.
but Connection is lost sometime without any errors(5-50
every minuts). I do 
not know why connection is dropped. This is openswan 2.4.0
problem.



----- Original Message ----- 
From: "Jacco de Leeuw" <jacco2dds.nl>
To: <devopenswan.org>
Sent: Tuesday, January 03, 2006 8:44 PM
Subject: Re: [Openswan dev] nat-t openswan interop problem
Win2003


>
> Martin Schläffer wrote:
>
>> I want to connect on a Linux client with Openswan
2.4.0, Kernel 2.6.12 to 
>> a Windows Server, which is not NATed.
>> The connection uses l2tp and works perfectly with a
Linux client if it 
>> _is_not_ behind a NAT device, or works when
connecting using a Windows 
>> client which _is_ behind a NAT device.
>>
>> But the connection with openswan under linux using
NAT-T cannot be 
>> established, which can be seen in the following
log:
>>
>> 104 "iaik" #1: STATE_MAIN_I1: initiate
>> 003 "iaik" #1: ignoring Vendor ID payload
[MS NT5 ISAKMPOAKLEY 00000004]
>> 003 "iaik" #1: ignoring Vendor ID payload
[FRAGMENTATION]
>> 003 "iaik" #1: received Vendor ID payload

>> [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
>> 106 "iaik" #1: STATE_MAIN_I2: sent MI2,
expecting MR2
>> 003 "iaik" #1: NAT-Traversal: Only 0
NAT-D - Aborting NAT-Traversal 
>> negotiation
>
> Windows Server 2003 does not support the draft-02
vendorid without the
> extra newline character. If you modify Openswan to send
both vendorids
> (the ones with and without the newline) then the NAT-T
negotiation will
> continue.
>
> --- nat_traversal.c.orig        2005-11-24
06:30:37.000000000 +0100
> +++ nat_traversal.c     2006-01-03 11:35:20.000000000
+0100
>  -201,6 +201,7 
>                 if (r) r = out_vendorid(np, outs,
VID_NATT_RFC);
>                 if (r) r = out_vendorid(np, outs,
VID_NATT_IETF_03);
>                 if (r) r = out_vendorid(np, outs,
VID_NATT_IETF_02);
> +               if (r) r = out_vendorid(np, outs,
VID_NATT_IETF_02_N);
>         }
>         if (nat_traversal_support_non_ike) {
>                 if (r) r = out_vendorid(np, outs,
VID_NATT_IETF_00);
>
> This patch is also needed if you connect to Netscreen,
as reported here:
> http://lists.openswan.org/pipermail/users/200
5-December/007609.html
>
> With this patch the NAT-T negotation will succeed but
then you run
> into another problem: "our client ID returned
doesn't match my proposal".
> I used the following patch to print a number of
variables:
>
> --- ikev1_quick.c.orig  2005-10-13 05:55:46.000000000
+0200
> +++ ikev1_quick.c       2006-01-03 15:02:14.000000000
+0100
>  -552,8 +552,15 
>      if (!samesubnet(net, &net_temp)
>      || *protoid != id->isaiid_protoid || *port !=
id->isaiid_port)
>      {
> +        loglog(RC_LOG_SERIOUS,"%s net: 
> %s/%dn",which,ip_str(&(net->addr)),
net->maskbits);
> +        loglog(RC_LOG_SERIOUS,"%s net_temp: 
> %s/%dn",which,ip_str(&(net_temp.addr)),
net_temp.maskbits);
> +        loglog(RC_LOG_SERIOUS,"%s *protoid: 
> %dn",which,*protoid);
> +        loglog(RC_LOG_SERIOUS,"%s
id->isaiid_protoid: 
> %dn",which,id->isaiid_protoid);
> +        loglog(RC_LOG_SERIOUS,"%s *port:         
    %dn",which,*port);
> +        loglog(RC_LOG_SERIOUS,"%s
id->isaiid_port: 
> %dn",which,id->isaiid_port);
>         loglog(RC_LOG_SERIOUS, "%s ID returned
doesn't match my proposal", 
> which);
> -       return FALSE;
> +       /* return FALSE; */
> +       return TRUE;
>      }
>      return TRUE;
>  }
>
> With the following setup:
>
> Openswan 2.4.5rc1 client:    10.0.0.123
> NAT router internal:         10.0.0.1
> NAT router external:         192.168.10.150
> Windows Server 2003:         192.168.10.20
>
> I got these log messages:
>
> #1: initiating Main Mode
> #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY
00000004]
> #1: ignoring Vendor ID payload [FRAGMENTATION]
> #1: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] method 
> set to=106
> #1: enabling possible NAT-traversal with method RFC
3947 (NAT-Traversal)
> #1: transition from state STATE_MAIN_I1 to state
STATE_MAIN_I2
> #1: STATE_MAIN_I2: sent MI2, expecting MR2
> #1: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: i am 
> NATed
> #1: I am sending my cert
> #1: I am sending a certificate request
> #1: transition from state STATE_MAIN_I2 to state
STATE_MAIN_I3
> #1: STATE_MAIN_I3: sent MI3, expecting MR3
> #1: Main mode peer ID is ID_DER_ASN1_DN: 'C=NL, ST=ST,
L=L, O=TESTORG, 
> CN=duron'
> #1: transition from state STATE_MAIN_I3 to state
STATE_MAIN_I4
> #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG 
> cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
> #2: initiating Quick Mode RSASIG+ENCRYPT+DONTREKEY+UP
{using isakmp#1}
> #2: IKE message has the Commit Flag set but Pluto
doesn't implement this 
> feature; ignoring flag
> #2: ignoring informational payload, type
IPSEC_RESPONDER_LIFETIME
> #2: our client net:                10.0.0.123/32
> #2: our client net_temp:           192.168.10.150/32
> #2: our client *protoid:           17
> #2: our client id->isaiid_protoid: 17
> #2: our client *port:              1701
> #2: our client id->isaiid_port:    1701
> #2: our client ID returned doesn't match my proposal
> #2: peer client net:                192.168.10.20/32
> #2: peer client net_temp:           192.168.10.150/32
> #2: peer client *protoid:           17
> #2: peer client id->isaiid_protoid: 17
> #2: peer client *port:              1701
> #2: peer client id->isaiid_port:    1701
> #2: peer client ID returned doesn't match my proposal
> #2: transition from state STATE_QUICK_I1 to state
STATE_QUICK_I2
> #2: STATE_QUICK_I2: sent QI2, IPsec SA established
{ESP=>0x3e27256e 
> <0x8d737967 xfrm=3DES_0-HMAC_SHA1 NATD=none
DPD=none}
> #2: IKE message has the Commit Flag set but Pluto
doesn't implement this 
> feature; ignoring flag
> #2: message ignored because it contains an unexpected
payload type 
> (ISAKMP_NEXT_HASH)
> #2: sending encrypted notification INVALID_PAYLOAD_TYPE
to 
> 192.168.10.20:4500
>
> Ignoring the Commit flag, ISAKMP_NEXT_HASH and
INVALID_PAYLOAD_TYPE
> errors for the moment, could it be a bug in Win2003
where it always uses
> a client ID consisting of the external IP address of
the NAT router?
>
> Jacco
> -- 
> Jacco de Leeuw                        
mailto:jacco2dds.nl
> Zaandam, The Netherlands           http://www.jacco2.dds.nl
>                     Mosquitos suck
> _______________________________________________
> Dev mailing list
> Devopenswan.org
> http:/
/lists.openswan.org/mailman/listinfo/dev 

_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )