Re: IKEv2/IPsec VPN

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

On 9/20/2017 8:48 PM, Chuck Zmudzinski wrote:
> On 9/20/2017 5:12 PM, Christos Zoulas wrote:
>> In article <e8da578e-c03b-7ae6-3062-b0da729dc179%gmail.com@localhost>,
>> Chuck Zmudzinski  <frchuckz%gmail.com@localhost> wrote:
>>> I have used netbsd-6 and netbsd-7 with racoon to set up 
>>> IKEv1/L2TP/IPsec
>>> VPN with Windows clients. I have not tried IKEv2 and based on the 
>>> little
>>> research I have done I don't think it is possible using an out of 
>>> the box
>>> NetBSD/pkgsrc configuration. Even for IKEv1 I needed to hack the NetBSD
>>> kernel to get IKEv1 and IPsec NAT-traversal to work with IPsec, and 
>>> I used
>>> a locally modified version of the ancient and apparently no longer
>>> maintained rp-l2tp package to set up l2tp tunnels. If you don't need 
>>> NAT
>>> traversal, that is, if neither clients nor the server are behind a 
>>> NAT box,
>>> it might be easier to do...
>> In current and 8 it should work out of the box...
>>
>> https://wiki.netbsd.org/tutorials/how_to_create_an_l2tp_ipsec_tunnel_between_an_android_or_iphone_or_ios_device_to_netbsd/ 
>>
>>
>> christos
> I will try 8 and current and post my result in the next few days. I 
> also will try racoon2 with
> IKEv2 sometime with 8 and current. As I understand it, racoon2 is in 
> pkgsrc. It's also good
> to know xl2tpd works for l2tp/ipsec. I have been planning on trying it 
> instead of using the
> ancient rp-l2tp.
>
> Chuck
>
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.

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.

Chuck