Issue #359
Mediation Server Connection
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 8 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 ;-)