I think it's due to key re-negotiation maybe? You might be
able to
make it work by setting the rekey interval to a very large
number.
On 1/3/06, Dmitriy <ddmk r66.ru> wrote:
> 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
>
--
- Norman Rasmussen
- Email: normanrasmussen.co.za
- Home page: http://norman.rasmusse
n.co.za/
_______________________________________________
Dev mailing list
Devopenswan.org
http:/
/lists.openswan.org/mailman/listinfo/dev
|