NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: IKEv2/IPsec VPN

On 9/22/2017 3:49 AM, Christos Zoulas wrote:
On Sep 21,  9:18pm, (Chuck Zmudzinski) wrote:
-- Subject: Re: IKEv2/IPsec VPN

| My results show that neither 8 nor current works for the case when the
| windows (or ios or android) L2TP/IPsec VPN client is not behind NAT but
| NetBSD
| L2TP/IPsec server is behind a NAT. In that case, my tests conclusively show
| that the NetBSD kernel, not even 8 and current, implements RFC 3948 "UDP
| Encapsulation of IPsec ESP packets" for the transport mode case, and
| that is why
| private kernel patches that implement RFC 3948 for transport mode are
| necessary
| for the connection to succeed in this case. I have verified this by
| applying my own
| private patches to the netbsd-6 and netbsd-7 kernels that implement RFC 3948
| for the transport mode case and make the connection work when the NetBSD
| L2TP/IPsec server is behind a NAT. My tests also show netbsd does not
| work when
| both the windows, ios or android L2TP/IPsec VPN client and the netbsd
| L2TP/IPsec
| VPN server are behind NAT, again because of lack of implementation of
| RFC 3948
| for the transport mode case in the netbsd kernel, and my test also show
| that patches
| to the netbsd kernel that implement RFC 3948 for the transport mode case
| can fix
| this for the case of both client and NetBSD server behind NAT.

Well, why don't you share those patches? There is also the lack of
ability to multiplex multiple IPSEC tunnels from the same NATed endpoint.
Having said that, you can create a single IPSEC tunnel between two
endpoints that are both NATed provided that you do all the work on the
"server" side in the firewall (i.e. direct all IPSED traffic to that server).
Then the client initiates and all is well. Having said that, I only
tested tunnel mode.

| I suspect if it was the other way around, that is, if the windows (or
| ios or android)
| L2TP/IPsec client is behind NAT but the NetBSD L2TP/IPsec server is NOT
| behind NAT,
| the connection would succeed for all stock netbsd kernels as far back as
| at least
| netbsd-6, as shown in the wiki tutorial page that Christos referred to
| earlier in this
| thread. If one looks carefully at the logs showing a successful
| connection on that wiki
| page, you will see that racoon reports that NAT was detected only for
| the PEER, and not
| for ME. For the common case of a server that is not behind a NAT, this
| is sufficient
| because more often than not it is the client, not the server, that is
| behind NAT.
| For the case Gerard Lally is interested in, which involves substituting
| an IKEv2
| IPsec solution for an OpenVPN solution in a scenario where both ends
| of the secure tunnel are a NetBSD box, the question is whether or not NetBSD
| can handle any issues that NAT traversal might cause. As far as I know,
| OpenVPN
| handles NAT traversal more readily than IPsec does. I think the stock NetBSD
| kernel would work fine for IKEv2 as long as both NetBSD boxes are NOT behind
| NAT, and each would use the racoon2 package for IKEv2. If one or both NetBSD
| boxes are behind a NAT, then it depends on whether or not NetBSD can be
| easily configured to support UDP encapsulation in tunnel mode (RFC 3948),
| because the IKEv2 VPNs use tunnel mode, in contrast to the transport
| mode that
| L2TP/IPsec VPNs use. My tests, which are for L2TP/IPsec which uses IPsec
| transport
| mode, definitively show that no version of the netbsd kernel, not 8 nor
| current,
| nor the earlier versions, supports UDP encapsulation in transport mode,
| for any
| case when a NetBSD box is behind the NAT.
| Based on my reading of RFC 3948, I think it is likely a solution for the NAT
| problem for IKEv2 VPNs which use tunnel mode instead of transport mode
| would be easier than for the transport mode case and would probably not
| require patching the kernel but would just involve setting up the
| security policies
| and NAT rules properly in the configuration files according to the rules
| given
| in RFC 3948 for tunnel mode. This could probably be accomplished using tools
| provided by the racoon2 package and without patching the kernel, although I
| have never tried racoon2 or IKEv2. The transport mode NAT problem is more
| complicated and requires kernel patches because, as RFC 3948 observes,
| the UDP checksum is invalidated by NAT for the transport mode case, and
| the fix for
| this needs to be done in the kernel where the UDP checksum is verified.
| As far
| as I can tell, all versions of netbsd fail to make the corrections to
| the UDP checksum
| called for in RFC 3948, for the transport mode case, and that is why
| L2TP/IPsec
| connections to an L2TP/IPsec NetBSD server located behind a NAT box
| always fail,
| no matter how hard one might try to tweak the configuration files and
| security
| policies.

I believe that the code to fix the checksum is in HEAD, but not in -8
and that in itself is not done efficiently.


Sorry about that long post yesterday - I find I cannot reproduce the result shown on the Wiki page referenced above that uses iphone or android l2tp clients behind NAT and netbsd l2tp server not behind NAT using unpatched kernels, whether 6, 7, 8 or current. But there are some differences still between my setup and the Wiki example -  I am using windows client not android or ios.

I also remember that when I wrote the patches to get my setup to work through a NAT, the code in the kernel that verifies the udp checksum, I think it was in udp_usrreq.c, indicated that the checksum in some configurations is verified in hardware but I don't know if that means some hardware can do the checksum correction described in RFC 3948, but in my setup, which is using netbsd running in a DomU behind a NAT, the xennet virtual network interface is used to connect to the internet and my debugging showed that in my case the checksum verification needs to be done in the kernel. My setup also uses a different l2tp package.

When I get a chance I will try and reproduce the Wiki result of a successful connection without my patches through a NAT by switching to the xl2tpd package as in the Wiki, and also using an iphone instead of windows for the client, and if I still can't reproduce the result of a successful connection with the clients only behind NAT then it's likely that my patches would be helpful in the case when the udp checksum is not verified in hardware but needs to be verified by the kernel.

I didn't share my patches because i was not sure NetBSD wanted to implement RFC 3948 because it had been said a long time ago in another place that it might be encumbered by a patent. I will post my patch for netbsd-7 kernels on a tech-net shortly and we can discuss further over there. The patch uses the NAT original address information from the peer that IKE nat-t extensions provide, as described in RFC 3948.


Home | Main Index | Thread Index | Old Index