2

Originally, I thought I intuitively understood why B can't accept TCP connections, however when I read about how P2P applications circumvent this exact problem by using an intermediate peer that is not behind a NAT I get very confused.

For example if B is behind a NAT, and A is not, but still wants to contact B, literature states that A can contact B through a peer C, which is not behind a NAT. But why not just directly contact B, since A and C are effectively equivalent in that they are both without a NAT?

EDIT#1: I have be asked to provide some additional information, however this is a question that sprang up due to my reading about NAT functionality in a textbook (Networking a top-down approach by Kurose/Ross). The following excerpt is the motivation for the question: "... another major problem with NAT is that it interferes with P2P [apps]. Recall... that in a P2P [app], any participating Peer A should be able to initiate a TCP connection to any other participating Peer B. The essence of the problem is that if Peer B is behind a NAT, it cannot act as a server and accept TCP connections"

Then, later on in the textbook, it mentions, quickly, the process of connection reversal/NAT traversal (saying that Peer B can be contacted by A through an intermediate Peer C). Thus leading to my original question. As such I see no need for additional firewall/network topology information.

  • It depends on the version of NAT and how it is configured. You will need to be more specific. Also, please add the router/firewall model and configuration. – Ron Maupin Jul 24 '18 at 22:57
  • You really need to be specific about the NAT version. For example, you should not have the problem you describe using static, one-to-one NAT, but you can have all types of problems with NAPT. I think you probably need to do more research on NAT, which can be a very large (too large to properly deal with here) subject. Given more information, we could probably help you. – Ron Maupin Jul 24 '18 at 23:33
1

A needs to contact B, A is not behind NAT, B is.

We have to assume that B is behind a hide NAT (overload, NAPT per RFC 2663) and doesn’t have the option of creating a static NAT, otherwise A could open a connection to B using the static NAT and in that case there would be no need for C.

The issue is that B cannot accept inbound connections due to the NAT type. With NAPT there are no open inbound ports. Connections are initiated from B through the NAT and B's IP is translated to the IP configured for the NAT. B's port number may also be translated if it is not free on the NAT.

B could of course initiate the connection to A, but if B is the server it would not know that A was trying to contact it, or what address to use to reach A.

It would help if you understood the methods of NAT traversal that are used to allow A to connect to B and then you can see at no point does anything connect inbound to B, in fitting with the restriction NAT places on inbound connections to B:

One simple method to achieve the connection is Relaying:

  • B could contact A, but it doesn’t know A’s IP address
  • A and B both know the IP address of an intermediary device – C (which is not behind NAT)
  • A and B both make outbound connections to C
  • C stitches the two connections together and relays the messages from A to B and vice versa.

Another method is Connection Reversal:

  • B could contact A, but it doesn’t know A’s IP address
  • A and B both know the IP address of an intermediary device – C
  • A and B both make outbound connections to C
  • B can now learn of A's IP address and port
  • B can now make a direct outbound connection to A

With relaying there is a big overhead on C as it is in the data path for all traffic between A and B. With connection reversal, C is only used to learn A's IP address. Once the connection is set up, traffic between A and B is routed direct, bypassing C.

I think the main point of your confusion is due to the first step in each of these methods. Yes, in your specific example, B could contact A directly if it knew which IP:port to connect to, but it doesn't, so either needs to broker the whole connection through a relay server or use an intermediary server to learn the IP:port and then make that connection outbound itself.

There is a lot more detail in RFC 5128 - State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs)

https://tools.ietf.org/html/rfc5128#page-8

There are many methods explained, this could be a variation on 3.1 Relaying

3.1. Relaying

The most reliable, but least efficient, method of implementing peer- to-peer communication in the presence of a NAT device is to make the peer-to-peer communication look to the network like client/server communication through relaying. Consider the scenario in figure 1. Two client hosts, A and B, have each initiated TCP or UDP connections to a well-known rendezvous server S. The Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration, discovery, and relay. Hosts behind NAT register with the server. Peer hosts can discover hosts behind NATs and relay all end-to-end messages using the server. The clients reside on separate private networks, and their respective NAT devices prevent either client from directly initiating a connection to the other.

                       Registry, Discovery
                       Combined with Relay
                             Server S
                        192.0.2.128:20001
                                 |
    +----------------------------+----------------------------+
    | ^ Registry/              ^   ^ Registry/              ^ |
    | | Relay-Req Session(A-S) |   | Relay-Req Session(B-S) | |
    | | 192.0.2.128:20001      |   |  192.0.2.128:20001     | |
    | | 192.0.2.1:62000        |   |  192.0.2.254:31000     | |
    |                                                         |
  +--------------+                                 +--------------+
  | 192.0.2.1    |                                 | 192.0.2.254  |
  |              |                                 |              |
  |    NAT A     |                                 |    NAT B     |
  +--------------+                                 +--------------+
    |                                                         |
    | ^ Registry/              ^   ^ Registry/              ^ |
    | | Relay-Req Session(A-S) |   | Relay-Req Session(B-S) | |
    | |  192.0.2.128:20001     |   |  192.0.2.128:20001     | |
    | |     10.0.0.1:1234      |   |     10.1.1.3:1234      | |
    |                                                         |
 Client A                                                 Client B
 10.0.0.1:1234                                        10.1.1.3:1234

     Figure 1: Use of a Relay Server to communicate with peers

Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them. For example, to send a message to client B, client A simply sends the message to server S along its already established client/server connection, and server S then sends the message on to client B using its existing client/server connection with B.

This method has the advantage that it will always work as long as
both clients have connectivity to the server. The enroute NAT device is not required to be EIM-NAT. The obvious disadvantages of relaying are that it consumes the server's processing power and network
bandwidth, and communication latency between the peering clients is
likely to be increased even if the server has sufficient I/O
bandwidth and is located correctly topology-wise. The TURN protocol
[TURN] defines a method of implementing application agnostic,
session-oriented, packet relay in a relatively secure fashion.

You could also use 3.2 - Connection Reversal which applies more specifically to your case:

3.2. Connection Reversal

The following connection reversal technique for a direct
communication works only when one of the peers is behind a NAT device and the other is not. For example, consider the scenario in figure 2. Client A is behind a NAT, but client B has a publicly addressable IP address. Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration and discovery. Hosts behind a NAT register their endpoints with the server. Peer hosts discover endpoints of hosts behind a NAT using the server.

                      Registry and Discovery
                             Server S
                        192.0.2.128:20001
                                 |
    +----------------------------+----------------------------+
    | ^ Registry Session(A-S) ^     ^ Registry Session(B-S) ^ |
    | | 192.0.2.128:20001     |     |  192.0.2.128:20001    | |
    | | 192.0.2.1:62000       |     |  192.0.2.254:1234     | |
    |                                                         |
    | ^ P2P Session (A-B)     ^     |  P2P Session (B-A)    | |
    | | 192.0.2.254:1234      |     |  192.0.2.1:62000      | |
    | | 192.0.2.1:62000       |     v  192.0.2.254:1234     v |
    |                                                         |
  +--------------+                                            |
  | 192.0.2.1    |                                            |
  |              |                                            |
  |    NAT A     |                                            |
  +--------------+                                            |
    |                                                         |
    | ^ Registry Session(A-S) ^                               |
    | |  192.0.2.128:20001    |                               |
    | |     10.0.0.1:1234     |                               |
    |                                                         |
    | ^ P2P Session (A-B)     ^                               |
    | |  192.0.2.254:1234     |                               |
    | |     10.0.0.1:1234     |                               |
    |                                                         |
 Private Client A                                 Public Client B
 10.0.0.1:1234                                    192.0.2.254:1234

       Figure 2: Connection reversal using Rendezvous server

Client A has private IP address 10.0.0.1, and the application is
using TCP port 1234. This client has established a connection with
server S at public IP address 192.0.2.128 and port 20001. NAT A has
assigned TCP port 62000, at its own public IP address 192.0.2.1, to
serve as the temporary public endpoint address for A's session with
S; therefore, server S believes that client A is at IP address 192.0.2.1 using port 62000. Client B, however, has its own permanent IP address, 192.0.2.254, and the application on B is accepting TCP connections at port 1234.

Now suppose client B wishes to establish a direct communication
session with client A. B might first attempt to contact client A
either at the address client A believes itself to have, namely, 10.0.0.1:1234, or at the address of A as observed by server S, namely, 192.0.2.1:62000. In either case, the connection will fail.
In the first case, traffic directed to IP address 10.0.0.1 will
simply be dropped by the network because 10.0.0.1 is not a publicly
routable IP address. In the second case, the TCP SYN request from B
will arrive at NAT A directed to port 62000, but NAT A will reject
the connection request because only outgoing connections are allowed.

After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate
a "reversed" connection to client B. Client A, upon receiving this
relayed request through S, opens a TCP connection to client B at B's
public IP address and port number. NAT A allows the connection to
proceed because it is originating inside the firewall, and client B
can receive the connection because it is not behind a NAT device.

A variety of current peer-to-peer applications implement this
technique. Its main limitation, of course, is that it only works so
long as only one of the communicating peers is behind a NAT device.
If the NAT device is EIM-NAT, the public client can contact external
server S to determine the specific public endpoint from which to
expect Client-A-originated connection and allow connections from just those endpoints. If the NAT device is EIM-NAT, the public client can contact the external server S to determine the specific public
endpoint from which to expect connections originated by client A, and allow connections from just that endpoint. If the NAT device is not
EIM-NAT, the public client cannot know the specific public endpoint
from which to expect connections originated by client A. In the
increasingly common case where both peers can be behind NATs, the
Connection Reversal method fails. Connection Reversal is not a
general solution to the peer-to-peer connection problem. If neither
a "forward" nor a "reverse" connection can be established,
applications often fall back to another mechanism such as relaying.

3

If you'll forgive the pun, NAT itself is an overloaded term as it can refer to processes happening at layers 3 and 4 (or often both).

In the case of pure L3 NAT there is, by definition, a 1:1 mapping between the translated address and the outside address. Reusing your terms from above, A is a private address that is translated to address E, which is directly reachable from B and C. Packets from A to C are translated such that the NAT gateway emits them apparently sourcing from E. Response traffic from A to E is, of course, translated on its way back through the gateway as A to D. Similarly, any traffic originating from C and bound to E ends up effectively as a connection built from C to A. Put another way, NAT at L3 is bidirectional.

The obvious issue here is that this is completely ineffectual in terms of saving address space and, as such, isn't typically useful for public Internet connectivity. Because of its bidirectionality it's a good mechanism for transitioning between address allocations or interconnecting partially overlapping scopes.

Where NAT does become useful for public Internet connectivity is L4 NAT - or, more commonly, Port Address Translation (PAT). In this case we still have a private source A, a NAT gateway with a public address E and other external hosts B and C. When A connects to C the NAT gateway not only translates the L3 address to E but also actually maintains a state table at L4 - specifically two tuples of (inside source address, destination address, source L4 port, destination L4 port) and (outside / translated source address, destination address, translated L4 source port, destination L4 port). So in our case this would be - for example (A, B, 1023, 80) : (E, B, 1025, 80). Note that the source ports are assumed to be ephemeral. When the server on B responds it will show up as the inverse of the second tuple, or (B, E, 80, 1025), which the NAT gateway can then translate back to (B, A, 80, 1023). This appears to A as a normal response from B and the session continues. Note that this is pretty readily applicable to most TCP or UDP protocols but can get potentially require different rules to handle other protocols (ICMP, etc).

The key advantage here is that a large number of devices can share the NAT gateway's single address. The disadvantage is that the inside host has to initiate the connection for the NAT (or, really, PAT) gateway to understand how to handle response traffic. The NAT gateway has no idea how to handle arbitrary traffic initiated by B. The way to work around this either to have an intermediate node C that both A and B can connect to (...as you point out) or a static rule on the NAT gateway that says that all incoming traffic to the public address E on a particular port/protocol will be translated into private connections back to A (..otherwise known as port forwarding).

This obviously leaves us in a place whee a given port number on the public address can only correspond to a single internal address - so, for example, a connection on port 80 to E only corresponds to some port on A. There's no way to know (at L4) that an inbound connection to E on port 80 should be redirected to A' without additional configuration being made and state information being tracked.

1

There are four ways address translation can occur:

  • Static NAT – Translation of just the IP address where the administrator explicitly defines the IP address after translation
  • Static PAT – Translation of the IP address and Port, where the administrator explicitly defines the IP address and Port after translation
  • Dynamic PAT – Translation of the IP address and Port, where the router determines the new IP address and Port after translation
  • Dynamic NAT – Translation of just the IP address, where the router determines the new IP address after translation

(These go by different names depending on which vendor's document you are reading)

All but one of these types of translation are Bidirectional -- traffic can be be processed by the translation whether it is initiated from an internal host or an external host.

The one that isn't (Dynamic PAT) is Unidirectional -- traffic flows only if the internal host initiated the traffic.

You didn't explicitely indiciate which type of translation you are referring to, but I think it is safe to say you are speaking about a Dynamic PAT. To that end, the question you are actually asking is ...

Why is a Dynamic PAT unidirectional?

To understand, you must first look at how a Dynamic PAT process traffic. First, let's look at outbound traffic:

Practical Networking :: Dynamic PAT :: Outbound

As the internal hosts send traffic through the device configured with a Dynamic PAT, the device translates the Source IP and Source Port, then sends the packet along.

The original packet attributes and translated packet attributes are logged in the translation table.

On the way back in, the return packet is matched against the translation table to determine how to "untranslated" the packet and send it to the correct initiating host:

Practical Networking :: Dynamic PAT :: Inbound Response Traffic

Notice the response traffic of the original request is allowed back through the translation device (the Router, in this case, but many devices can do a Dynamic PAT) because the entry in the Translation table existed.

If, however, traffic is initiated externally towards the Dynamic PAT IP address:

Practical Networking :: Dynamic PAT :: Inbound Initial Traffic

The Router will have no entry in the translation table, and will therefore not know which of the internal hosts (A, B, or C) to send the packet to. Therefore, all the Router can do with it is drop the packet.

  • Traditional NAT is Basic NAT and NAPT, then there is Bi-directional NAT (or) Two-Way NAT, Twice NAT, and Multihomed NAT. There really is a lot to NAT, with a lot of combinations. Your answer is pretty Cisco-specific. For example, Bi-directional NAT actually involves DNS. – Ron Maupin Jul 25 '18 at 4:01
  • @RonMaupin I'm hesitant to get into this with you, because I fear you will take this way outside the scope of the question, or even L3/L4 address translation... so if it goes that route, let's offload to Chat early? Either way... every way you slice it, it still comes down to only the four types of translations I mentioned above. Traditional NAT and Bidirectional NAT are simply designations for types of translations that are arbitrarily unidirectional and bidirectional. Basic NAT with equal number of "private" and "public" addresses is what I describe as Static NAT, and ... – Eddie Jul 25 '18 at 8:42
  • (continued) ... Basic NAT with more "private" than "public" addresses is what I describe as Dynamic NAT. NAPT is what I describe as PAT (translating IP and Port information in a packet. If you map the pre and post translation attributes explicitely to each other you have what I describe as Static PAT, and if you allow the device to determine the pre and post translation attribute mappings you have what I describe as Dynamic PAT. Twice NAT is simply one of the four types of translations I mention above, applied to both "sides" of the packet (source + destination). ... – Eddie Jul 25 '18 at 8:43
  • (continued) ... Multihomed NAT is again one of the four types of NAT I describe above, but spread across multi-homed routers. And ANY time you translate L3 or L4 information in packet which also includes the L3/L4 information in the Application Payload, you will need an Application Level Gateway (ALG) to mimic the translation in the Application Data. DNS is just one example provided by the RFC. By no means is it required. And by no means is it relevent to the question at hand. – Eddie Jul 25 '18 at 8:43

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.