On Sep 21, 9:18pm, frchuckz%gmail.com@localhost (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.
christos