[strongSwan] Clarifying behaviour around NAT-T and remapping
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 172.17.128.86 to 126.96.36.199 (160 bytes)
>> Mar 27 15:47:35 stg-vault-zk04 charon: 07[NET] <stg-vault-zk06_0|318> received packet: from 188.8.131.52 to 172.17.128.86 (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 to 184.108.40.206 (524 bytes)
>> Mar 27 15:47:35 stg-vault-zk06 charon: 03[NET] sending packet: from 10.0.0.59 to 220.127.116.11 (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 .
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