[strongSwan] Clarifying behaviour around NAT-T and remapping
tobias at strongswan.org
Fri Mar 23 18:20:47 CET 2018
> 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.
More information about the Users