[Openswan Users] RE: NAT-t rekey bug manifestation (and typo) in 2.3.0

[Ronald Moesbergen]

> On Fri, 28 Jan 2005, Ronald Moesbergen wrote:
> 
> > Jan 28 09:40:25  "dialup"[2] 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"[4] 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"[4] 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"[4] 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"[4] 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"[4] x.x.x.x:12651 #19: 
> cannot respond 
> > to IPsec SA request because no connection is known for 
> > 82.94.14.100:4500[C=NL, ST=Utrecht, L=Maarn, O=BK Vision 
> International 
> > 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
know.

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?
> 
> Paul
> 

Regards,
Ronald.