Project

General

Profile

Issue #359

Mediation Server Connection

Added by Nicolai Kuntze over 7 years ago. Updated over 7 years ago.

Status:
Feedback
Priority:
Normal
Category:
charon
Affected version:
5.0.4
Resolution:

Description

Some NAT implementations seem to assign for each outgoing connection a new Pseudo Port. This Pseudo Port is unknown to the Mediation Server and is therefore not communicated. The mediation Server always assumes that all traffic is channled through the same port. The following example shows the respective NAT translation table of Bob's router (Mediation Server 141.12.72.217, Alice 84.118.5.87 and Bob 178.4.168.107):

Index     Protocol     Local IP     Local Port     Pseudo IP     Pseudo Port     Peer IP     Peer Port
99      UDP     192.168.61.109     4500     178.4.168.107     4500     141.12.72.217     4500
100     UDP     192.168.61.109     4500     178.4.168.107     4506     192.168.0.20      4500
101     UDP     192.168.61.109     4500     178.4.168.107     4507     192.168.0.19      4500
102     UDP     192.168.61.109     4500     178.4.168.107     4508     84.118.5.87       4500

I think a possible fix is to use "fresh" ports for the Alice to Bob connection as at the first usage local and pseudo port are identical. This "fresh" port could then be communicated by the mediation server. If the first time fails a different port can be chosen (even independently on both sides using a predetermind scheme).

History

#1 Updated by Tobias Brunner over 7 years ago

  • Description updated (diff)
  • Category set to charon
  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner

Some NAT implementations seem to assign for each outgoing connection a new Pseudo Port.

Yes, some implementation do that (FreeBSD, for instance, even randomizes the external ports). If this happens only on one side, the peers might still be able to establish a direct connection, but that will depend on the filter rules employed at the other end (the implementation might drop the packets even if the endpoint stayed the same because packets are now received from an unknown remote port). Some NAT devices even allow administrators to change their behavior in such situations. For instance, my D-Link router provides the following options for NAT endpoint filtering: "Endpoint Independent", "Address Restricted", and "Port And Address Restricted".

The mediation Server always assumes that all traffic is channled through the same port.

The mediation server actually doesn't assume anything. It simply allows clients to request their reflected external endpoint and later exchange a list of endpoints with other peers. It's the clients who decide which endpoints they send to the other peer via mediation server (the reflected endpoint being just one of them). The two peers then simply try to reach the other one by sending packets to every received endpoint. As described in draft-brunner-ikev2-mediation the source of these endpoints is implementation specific (so could easily be extended).

I think a possible fix is to use "fresh" ports for the Alice to Bob connection as at the first usage local and pseudo port are identical. This "fresh" port could then be communicated by the mediation server. If the first time fails a different port can be chosen (even independently on both sides using a predetermind scheme).

I suppose the peers could use the IP address received as reflective endpoint (they still have to find out their public IP address) and combine that with a random port that they will use locally to reach the other peer. This would require using the socket-dynamic plugin in order to being able to use arbitrary source ports. As the port must be known before hand, to send it to the other peer, this might fail even locally, if the chosen port is already in use by another application. And it would only be a fix for this specific type of NAT implementation.

Anyway, to fix such situations reliably a relayed endpoint would be needed, that is, packets would have to be sent over a host that is publicly reachable by both peers, for instance, the mediation server. Unfortunately, neither the Internet Draft nor the implementation were extended with a relaying mechanism, so far. Patches are welcome ;-)

Also available in: Atom PDF