[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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:
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
May 13 12:17:11 ave racoon: INFO: received Vendor ID: RFC 3947
May 13 12:17:11 ave racoon: INFO: received Vendor ID:
May 13 12:17:11 ave racoon: INFO: received Vendor ID: FRAGMENTATION
May 13 12:17:11 ave racoon: [188.8.131.52] INFO: Selected NAT-T
version: RFC 3947
This is from a Microsoft Windows 10 client, and it reports using RFC
Nat-t version, yet in the NetBSD 7.x udp_usrreq.c code, my system is
the UDP_ENCAP_ESPINUDP_NON_IKE case but I had to edit the skip
that case to what skip would be if the INP_ESPINUDP case was
udp_usrreq.c to get my setup to work with the windows clients. If is
to me, but my patch does work with windows clients but I don't know
patch breaks other cases.
Well, at a first glance it looks like there's a problem with racoon.
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
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.
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:
Instead of this:
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.
Main Index |
Thread Index |