Project

General

Profile

Issue #482

NAT-NAT connection

Added by Nicolai Kuntze over 6 years ago. Updated almost 6 years ago.

Status:
Feedback
Priority:
Normal
Category:
-
Affected version:
5.1.1
Resolution:

Description

Establishing a VPN between two devices each behind a NAT using the mediation server is not functional. NAT routers assign to each internal port a new external port. For example the first connection with 4500 as source is assigned to 4500, the second connection from 4500 is most likely assigned to 4501. This behaviour of routers prevents the mediation server from working.

I would propose to change the behaviour of the mediation server and clients a bit. Instead of originating all connections from 4500 only connect to the mediation server using 4500. The connection to the target could use an arbitarilly choosen port and this port is communicated to the connection target through the mediation server. This scheme should have a good chance to succeed (in the worst case some ports are tried until success or time out).

History

#1 Updated by Tobias Brunner over 6 years ago

  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner

Establishing a VPN between two devices each behind a NAT using the mediation server is not functional. NAT routers assign to each internal port a new external port. For example the first connection with 4500 as source is assigned to 4500, the second connection from 4500 is most likely assigned to 4501. This behaviour of routers prevents the mediation server from working.

That highly depends on the involved routers (see section 4.1.5 and 5 of our thesis from 2006, only available in German). But if the routers on both ends do something like this then, yes, the current solution can not provide a direct connection. Some routers actually provide options to change the NAT and filter behavior in their configuration backends.

I would propose to change the behaviour of the mediation server and clients a bit. Instead of originating all connections from 4500 only connect to the mediation server using 4500. The connection to the target could use an arbitarilly choosen port and this port is communicated to the connection target through the mediation server. This scheme should have a good chance to succeed (in the worst case some ports are tried until success or time out).

Using a random port might be an option, but there is no guarantee that the NAT will preserve it. Another problem is that choosing a random (unused) port is not that easy in the current strongSwan code base. The socket-dynamic plugin might be used for this but it only allocates sockets/ports if packets are sent. So determining the port (if we'd let socket-dynamic allocate it) to communicate it to the other peer would be tricky (we'd actually need a response packet to determine the port). And if the port is chosen randomly before sending any packets it could already be in use by other applications, still, an option would be to chose a few random ports and try all of them.

Anyway, in terms of draft-brunner-ikev2-mediation a Relayed Endpoint would be required to make the solution work reliably in such situations.

#2 Updated by Nicolai Kuntze over 6 years ago

I'm not expecting a guarantee but a 80-90% solution that works with most of the routers out to turn NAT-NAT into a useable feature. All routers I had the fun to try where (i) not configureable and (ii) had this "bad" behaviour.

The mediation server is at the perfect position to communicate the ports between the two devices. I would propose to try first with the 4500 port and if that fails after a certain time to fall back on a randomly chosen port selected by the client. One can do this a couple of times to increase the propability of success.

At the end a Relayed Endpoint can take care of the rest.

#3 Updated by Nicolai Kuntze over 6 years ago

Just to document our thoughts. Would that be a possible solution?

Routers a and b are behind NAT walls. a and b have a connection to the mediation server using port 4500.

a selects random port and communicates the port to b via the mediation server.
a starts a module and opens communication channel to b by sending packets to open a port at the outside of the NAT wall.
a receives port of b via the mediation server and sends packets to be using port 4500 as source and b's port as destination.

a's module behind the random port receives the answers and forwards them to 4500 locally.

#4 Updated by Nicolai Kuntze almost 6 years ago

Another approach to the topic I recently noticed is RakNet (www.raknet.net/raknet/manual/natpunchthrough.html). Could you include their approach into StrongSwan? It would enhance the NAT-NAT feature (even if not every possible case can be covered). I thought it would be nice to use UPnP and also NAT-PMP (RFC6886) in addition to a more flexible port allocation/hole punching to cover at least the most common routers and scenarios.

Also available in: Atom PDF