NAT-OA patch, was Re: [Openswan Users] OpenSwan 2.3.0 L2TP response in plaintext

[Jacco de Leeuw]

>>> Forgot to mention, perhaps this patch by Bernd Galonska fixes
>>> the problem?
> 
> (Which was a NATed server with L2TP/IPsec Windows Road Warriors).
> 
>>> http://lists.openswan.org/pipermail/users/2005-February/003927.html
>>
>> The patch is still in the queue to be investigated and applied in some 
>> form or shape.
> 
> But what I don't understand is why removing the NAT-OA fixes the problem.
> The RFC says it MUST be send in transport mode. Is Microsoft way off here?

The NAT-T RFC 3947 says:

   Initiator <------> NAT1 <---------> NAT2 <-------> Responder

   In the case of transport mode, both ends MUST send both original
   Initiator and Responder addresses to the other end. The[se] NAT-OA
   payloads are sent inside the first and second packets of Quick Mode.

But Microsoft implemented draft-02 which says:

   In case of transport mode both ends SHOULD send the original source
   address to the other end.

So I wonder why Windows chokes on this NAT-OA payload if draft-02 says
that it SHOULD be able to process the message...

Jacco
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl