[strongSwan] Clarifying behaviour around NAT-T and remapping

[Tobias Brunner]

Hi Rich,

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

And what happens to port 4500?  Why would there even be further messages
from port 500 for existing IKE_SAs?

If a NAT is detected when the SA is established (even if the port is the
same, the IP changes so a NAT should be detected) racoon should switch
to port 4500 with the third Main Mode message and then keep sending
packets from/to that port (there is no reason to send messages from port
500 later, unless a new SA is initiated).

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

Are these DPD messages?  Or what IKE messages trigger this?  Or is this
actually triggered by ESP-in-UDP messages via a kernel event?  (There is
one if the kernel notices different UDP ports than configured on the
installed IPsec SA.)

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

Check the log for what's actually going on.

> And: If the Azure end was StrongSwan, and ESP-in-UDP packets started arriving at port 500, would StrongSwan process them as ESP?

No, it's not possible to process ESP-in-UDP packets on port 500 as IKE
messages to that port are not sent with non-ESP marker and thus would
get processed as ESP messages.

Regards,
Tobias