NAT – How NAT Decides Inbound and Outbound Connections

layer4nat;protocol-theorytcptransport-protocol

I'm building a P2P application that needs to be able to access nodes behind a NAT. This NAT does not allow inbound connections, therefore the nodes outside the network cannot reach out to the nodes behind the NAT.

My solution to this problem is that the node behind the NAT would reach out to the node outside, and the node outside, when the time is ready, connect to the node that is inside the NAT by using that pre-established TCP connection. Since this connection would be established by the node inside the NAT, this would not be blocked by the NAT.

Here's my question. I do not know which of the interpretations underlined are correct, or if both are wrong.

Interpretation #1

There is a concept of a TCP connection, effectively a tube, and when a node inside the NAT makes a request to anything on the outside world, that tube opens, the response is put into it, and the tube closes forever.

Result: The NAT will not allow any further TCP connections to the client from the node outside after that tube closes.

Interpretation #2

There is no such thing as a TCP connection, but, a TCP transmission. Since a TCP connection is defined as a local ip:port, and a remote ip:port, after a node behind the NAT calls a node outside, the node outside can call back using the same port the client made the request from, and that would "count" as the same TCP connection, not an unsolicited call in by the NAT.

Result: The NAT effectively guesses whether this connection was a response to what the node inside the NAT asked for by looking at the historic record. Since the node behind the NAT made the first call out, the node outside can call back in using the same client port and it would work.

My mental model was closer to #1, but when I inspected the connections with Wireshark, they did appear as separate TCP connections, or at least as separate entities.

Is it closer to #1, or #2, or am I hopelessly confused?

Best Answer

TCP is a connection-oriented protocol, and it can only communicate through connections.

Before you start programming using TCP, it would be helpful to first understand how TCP works, and you should start with RFC 793, Transmission Control Protocol, which is the definition of TCP.

The RFC explains sockets and connections:

Multiplexing:

To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections.

The binding of ports to processes is handled independently by each Host. However, it proves useful to attach frequently used processes (e.g., a "logger" or timesharing service) to fixed sockets which are made known to the public. These services can then be accessed through the known addresses. Establishing and learning the port addresses of other processes may involve more dynamic mechanisms.

Connections:

The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides.

When two processes wish to communicate, their TCP's must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses.

Since connections must be established between unreliable hosts and over the unreliable internet communication system, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections.

As far as the outside TCP peer is concerned, it is connecting to the outside address of the NAT device, even though that device is forwarding to the other TCP peer on the inside, based on the connection initiated by the inside device.

You can also study RFC 5382, NAT Behavioral Requirements for TCP.

Related Solutions

Brute Force UDP Hole Punch – Is It Possible?

Yes. Yes it is possible. The network has to be able to handle all the packets (without exceptions - packet loss means death), the machines have to be able to send out packets fast enough, the other end must not have "flooding protection" and the address has to not change every time you open a new connection. This method managed to connect my laptop behind my University's WiFi with my friends laptop behind his WiFi and it sent a packet from my home WiFi through my University's symmetric NAT. If you're using a phone, you should probably send packets as fast as possible because phones are slow but with laptops you can synchronize the barrage of UDP packets with Thread.sleep()

/**
 * Shoots empty UDP packets at every port between "start" and "end".
 */
public static void sendBarrage(int start, int end, InetAddress target) {

    final ByteBuffer to_send = ByteBuffer.allocate(0);

    // Start at a random value to avoid re-traversing failed paths on repeated attempts.
    final int starting_point = start + generator.nextInt(end - start);

    // Go from starting_point down to 1024. 
    for (int port = starting_point; port >= start; --port) { 
        try {
            if (made_connection == false) {
                myChannel.send(to_send, new InetSocketAddress(target, port));
            } else {
                break;
            }
        } catch (java.nio.channels.ClosedChannelException cce) {
            Application.printerr("Channel closed while on port: " + port);
            break;
        } catch (IOException e) {
            Application.printerr("Error sending in port: " + port);
            continue;
        }
    }

    // Go from 65535 down to say starting_point, not including starting_point.
    for (int port = end - 1; port > starting_point; --port) { 
        try {
            if (made_connection == false) {
                myChannel.send(to_send, new InetSocketAddress(target, port));
            } else {
                break;
            }
        } catch (java.nio.channels.ClosedChannelException cce) {
            Application.printerr("Channel closed while on port: " + port);
            break;
        } catch (IOException e) {
            Application.printerr("Error sending in port: " + port);
            continue;
        }
    }
}

^ Make sure you call this method in a loop, it might take a few attempts. Keep in mind that this method does NOT work with cell phone tower networks (unless you get insanely lucky and the public ip address does not change). It might work better if one side holds the port open while the other guesses rather than having them both brute force both sides.

Also, if only one side holds the ports open, this method might be good: https://www.goto.info.waseda.ac.jp/~wei/file/wei-apan-v10.pdf

Cisco ASA – Troubleshooting TCP Handshake Failures

By default, the ASA randomizes the sequence numbers in the handshake (to prevent session hijacks). So your sequence numbers don't actually match. You can turn off that feature.

random-sequence-number disable

Best Answer

Related Solutions

Brute Force UDP Hole Punch – Is It Possible?

Cisco ASA – Troubleshooting TCP Handshake Failures

Related Topic