Re: UDP_ENCAP_ESPINUDP_NON_IKE

[Chuck Zmudzinski <frchuckz%gmail.com@localhost>]

On 5/19/2018 2:52 PM, Chuck Zmudzinski wrote:
> On 5/19/2018 1:04 PM, Maxime Villard wrote:
> > Le 19/05/2018 à 16:57, Chuck Zmudzinski a écrit :
> > > A little more information on my setup from what racoon logs show:
> > >
> > > May 13 12:17:11 ave racoon: INFO: respond new phase 1 negotiation: 
> > > 192.168.xxx.xxx[500]<=>xxx.xxx.xxx.xxx[500]
> > > May 13 12:17:11 ave racoon: INFO: begin Identity Protection mode.
> > > May 13 12:17:11 ave racoon: INFO: received broken Microsoft ID: MS 
> > > NT5 ISAKMPOAKLEY
> > > May 13 12:17:11 ave racoon: INFO: received Vendor ID: RFC 3947
> > > May 13 12:17:11 ave racoon: INFO: received Vendor ID: 
> > > draft-ietf-ipsec-nat-t-ike-02
> > > May 13 12:17:11 ave racoon: INFO: received Vendor ID: FRAGMENTATION
> > > May 13 12:17:11 ave racoon: [68.40.135.16] INFO: Selected NAT-T 
> > > version: RFC 3947
> > >
> > > This is from a Microsoft Windows 10 client, and it reports using RFC 
> > > 3947 for
> > > Nat-t version, yet in the NetBSD 7.x udp_usrreq.c code, my system is 
> > > selecting
> > > the UDP_ENCAP_ESPINUDP_NON_IKE case but I had to edit the skip 
> > > variable for
> > > that case to what skip would be if the INP_ESPINUDP case was 
> > > selected in
> > > udp_usrreq.c to get my setup to work with the windows clients. If is 
> > > confusing
> > > to me, but my patch does work with windows clients but I don't know 
> > > if my
> > > patch breaks other cases.
> >
> > Well, at a first glance it looks like there's a problem with racoon. 
> > If it
> > uses RFC3947, it shouldn't use non-IKE markers.
>
> That's what I was thinking also, but as I said I am using Microsoft 
> clients with the AssumeUDPEncapsulationContextOnSendRule value set to 
> 2 in the Windows registry 
> <https://support.microsoft.com/en-us/help/926179/how-to-configure-an-l2tp-ipsec-server-behind-a-nat-t-device-in-windows>, 
> and maybe that is tricking racoon into using non-IKE markers. I can 
> try Windows clients with that value set to 0 or 1 and see if racoon is 
> still using non-IKE markers.
>
> Next week I will have some time to do some debugging and test my confi 
> guration also with a non-Windows client and see if it is still using 
> non-IKE markers. I can try an iphone client and I also got a NetBSD 
> client that uses racoon to work with my patch but I never checked if 
> it used non-IKE markers in that case. I will let you know what I find.
>
> Chuck Zmudzinski

After some debugging and browsing the source code of racoon I found that 
my racoon was configured in such a way that racoon would report to the 
kernel that it was using non-IKE markers even though non-IKE markers 
were not being used. This happened when in racoon.conf I had something like:

listen
{
    isakmp 192.168.xxx.xxx[500];
    isakmp 192.168.xxx.xxx[4500];
}

Instead of this:

listen
{
    isakmp 192.168.xxx.xxx[500];
    isakmp_natt 192.168.xxx.xxx[4500];
}

According to the racoon.conf man page, a socket will accept 
UDP-encapsulated ESP traffic for NAT-Traversal when using the 
isakmp_natt statement in the listen directive, but not when using the 
isakmp statement. In fact, however, I discovered that NetBSD's racoon 
(NetBSD 7.x) will accept UDP-encapsulated traffic even with the isakmp 
statement for port 4500, but it will report to the kernel that it is 
using non-IKE markers when, as far as I can tell, it actually is not 
using non-IKE markers. I observed this behavior for all L2TP/IPSEC 
clients I tested, including Windows, iPhone, and netbsd/racoon.

When using the isakmp_natt statement for port 4500 in the listen 
directive, racoon works as expected and does not report using non-IKE 
markers and everything works as expected for RFC 3947/3948, for all 
clients I tested, including Windows, iPhone, and a netbsd/racoon client.

The bottom line: I think if we remove UDP_ENCAP_ESPINUDP_NON_IKE option 
from the kernel, also remove it from racoon.

Chuck Zmudzinski