Why doesn't WebRTC work with Symmetric NAT?

Question

Let's say we have two peers - A & B - trying to establish a WebRTC peer connection through Symmetric NAT. They exchanged the ICE candidates via signalling.

A's public address: IP_A : Port_A
B's public address: IP_B : Port_B

First, A tries to connect to B
IP_A : Port_A ---> IP_B : Port_B

The request is however rejected by B's NAT. Only B's STUN server can connect B at that address.

Next it's B's turn.
IP_B : Port_B ---> IP_A : Port_A

But here, shouldn't the connection be established? Because, Peer A's NAT table should have registered Peer B's address when A first sent request to B. So, any response from B must be accepted. But of course, it doesn't seem to work. So, where am I wrong?

Answer 1

I think I found the answer myself. Symmetric NAT is even more restrictive than I thought. Look at the Wikipedia explanation,

Symmetric NAT

• Each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port; if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used.
• Only an external host that receives a packet from an internal host can send a packet back.

The problem is, Symmetric NAT will use a different IP : Port combination for Peer A while sending a request to Peer B than the IP_A : Port_A combination provided by the STUN. But Peer B's remote description still points to IP_A : Port_A. So, the addresses don't match and connection never happens. Perhaps a port prediction system could still make this work I assume :D

Answer 2

It makes a lot more sense if you think in terms of Mapping/Filtering. The other NAT terms don't do a good job of describing how things actually work. My answer comes from RFC 4787 and WebRTC for the Curious: Connecting

Mapping is when your NAT allocates a IP/Port for an outbound packet. A remote peer can the send traffic to this mapping. Filtering are the rules around who can use these mappings.

Filtering and Mappings can then be address dependent and independent. If a mapping is address dependent it means a new mapping is created for each time you contact a new IP/Port. If a mapping is address independent it means it is re-used no matter where you send traffic. These same rules apply to filtering.

---

To your original question it looks like address dependent mapping+filtering is causing an issue!

I would still expect things to work in the setup you describe. WebRTC has Peer Reflexive Candidates. WebRTC can discoverer new candidates during ICE connectivity checks. Since ICE is authenticated we can accept traffic from IP/Ports that haven't been exchanged, we just need to assert the ICE userfragment and password is what we expect.