Re: racoon, IKEv1 and multiple ipsec clients behind NAT

[Chuck Zmudzinski <frchuckz%gmail.com@localhost>]

On 10/23/2022 1:14 AM, Mathew, Cherry G. wrote:
> On October 22, 2022 10:35:51 PM UTC, Chuck Zmudzinski <frchuckz%gmail.com@localhost> wrote:
>
>     On 10/22/2022 4:58 PM, Andrew Cagney wrote:
>
>         On Thu, 20 Oct 2022 at 12:19, Mathew, Cherry G. <c%bow.st@localhost> wrote:
>
>                 Each client will (probably) generate unique client->server and server->client SPIs (identifiers). The server knows these values so should be able to DTRT. On the other hand the NAT is clueless as to who has which inbound SPI so likely just forwards the the packets to the most recent ESP sender. 
>
>             This is my best guess too, but unfortunately I have no way to test because the clients are phones. Would this behavior be theoretically be identical regardless of client type ? (ie; if i added a third client running NetBSD+ raccoon as client) 
>
>         Yes, it's IP all the way down. Getting a NetBSD client involved would definitely make life easier
>
>                 (of course I could be completely wrong, I refuse to read IKEv1 specs) 
>
>             What is the the latest hot stuff ? Wireguard ? I dont see wireguard VPN client options for phones though.... 
>
>         I asked around, apparently the buzzwords to look for are IKEv2 and EAP-MSCHAPv2. Andrew 
>
>
>     I worked with Christos a couple of years ago on exploring porting an IKEv2 client to NetBSD. We thought OpenBSD's iked was the best option because it is actively developed by OpenBSD but unfortunately OpenBSD dropped their work of providing their iked for other platforms, and also racoon2 which has IKEv2 was investigated, but racoon2 is not actively developed anywhere. We had some success with porting OpenBSD's iked to NetBSD but not enough resources to complete the job which would also require either replacing racoon for IKEv1 with OpenBSD's IKEv1 client or otherwise developing a solution to support both IKEv1 and IKEv2, so the effort stalled. Unfortunately I do not have time to continue the effort.
>
>     My tests of both openiked and racoon2 on NetBSD at the time did successfully work to provide a working IKEv2 VPN server on NetBSD current of that time for iphones, Windows clients, etc., but it was far from ready for production use. Also, in my tests both the server and the client could be behind and IPv4 NAT, but it did not support multiple clients behind the same NAT. IKEv2 uses IPSec tunnel mode instead of IPSec transport mode of l2tp packets and PPP to provide an IP tunnel, and it is able to tunnel both IPv4 and IPv6 over the VPN connection, and OpenBSD's iked also provides support for MOBIKE on the server side for more robust connections from clients that also have MOBIKE, such as Windows and iOS VPN clients.
>
>     There are a couple of public github repos for openiked and racoon2 on NetBSD that document the work that was done a few of years ago if anyone is interested in picking up that project and continuing it:
>
>     https://github.com/zmudc/openiked
>     https://github.com/zoulasc/racoon2
>
>     Cheers,
>
>     Chuck
>
>
> Hi Chuck,
>
> That's interesting - I'm looking at this as a user - with several questions (I'm mindful that you've probably answered a subset of them already):
>
> What's the difference between racoon2 and iked feature set wise ? Are either interchangeably usable ? What are the benefits and shortfalls of choosing one over the other ? Can both co-exist ? Can they solve the original problem I had of multiple clients behind IPv4 NAT ?

OpenBSD's iked has many more modern features and is actively developed and used by the OpenBSD community. Racoon2 was developed a long time ago, and as far as I know it was never used except experimentally. I remember I had to add support for certificate authentication to racoon2 which was lacking and you can find the commits that added that in the aforementioned racoon2 repo on github. So if you try racoon2 it will not have other modern authentication mechanism such as EAP-MSChapv2 either, nor will it use modern encryption algorithms which OpenBSD's iked will be more likely to have because it is actively developed currently. I would recommend trying iked and IKEv2 as the more modern and supported option.

The only benefit of racoon2 is that it has support to handle and distinguish IKEv1 and IKEv2 in one daemon, but OpenBSD's iked only supports IKEv2 and OpenBSD has another daemon to support IKEv1, so with OpenBSD's iked and racoon or a port of OpenBSD's IKEv1 daemon to provide IKEv1 on a NetBSD system, further work would be needed if you wanted to support both IKEv1 and IKEv2 on the same server because they both use UDP port 500, so you could only run an  IKEv1 daemon *or* an IKEv2-only daemon (such as iked), but not both simultaneously without some kind of a packet filter to inspect incoming packets and direct them to the correct daemon or by extending the programs to ensure incoming IKE packets are handled by the correct daemon for the IKE version that each connection uses.

As far as solving the original problem of multiple clients behind the same NAT, I remember trying it with racoon and IKEv1 and it does not work with NetBSD because, if I understand correctly, the NetBSD kernel's IPsec implementation cannot distinguish UDP encapsulated IPSec and IKE packets from the same source IPv4  address but actually from different IPSec/IKE connections behind the same NAT because the data that defines the security associations in the kernel includes the source IP address but not the source port when IPSec (esp) is encapsulated in UDP. Maybe someone more knowledgeable can correct me, but I do not think there is a standard for solving that problem.

You will probably want to read and understand RFC 3948 to work on solving the problem for NetBSD: https://www.rfc-editor.org/rfc/rfc3948

The problem is that RFC 3948 only solves the problem of NAT with IPSec, but it does not standardize a way to handle the specific problem of multiple clients behind the same NAT, and I don't think their is a standardized way to solve it.

You will need to do your own research to find a way to solve the problem and you might be able to find some solutions by searching the Internet. Keep in mind that IKEv2 uses IPSec tunnel mode IPSec, so the problem might not be exactly the same if you try to use IKEv2 instead of IKEv1/L2TP/IPsec which uses transport mode IPSec. I know about Linux/Strongswan's solution to the problem which is saref in the Linux kernel Netkey IPsec implementation, but I don't know if that only works for L2TP/IPSec/IKEv1 or for IKEv2 also, and I also don't know if that solution is compatible with the standard VPN clients on iOS, android, macOS, Windows, etc. That solution also would be difficult to port to NetBSD because it uses Linux kernel Netkey for IPSec in the kernel, but the NetBSD kernel uses pfkeyv2.

I think perhaps a better approach for NetBSD is the one described in the link I posted earlier: https://forum.mikrotik.com/viewtopic.php?p=652517

If I understand correctly (and I might not understand correctly), that approach uses packet filtering to do SNAT (source IP address NAT) on incoming espinudp packets (and IKE packets also, I presume) with the same IP address but different source ports so that each connection from behind the same NAT will appear to have a unique source IP address. Then the NetBSD kernel will be able to distinguish the different connections from behind the same NAT because they will appear to be coming from different IP addresses. The packet filter would need to implement the ugly kludges that are necessary to make IPSec work with NAT as described in RFC 3948.

As others have mentioned, it is much easier to use IPv6 and do away with trying to make IPSec work with NAT, but the more inexpensive options from the Internet service providers might not provide that capability, so in that case it is still needed to implement the kludges to make IPSec work with NAT.

Cheers,

Chuck