[strongSwan] Clarifying behaviour around NAT-T and remapping

[Rich Lafferty]

Hello again!

I’m still working on getting Racoon and Strongswan talking to each other, and I’ve run into an issue with NAT remapping. The issue is primarily on the Racoon side, but I want to understand Strongswan behaviour to figure out how to move forward because Racoon is long unmaintained and I’m stuck with it for now.

I have a Racoon host in Azure behind SNAT, and a StrongSwan host in AWS (also behind SNAT).

Occasionally, Azure decides to reset all of its SNAT mappings. (AWS doesn’t do this, so you can ignore the AWS side.) After this happens, StrongSwan starts sending both ESP-in-UDP and IKE packets to the newly-mapped 

So step by step:

1. IKE and ESP SAs are established normally with NAT-T, i.e. 500:4500.
2. NAT remapping occurs within Azure, at which point StrongSwan sees IKE packets come from port 1027 instead of 500. (i.e. instead of 500:500 it’s 500:1027).
3. StrongSwan observes that the source port for IKE has changed to 1027, and starts sending both IKE and ESP-in-UDP packets to azure:1027.
4. Racoon sees ESP-in-UDP packets arriving at port 500 and cannot process them.

Step 3 is the one I am least confident in, other than what I’ve seen in tcpdump.

(One challenge I have here is that the Azure SNAT remapping only happens every few DAYS, so it’s very difficult to reproduce.)

So my questions are:

First, am I correctly understanding the behaviour of StrongSwan when NAT remapping occurs? Is this expected StrongSwan behaviour?

And: If the Azure end was StrongSwan, and ESP-in-UDP packets started arriving at port 500, would StrongSwan process them as ESP? (Which is to say, “if I upgraded all of my Azure instances to StrongSwan first would this problem go away?”)

Thanks,
-Rich