2

I am trying to understand how the NAT behaves when two peers behind two NATs with two different public ip Addresses try to establish a TCP connection using simultaneous open. I did some research and found that both peers will get their public mapping through an ICE server and then will exchange their mappings through a rendezvous server before trying to establish the simultaneous TCP open.

What I am trying to understand how is the Peer guaranteed to get the same port Mapping as the one it shared with the other peer?

For Example:

enter image description here

In the diagram host A asks the rendezvous server for the Nat Mapping of Host B gets it and Host B does the same thing. Afterward they try to do a simultaneous TCP open (Assuming they are behind a Full cone Map). The Steps for the simultaneous Mapping 1) Host A sends a SYN packet to IP Y port 100 2) At the same time B will send a SYN packet to IP X port 55

My question is: How is host A guaranteed to get the same External Port mapping, i.e: Port 55 that it shared with Host B through the rendezvous server and How is Host B guaranteed to get the same External Port mapping, i.e: Port 100. In other words, will the NAT always assign the same port mapping to the same (IP, port) unique tuple ?

Assuming of course the NAT supports simultaneous TCP opens and I am talking about dynamic NATs, not NATs with static mappings.

EDIT:

I need to clarify that I am only interested in the behavior of the NAT when this type of simultaneous TCP opens occurs. How would the the "NAT" make it is best effort to make sure that the HOST behind it gets the same mapping it is expecting to get.

Additional Note: The TCP simultaneous open is described in RFC 5382 https://tools.ietf.org/rfc/rfc5382.txt

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Feb 21 '18 at 16:49
1

Your rendezvous server requires some kind of coordination protocol (ICE?) - this could use a token, user name, or something similar to connect both sockets coming from different directions into a virtual session. Their originating port doesn't matter.

However, this is no function of NAT and higher level protocols are off-topic here.

  • Actually I am writing a code for a NAT and I want it to support such simultaneous TCP connections and wanted to understand how would I assign the ports if wanted a peer behind my NAT connect to another peer behind other NAT the also supports simultaneous TCP connections opens. So I am more concerned about the NAT behavior than the behavior of the rendezvous server – Abdullah Saleh Nov 20 '17 at 18:14
  • I don't think your approach can work. With NAT, there is no guarantee for anything except what you have in a given moment. You can't "tie" two TCP connection attempts sending SYNs. You need to terminate both sockets on the rendezvous server and have it copy all data between the sockets. – Zac67 Nov 20 '17 at 18:28
  • It is not "my approach". The approach of simultaneous TCP open is described in RFC5382 (tools.ietf.org/rfc/rfc5382.txt) and I just trying to figure out how it works since the two sides are not guaranteed to get the same mapping as the one they expect to have – Abdullah Saleh Nov 21 '17 at 6:46
  • The scheme in RFC 5382 4.2 sounds fairly theoretical: to actually work, the SYNs would have to cross each other in flight and each side would need to know in advance which external port is being used by the other side. How do you do that before you establish communication and without knowing what the NAT router would allocate? I'm pretty sure this isn't in common practice nor would it work in a common environment. Additionally, that concept doesn't use a rendezvous server like in your chart. Your question is exactly right: how can you make this work? I don't think you can. – Zac67 Nov 21 '17 at 18:27
  • Is there any other ways to establish a peer to peer connection with both peers behind the NAT? how do applications like bittorrent work ? – Abdullah Saleh Nov 24 '17 at 6:55
1

You ask "In other words, will the NAT always assign the same port mapping to the same (IP, port) unique tuple ?"

The answer is no, it's entirely up to the NAT device. In the general case it's impossible to guarantee it, as there's usually a 16-bit space of the NAT port, and N hosts inside the NAT with a 16-bit port space. It could try to make it as stable as possible, but usually the outgoing port is pretty unpredictable.

  • So simultaneous TCP open sometimes fail in case The mapping of a host behind the NAT changes by the time the other Host sends a syn (case of peer to peer connection) ? and is there anyway to go around this problem ? – Abdullah Saleh Nov 20 '17 at 17:15
  • 1
    The client sends a SYN through the NAT router which changes the source IP and port and forwards it to the destination. The port can't change after that. The server only ever sees the NAT'ed port. – Zac67 Nov 20 '17 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.