RE: NAT-t rekey bug manifestation (and typo) in 2.3.0
Ronald.Moesbergen at bkvision.nl
Mon Jan 31 10:47:14 CET 2005
> On Fri, 28 Jan 2005, Ronald Moesbergen wrote:
> > Jan 28 09:40:25 "dialup" x.x.x.x:12640 #175: ASSERTION
> > FAILED at demux.c:1799: STATE_IKE_FLOOR <= from_state &&
> from_state <=
> > STATE_IKE_ROOF
> So we ended up in some unknown state..... It's strange that
> would only happen in debug mode, since it is not related to
> enabling debuggig or not. I'd be tempted to say it's coincidence.
In the CVS version this assertion still occurs, but there's also good
news, read on ...
> > Jan 28 11:21:08 | no IKE algorithms for this connection
> So this is 2.3.0 right? Not CVS head?
> > Jan 28 11:21:08 "dialup" x.x.x.x:12651 #19: NAT-Traversal:
> > Only 0 NAT-D - Aborting NAT-Traversal negociation
> Michael already commented about this issue. It seems a bug on
> the Windows end. It might cause us to enter that unknown pluto state.
> > Jan 28 11:21:09 "dialup" x.x.x.x:12651 #19: ignoring
> > informational payload, type INVALID_ID_INFORMATION
> I wonder if there is something more we can do. If this msg is
> authenticated, which I think it is at this point, shouldn't
> we terminate the ISAKMP so it can re-establish again from
> scratch? (in this case, it would work around Microsoft's
> rekey bug). Michael?
> > Jan 28 11:25:01 "dialup" x.x.x.x:12651 #19: Virtual IP
> > 10.0.0.151/32 is already used by 'y.y.y.y'
> This is also an interested issue we have no testcase for yet.
> I hope your employees do not all have the same ADSL setup and
> are all using 10.0.0.0/24 internally with a dhcp server that
> gives them att 10.0.0.151 as the first free IP, because then
> you have a big problem.
> But I am not entirely sure how virtual ip and L2TP work
> together. Since L2TP gives you yet another IP to use on the
> windows machine. But I would think the IPsec SA still needs
> that virtual IP.
> > Jan 28 11:25:01 "dialup" x.x.x.x:12651 #19: Your ID is
> > 'C=NL, ST=Utrecht, L=Maarn, O=BK Vision International B.V.,
> > OU=Systeembeheer, CN=HB1, E=***'
> > Jan 28 11:25:01 "dialup" x.x.x.x:12651 #19:
> cannot respond
> > to IPsec SA request because no connection is known for
> > 184.108.40.206:4500[C=NL, ST=Utrecht, L=Maarn, O=BK Vision
> > B.V., OU=Systeembeheer, CN=vpn.bkvision.nl,
> > E=vpn at bkvision.nl]:17/1701...x.x.x.x:12651[C=NL, ST=Utrecht,
> > L=Maarn, O=BK Vision International B.V., OU=Systeembeheer, CN=HB1,
> > E=***]:17/1701===10.0.0.151/32
> This error seems a bit misleading, because it is because of
> the clash of virtual IP's I think.
> > After this, the L2TP connection was terminated. Fortunately
> the user
> > had just enabled Oakley logging, so attached to this email is that
> > oakley.log.
> I'll go read through it, but I believe the problem is a clash
> in virtual IP and a nat-t bug, which we are not handling
> properly with Openswan.
> I see Michael commited some fixes last night, so perhaps the
> CVS version would work slightly better. I haven't looked at
> the actual code changes to see if it fixes all these issues.
I tested the CVS version and the problem seems to have been fixed! I was
able to sustain a connection for more than 2 hours on both pc's and I've
seen several rekeying messages in the log and they all went fine. The '0
NAT-D' message is also gone. I'll do one final test on Friday where I'll
attempt a connection for 8 hours, if that gives trouble I'll let you
Thanks for all your help in getting this fixed, if there's anything I
can provide to solve the debug assertion, let me know.
> I'll see if I can contact Microsoft about this. Your client
> was Windows XP SP2 with automatic updates?
More information about the Users