Re: racoon, IKEv1 and multiple ipsec clients behind NAT

[Andrew Cagney <andrew.cagney%gmail.com@localhost>]

On Wed, 19 Oct 2022 at 03:26, Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
>
> On Wed, Oct 19, 2022 at 07:06:39AM +0000, Mathew, Cherry G.* wrote:
> > Hello tech-net,
> >
> > I had a user question about ipsec using racoon.
> >
> > I have racoon running on a static IP, and I'm able to make sharedkey
> > connections to it from multiple clients behind NATs over different
> > ISPs. However, multiple clients behind the same NAT connecting over
> > NAT-D don't seem to be able to work.
> >
> > The symptom I see is that the second connection times out the first one,
> > and the first in-band ppp interface (using xl2tpd) drops.
> >
> > Before posting configs, logs etc, I wanted to ask if we are able to
> > support multiple clients (say behind a residential ISP router NAT)
> > creating independant l2tp/ipsec transport connections (eg: from multiple
> > phone devices etc.)

Is the second device receiving the first device's packets?

> I've been there. If I remember properly, it did work from my home
> (where the NAT router is NetBSD/ipf) but not from another house (where
> the NAT router is the ISP-provided one).
>
> I'm not sure I remeber properly the details but I think it was an issue with
> port numbers: while NetBSD's NAT doesn't special case UDP port 4500 (and
> remap it to something different for each client),
> the ISP-provided one did, and remapped 4500 to 4500 on the public
> interface. So the server sees both clients packets from the same IP
> and the same UDP port (4500) and confuses them.

That would limit things to one IKE SA behind the NAT, yes (NATs seem
to have strange knobs for controlling this).

But even if that works, it's transport mode so the ESP packets have no port.

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.

(of course I could be completely wrong, I refuse to read IKEv1 specs)