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

[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.