[strongSwan] Clarifying behaviour around NAT-T and remapping

[Rich Lafferty]

> On Mar 29, 2018, at 5:46 AM, Tobias Brunner <tobias at strongswan.org> wrote:
> 
> 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?

That’s exactly what’s happening, yes. There’s two different “nat settings" — one to _always_ forward 500/4500 through to the host for incoming packets (static “port forwarding” NAT) and a separate connection-tracking kind of NAT which handles the outgoing connections (and which _usually_ maps 500->500 and 4500->4500 except that sometimes it remaps.)

Azure has, thankfully, abandoned this model in its newer offerings but alas, those aren’t the ones we’re using. 

(Not a VPN gateway, though, all transport mode, full mesh.)

> Since the remote port is now not 500 anymore strongSwan won't switch to
> remote port 4500:

> 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

Aha, those two things were my working theory so it’s good to have them confirmed.

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

I haven’t patched anything. We’re using 5.6.1 from Ubuntu unstable (backported to Trusty/Xenial). I don’t see any relevant patches in the Ubuntu package, but on the other hand, parsing the IKE header _does_ fail, so I think we’re getting expected behaviour.

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

I’ll give both of those a shot and report back. (It’s not clear to me from the NatTraversal page if this will work with IKEv1 but I’ll find out soon enough.)

Thanks!

  -Rich