Re: UDP_ENCAP_ESPINUDP_NON_IKE

["Fr. Chuck Zmudzinski" <brchuck%hotmail.com@localhost>]

On 5/22/2018 11:11 PM, Chuck Zmudzinski wrote:
> On 5/22/2018 12:07 PM, Chuck Zmudzinski wrote:
>> On 5/21/2018 1:07 PM, Maxime Villard wrote:
>>> Le 21/05/2018 à 17:47, Chuck Zmudzinski a écrit :
>>>> 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.
>>>
>>> Yes, and that's a case that we are not supposed to support. Just 
>>> like we're
>>> not supposed to support all the drafts that led to the many RFCs 
>>> available
>>> out there.
>>>
>>>>> 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_IKE
>>>>> from 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!
>>>
>>> What? The kernel code doesn't work in the first place.
>>>
>>> Disabling NATT_00 on racoon under NetBSD does not remove a feature, 
>>> since it
>>> already doesn't work on NetBSD.
>>>
>>> To me the current code in racoon is wrong, it shouldn't 
>>> automatically use
>>> non-IKE markers when there is no NAT-T.
>>
>> Yest, that is definitely a bug in the current code in racoon.
>>
>>>
>>>
>>> And no, there won't be a bug report, for the same reason we didn't 
>>> get a
>>> report in the last 13 years about broken non-IKE markers in the kernel.
>>
>> I agree.
>>>
>>>
>>> (Well, there was one guy that figured this out a few months ago, and 
>>> it was
>>> you.)
>>
>> I actually have been working on this for several years and I forget 
>> exactly what prompted me to post about this problem to the mailing 
>> lists a few months ago, but I am pleased that we are getting this 
>> fixed in NetBSD!
>>>
>>>>> Can you recompile racoon without ENABLE_NATT_00 and test again? 
>>>>> You should be
>>>>> able to do so by uncommenting the #define in 
>>>>> /src/lib/libipsec/config.h.
>>>
>>> note: I meant _commenting_, as you probably understood.
>>>
>>>>>
>>>>> 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.
>>>
>>> Thanks,
>>> Maxime
>>
>> This worked exactly as expected on netbsd-7. I did not test a full 
>> build, but it compiled and ran exactly as expected when I rebuilt in 
>> /src/lib/libipsec and in /src/usr.sbin/racoon on netbsd-7 after 
>> commenting out the #define of ENABLE_NATT_00 in 
>> /src/lib/libipsec/config.h and installing the new racoon and 
>> libipsec.so.3.0 in my netbsd-7 system that is modified with a kernel 
>> that patched the UDP_ENCAP_ESPINUDP_NON_IKE code to deal with my 
>> misconfigured racoon configuration.
>>
>> Results as reported by the racoon log:
>>
>> Before patching racoon:
>>
>> May 20 21:06:12 ave racoon: INFO: respond new phase 1 negotiation: 
>> 192.168.xxx.xxx[500]<=>xxx.xxx.xxx.xxx[500]
>> May 20 21:06:12 ave racoon: INFO: begin Identity Protection mode.
>> May 20 21:06:12 ave racoon: INFO: received Vendor ID: RFC 3947
>> May 20 21:06:12 ave racoon: INFO: received Vendor ID: 
>> draft-ietf-ipsec-nat-t-ike-02
>> May 20 21:06:12 ave racoon: INFO: received Vendor ID: 
>> draft-ietf-ipsec-nat-t-ike-02
>> May 20 21:06:12 ave racoon: INFO: received Vendor ID: 
>> draft-ietf-ipsec-nat-t-ike-00
>> May 20 21:06:12 ave racoon: INFO: received Vendor ID: DPD
>> May 20 21:06:12 ave racoon: [xxx.xxx.xxx.xxx] INFO: Selected NAT-T 
>> version: RFC 3947
>>
>> After patching racoon by commenting out the #define of ENABLE_NATT_00 
>> in /src/lib/libipsec/config.h:
>>
>> May 20 22:10:08 ave racoon: INFO: respond new phase 1 negotiation: 
>> 192.168.xxx.xxx[500]<=>xxx.xxx.xxx.xxx[500]
>> May 20 22:10:08 ave racoon: INFO: begin Identity Protection mode.
>> May 20 22:10:08 ave racoon: INFO: received broken Microsoft ID: MS 
>> NT5 ISAKMPOAKLEY
>> May 20 22:10:08 ave racoon: INFO: received Vendor ID: RFC 3947
>> May 20 22:10:08 ave racoon: INFO: received Vendor ID: 
>> draft-ietf-ipsec-nat-t-ike-02
>> May 20 22:10:08 ave racoon: INFO: received Vendor ID: FRAGMENTATION
>> May 20 22:10:08 ave racoon: [xxx.xxx.xxx.xxx] INFO: Selected NAT-T 
>> version: RFC 3947
>>
>> Vendor ID draft-ietf-ipsec-nat-t-ike-00 is no longer received from 
>> the remote host, as expected.
>>
>> I also edited my kernel to report if it is using the 
>> UDP_ENCAP_ESPINUDP_NON_IKE branch or the UDP_ENCAP_ESPINUDP branch in 
>> udp_usrreq.c. As expected, now I get this in /var/log/messages:
>>
>> May 20 21:13:53 ave /netbsd: udp4_espinudp: UDP_ENCAP_ESPINUDP is set.
>>
>> It is working correctly now because racoon is not incorrectly telling 
>> the kernel it is using NON_IKE markers.
>>
>> Things get a little more complicated for the case with the patched 
>> racoon and racoon.conf configured incorrectly. To remind you, the 
>> incorrect configuration was that I had the wrong statement in the 
>> listen directive of racoon.conf for port 4500. I used isakmp instead 
>> of isakmp_natt in the listen directive.
>>
>> As I predicted, it does not work in this case, because in this case, 
>> racoon is configured to not do any version of ESP in UDP, so after 
>> phase 1 and phase 2 are negotiated successfully and the ESPINUDP 
>> packets start coming from the remote host, the kernel tries to do 
>> normal UDP processing on them instead of decapsulating them and 
>> sending them for processing by ipsec. The racoon log indicates the 
>> kernel sends the ESP in UDP back to racoon which complains about 
>> packets being too big and after a while the connection attempt fails 
>> and the remote host eventually terminates the connection with an error.
>>
>> Is this a bug? Well, on one hand, we should not support a 
>> misconfigured setup, so it is correct for the connection to fail. On 
>> the other hand, I would argue that it is still a bug in racoon to try 
>> to negotiate a connection based on RFC 3947 and 3948 and actually let 
>> the connection get to the point where the remote host is sending us 
>> ESP in UDP packets that we cannot handle correctly. In this case, I 
>> think the correct behavior is for racoon to detect that it is not 
>> configured correctly to support RFC 3947 and 3948 at startup and at 
>> least log a warning or even exit with an error and report that racoon 
>> is not configured correctly to handle NAT-T connections using RFC 
>> 3947 and 3948. I am working on a patch to racoon to do that. Even 
>> this patched racoon does not provide much useful information in its 
>> log messages to assist in the debugging process. This is why no one 
>> has solved this problem for the last 13 years.
>>
>> Thank you for all your help. I am glad to help get support for this 
>> feature in NetBSD.
>>
>> Chuck
>
>
> Update on my testing. I ran my NetBSD 7 userland including racoon 
> without support for draft-ietf-ipsec-nat-t-ike-00 on an unmodified 
> NetBSD 8.0 RC1 kernel and I was able to connect L2TP/IPSEC clients 
> without any modifications to the NetBSD 8.0 RC1 kernel. This means 
> that  ipsec4_fixup_checksum() in ipsec_intput.c on NetBSD 8.0 RC1 does 
> work in my setup and I won't need to worry about patching NetBSD 8.x 
> kernels to get nat-traversal working for L2TP/IPSEC VPN connections. 
> Next I will try a current kernel and I expect it will work also. As 
> for NetBSD 7, I ask if ipsec4_fixup_checksum() can be ported into 
> netbsd-7. I would rather use a port of the official netbsd solution 
> than my old patch in NetBSD 7.
>
> In my latest tests, though, I noticed something unexpected. With this 
> new setup that has a more correctly configured racoon, I got this in 
> the log when the remote host was using an unpatched racoon on NetBSD 
> (instead of Microsoft Windows):
>
> May 22 21:27:39 ave racoon: INFO: respond new phase 1 negotiation: 
> 192.168.xxx.xxx[500]<=>xxx.xxx.xxx.xxx[500]
> May 22 21:27:39 ave racoon: INFO: begin Identity Protection mode.
> May 22 21:27:39 ave racoon: INFO: received Vendor ID: RFC 3947
> May 22 21:27:39 ave racoon: INFO: received Vendor ID: 
> draft-ietf-ipsec-nat-t-ike-02
> May 22 21:27:39 ave racoon: INFO: received Vendor ID: 
> draft-ietf-ipsec-nat-t-ike-02
> May 22 21:27:39 ave racoon: INFO: received Vendor ID: 
> draft-ietf-ipsec-nat-t-ike-00
> May 22 21:27:39 ave racoon: INFO: received Vendor ID: DPD
> May 22 21:27:39 ave racoon: [xxx.xxx.xxx.xxx] INFO: Selected NAT-T 
> version: RFC 3947
>
> With the NetBSD/racoon client, our racoon that is not supposed to have 
> support for draft-ietf-ipsec-nat-t-ike-00 compiled in still recognizes 
> that deprecated version when logging information while it was 
> negotiating phase 1. I do not see this with Windows clients and the 
> new racoon. I saw it with Windows clients and the old racoon. So that 
> is a little weird. I think we at least have a functional setup now, 
> but I am sure it will still be very buggy.
>
> Chuck
>

Last update on my testing of the proposed racoon patch:

I tested a NetBSD 8.0 RC1 kernel with the attached patch to udp_usrreq.c 
that comments out the branch that processes packets with the 
UDP_ENCAP_ESPINUDP_NON_IKE socket option to test what would happen if we 
remove that from the kernel, and ran my NetBSD 7 system on it with the 
unpatched racoon and with our racoon that has support for ENABLE_NATT_00 
removed. As expected, with the old racoon, the connection attempt fails 
on this kernel because of the bug in racoon that mistakenly causes the 
kernel to use that branch of the kernel that I removed in this kernel. 
Also, as expected, our patch to racoon that removes support for 
ENABLE_NATT_00 fixes the problem on this kernel without 
UDP_ENCAP_ESPINUDP_NON_IKE so I think this solution will work on NetBSD 
8.x. This is good news.

The bad news: I started testing with a recent current kernel downloaded 
from daily snapshots. It is about a week old. I ran my NetBSD 7 system 
on that current kernel with the new racoon without support for 
ENABLE_NATT_00, and as expected it connected fine because it still has 
the branch that processes UDP_ENCAP_ESPINUDP_NON_IKE packets. However, 
as soon as I disconnected the VPN connection on the remote host, the 
current kernel crashed. I could not recover the log to see what happened 
when I rebooted after the crash.

I think I have done enough testing to show that our patch to racoon is a 
good place to begin, but if you want to test this on the current kernel, 
be prepared to deal with kernel crashes. I guess that is always true 
when using current kernels...

Chuck

--- udp_usrreq.c.orig	2018-05-22 15:29:56.078274000 -0400
+++ udp_usrreq.c	2018-05-23 14:04:52.850788000 -0400
@@ -1303,21 +1303,21 @@
 		if ((len <= sizeof(struct esp)) || (*st == 0))
 			return 0; /* Normal UDP processing */
 
 		skip = sizeof(struct udphdr);
 	}
-
+#if 0
 	if (inp->inp_flags & INP_ESPINUDP_NON_IKE) {
 		u_int32_t *st = (u_int32_t *)data;
 
 		if ((len <= sizeof(u_int64_t) + sizeof(struct esp))
 		    || ((st[0] | st[1]) != 0))
 			return 0; /* Normal UDP processing */
 
 		skip = sizeof(struct udphdr) + sizeof(u_int64_t);
 	}
-
+#endif
 	/*
 	 * Get the UDP ports. They are handled in network 
 	 * order everywhere in IPSEC_NAT_T code.
 	 */
 	udphdr = (struct udphdr *)((char *)data - skip);