On 5/21/2018 7:38 AM, Maxime Villard wrote:
Le 21/05/2018 à 04:43, Chuck Zmudzinski a écrit :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 beingused. 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, itactually is not using non-IKE markers. I observed this behavior for allL2TP/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 andeverything 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 fromthe kernel, also remove it from racoon. Chuck ZmudzinskiIt looks like the problem comes down to this branch [1]. I'm not sure how tofix it.
Yes, that and this branch [2] made me realize I needed to change the isakmp statement for port 4500 to an isakmp_natt statement for port 4500 in the listen directive of racoon.conf. After I did that, racoon was properly setting the socket option for UDP encapsulation of ESP traffic for NAT traversal without non-IKE markers, which is what the RFC calls for.
It is kind of legitimate to ask for non-IKE markers when NATT_00 is compiled; but at the same time, we may compile NATT_00 just because we want to support remote hosts that for some reason use deprecated drafts. The initial intent,in NetBSD, was the second case.
We would have to configure a remote host that uses the non-IKE markers and doesn't use the RFC to test the way the kernel currently deals with that case.
So I suggest we disable ENABLE_NATT_00. This will disable draft-00, in such a way that racoon will never use non-IKE markers. Then we remove ESPINUDP_NON_IKEfrom the kernel.
If we do this, we will find out if the old code was working and someone was relying on it, because this will break it and that person will file a bug report!
Can you recompile racoon without ENABLE_NATT_00 and test again? You should beable to do so by uncommenting the #define in /src/lib/libipsec/config.h. Maxime
It looks to me like that will work. I will try it when I get a chance. I can most quickly test it on NetBSD 7.x because that is the version I am using in my environment, and if that works as expected I will also test it with NetBSD 8 and current and let you know what I find.
I expect using a racoon compiled without support for non-IKE markers and my incorrect racoon configuration with isakmp 192.168.xxx.xxx[4500] instead of isakmp_natt 192.168.xxx.xxx[4500] in the listen directive of racoon.conf will not work, even with my patched kernel, which is as it should be when racoon.conf is configured incorrectly. When I use the correct configuration in racoon.conf, I expect the kernel will correctly process the ESP in UDP traffic even without the non-IKE support in the kernel when using standard clients that use the such as Windows and iPhone.
[2] https://nxr.netbsd.org/xref/src/crypto/dist/ipsec-tools/src/racoon/grabmyaddr.c?r=1.37#168[1] https://nxr.netbsd.org/xref/src/crypto/dist/ipsec-tools/src/racoon/isakmp.c?r=1.78#1648