[strongSwan] Clarifying behaviour around NAT-T and remapping

Rich Lafferty rich at lafferty.ca
Thu Mar 29 16:52:11 CEST 2018

> 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[500] to[500] (160 bytes)
>> Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET] <stg-vault-zk06_0|318> received packet: from[1031] to[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[500] to[500] (524 bytes)
>> Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] sending packet: from[500] to[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.)



More information about the Users mailing list