[strongSwan] Clarifying behaviour around NAT-T and remapping

[Tobias Brunner]

Hi Rich,

> Mar 27 15:47:35 stg-vault-zk04 charon: 14[NET] <stg-vault-zk06_0|318> sending packet: from 172.17.128.86[500] to 13.88.23.150[500] (160 bytes)
> Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET] <stg-vault-zk06_0|318> received packet: from 13.88.23.150[1031] to 172.17.128.86[500] (140 bytes)

Yeah, that's the problem.  Why is a packet first accepted on port 500
and then returned from port 1031?  You wrote Azure has a "less-static
NAT service".  But how does that makes sense?  You configure the NAT to
forward port 500 to your VPN gateway and then it maps the response from
that port to a new external port instead of using the existing static
NAT mapping?

Since the remote port is now not 500 anymore strongSwan won't switch to
remote port 4500:
> Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] <stg-vault-zk06_0|318> local host is behind NAT, sending keep alives
> Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] <stg-vault-zk06_0|318> remote host is behind NAT
> Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] <stg-vault-zk06_0|318> reinitiating already active tasks
> Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] <stg-vault-zk06_0|318>   ISAKMP_VENDOR task
> Mar 27 15:47:35 stg-vault-zk04 charon: 16[IKE] <stg-vault-zk06_0|318>   MAIN_MODE task
> Mar 27 15:47:35 stg-vault-zk04 charon: 16[ENC] <stg-vault-zk06_0|318> generating ID_PROT request 0 [ ID HASH ]
> Mar 27 15:47:35 stg-vault-zk04 charon: 16[NET] <stg-vault-zk06_0|318> sending packet: from 172.17.128.86[4500] to 13.88.23.150[1031] (92 bytes)
> 
> ^ we shouldn't be seeing traffic from 4500 to (1030->500)??? 

Correct, but the code that does the port switch currently checks if the
remote port is 500 and only switches to 4500 if that's the case.  On the
other hand, if we ourselves used port 500 the remote port really can't
be anything else but 500 (even if it is mapped to something else).
Otherwise, we wouldn't have been able to send a message to it as we only
add a non-ESP marker if neither port is 500, so if 1031 was not port 500
our IKE messages would have been processed as ESP messages.

> Mar 27 15:47:35 stg-vault-zk06 charon: 05[NET] <80> received packet: from 54.186.244.242[500] to 10.0.0.59[500] (160 bytes)
> Mar 27 15:47:35 stg-vault-zk06 charon: 05[CFG] <80> looking for an ike config for 10.0.0.59...54.186.244.242
> Mar 27 15:47:35 stg-vault-zk06 charon: 05[CFG] <80>   candidate: 10.0.0.59...54.186.244.242, prio 3100
> Mar 27 15:47:35 stg-vault-zk06 charon: 05[CFG] <80> found matching ike config: 10.0.0.59...54.186.244.242 with prio 3100
> Mar 27 15:47:35 stg-vault-zk06 charon: 05[IKE] <80> 54.186.244.242 is initiating a Main Mode IKE_SA
> Mar 27 15:47:35 stg-vault-zk06 charon: 05[NET] <80> sending packet: from 10.0.0.59[500] to 54.186.244.242[500] (140 bytes)
> Mar 27 15:47:35 stg-vault-zk06 charon: 10[NET] <80> received packet: from 54.186.244.242[500] to 10.0.0.59[500] (524 bytes)
> Mar 27 15:47:35 stg-vault-zk06 charon: 10[CFG] <80>   candidate "stg-vault-zk04_0", match: 1/1/3100 (me/other/ike)
> Mar 27 15:47:35 stg-vault-zk06 charon: 10[IKE] <80> no shared key found for '10.0.0.59'[10.0.0.59] - '(null)'[54.186.244.242]
> 
> ^ I don't understand why this is '(null)'

That's normal for IKEv1 as there is no remote identity yet when looking
up the PSK (unless you configured one in a config and that config was
found based on the IP addresses).

> Mar 27 15:47:35 stg-vault-zk06 charon: 10[NET] <80> sending packet: from 10.0.0.59[500] to 54.186.244.242[500] (524 bytes)
> Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] sending packet: from 10.0.0.59[500] to 54.186.244.242[4500] (36 bytes) 
> 
> ^ I don't know why this packet went from 500 to 4500

Because it received it on that port.  But it's strange that this even
works.  The initiator uses port 4500 and sends to port 1031, so it
should add a non-ESP marker.  However, as responder the non-ESP marker
is currently only stripped from the packet if neither port is 500.  Here
the responder's local port is 500, so the marker is not removed and
parsing the IKE header should fail.  Did you patch that?  If not, what
version are you using?

> Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] received unsupported IKE version 8.14 from 54.186.244.242, sending INVALID_MAJOR_VERSION
> Mar 27 15:47:35 stg-vault-zk06 charon: 15[NET] received unencrypted informational: from 54.186.244.242[4500] to 10.0.0.59[500]
> 
> ^ at this point I believe we're getting ESP-in-UDP packets to 1031->500.

Yep.

I pushed a patch to the port-float branch that might help.  And as a
workaround you could just initiate the connection directly to port 4500
(remote_port=4500), and from port 4500 (local_port=4500).  See [1].

Regards,
Tobias

[1] https://wiki.strongswan.org/projects/strongswan/wiki/NatTraversal