Ability to set a "public" address to be used in NAT detection.

[jkroonza]

Is your feature request related to a problem? Please describe.

Need to set up IKE+ESP (not NAT-T) on an endpoint that sits behind a 1:1 NAT. Meaning single public IP DNATs to a private "internal" IP.

Due to remote side we unfortunately cannot use NAT-T in this setup.

Having looking at src/libcharon/sa/ikev2/tasks/ike_natd.c I do not see a way to force the address that we say we're sending from to a specific value, although, it doesn't look like this should be excessively difficult to do.

Describe the solution you'd like

Would like an option to put an alternative IP address from the dedected sending in the NAT_DETECTION_SOURCE_IP in the initial IKE frame so that NAT will not be detected.

This can come with seriously big bad red warnings since quite frankly even though I'm suggesting this I think this is a terrible idea.

Describe alternatives you've considered

Tried to convince the remote side to permit NAT-T.

Requested public IP to be assigned on the host itself but the provider refuses.

Proposed an alternative VPN technology but the remote side insists on IPSec.

Additional context

Specific client is still using ipsec.conf rather than swanctl to load initial configuration.

[jkroonza]

I still think this is a potentially useful feature but you're welcome to close this at your discretion. We've managed get the remote side to permit NAT-T.

[tobiasbrunner]

To be honest, I'd rather add an option to disable NAT-T completely.

[jkroonza]

consider a use-case where our "server" also sits behind NAT and we'd like to use NAT-T if the remote client is behind NAT, but avoid NAT-T if not (ie, udp 500+4500 as well as all ESP is forwarded from the public address to the masqueraded server in a 1:1 manner).

I do agree that begin able to completely disable NAT-D (And by implication avoid NAT-T) could be useful and desirable too.

[tobiasbrunner]

I was not thinking about a global option but rather something like encap = never. So you could configure that just for a specific connection/client.

But yes, some mode for 1:1 NATs as responder could be interesting. Although, it would be a bit more effort than just using a specific IP for NAT_DETECTION_SOURCE_IP. We'd have to avoid detecting a NAT ourselves, so we'd have to match the NAT_DETECTION_DESTINATION_IP value sent by the client against potentially multiple values and then use the determined IP when generating the response. There could also be some changes in regards to MOBIKE.

[jkroonza]

Right. So as usual more complex than one thinks unless you know what's really know what's going on.

encap = never (assuming it can be set on a per-peer basis) would solve my original use-case. Probably also the simpler implementation to do.

W.r.t. to the 1:1 NATs, in the specific case I envisioned no traffic except LAN traffic - which in my world won't use IPSec - can reach the server without going through NAT, so an override for whatever the locally detected IP address is would be good enough, but as you rightly say ... that doesn't cover all scenarios.