IPv4 NAT – Brute Force Search for Symmetric NAT Port Prediction

ipv4nat;network-discovery

Say we have two clients A and B that wish to connect to each other, both behind symmetric NAT's NA and NB respectively. Also there is a rendezvous server S that exists to assist clients A and B with the hole punching process. The literatures says that because NA and NB randomly assign external ports anytime their respective clients initiate a new connection (even if the destination address is the same) the external port information that rendezvous server S swaps between its connecting clients is effectively useless. What i'm wondering is why is it not possible for clients A and B to try the external port information provided by S first and then, if that fails try repeatedly guessing/brute-forcing the external ports.

My guess is that trying all 2^16 ports would take too long or something is going completely over my head and the brute force search would require (2^16)^2 guesses which is completely unfeasible.

Best Answer

why is it not possible for clients A and B to try the external port information provided by S

Because the ports used for talking to S will never be the ports used to talk to either endpoint. A->S will be one port; A->B will be a different port. If NAT is being done correctly, neither port is guessable. The NAT entry maps Src(ip:port)/Dst(ip:port)[inside] to Src(ip:port)/Dst(ip:port)[outside] -- that's 8 numbers that NAT can change. When A changes from S to B, that's a completely new connection with completely new, unknown, external values. STUN/ICE/etc. are counting on the inside-outside src port association remaining the same for multiple destinations.

A and B have no way to know what port was selected by NAT, even if it is "sticky" (as long as the same inside src port is used, NAT uses the same outside src port), unless the same port(s) are used for multiple dst IPs. S only knows what was used to talk to it; if NAT uses a different outside src port, then neither S nor A will know what that port is.

Related Solutions

UDP Hole Punching – NAT Port Distinction for Outgoing Connections

The NAT device will keep a table with currently open connections so that it can send return packets to the internal host that opened the connection. An entry in the state table could look something like this:

Internal Source IP | Internal S-Port | External S-Port | Destination IP | D-Port
192.168.1.12         10123             10123             203.0.113.1      5555

When a packet is received (from the external side) the NAT device will check the Source IP, Source Port and Destination Port of the packet and compare it to the Destination IP, D-Port and External S-Port fields in its connection table. When it finds a match it will forward the packet to Internal Source IP on Internal S-Port.

UDP hole punching depends on the fact that Internal and External Source Ports are the same. This is normally the case unless you have a second internal host that uses the same Source port to connect to the same external Destination/D-Port combination.

When we assume that Internal and External S-Port are the same then both clients A,B can communicate their source port to the rendezvous server which will then relay the information back to the other client respectively.

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

Best Answer

Related Solutions

UDP Hole Punching – NAT Port Distinction for Outgoing Connections

Brute Force UDP Hole Punch – Is It Possible?

Related Topic