Where the Full Cone / Symmetric Classification Comes From
This classic NAT classification comes from RFC 3489, the 2003 document that defined the STUN protocol, and was originally used to explain whether a peer-to-peer connection could get through. Full Cone, Restricted Cone, Port Restricted Cone, and Symmetric are the four categories it introduced. Once it became clear that real-world router and firewall behavior often did not fit neatly into just four buckets, RFC 4787 replaced this scheme in 2007 with more precise "mapping behavior" and "filtering behavior" criteria. Even so, the original four-category classification is still widely used today as an intuitive way to describe how open a NAT is.
Full Cone NAT
Once an internal device sends traffic out from a specific port, any external host can then send traffic back to that same public port and have it forwarded to the device — the most permissive of the four types, since the mapping is not restricted to the original destination. This makes peer-to-peer connections the easiest to establish, but it also leaves more room for an external party to reach a predictable open port, making it comparatively less secure.
Restricted Cone NAT
One step more restrictive than full cone: incoming packets are only allowed through if they come from an IP address the internal device has previously sent traffic to — but the port number is not checked. So a response from a different port on that same IP address will still get through.
Port Restricted Cone NAT
Even more restrictive: incoming packets are only allowed through if both the IP address and the port number match a destination the internal device previously sent traffic to. This is common in home routers, and it is typically what gaming consoles label as "Moderate" NAT type.
Symmetric NAT
Every time the internal device connects to a different destination, it gets assigned a different public port — making the port nearly impossible for an outside party to predict. Because a mapping learned from one peer cannot be reused for a connection to a different peer, STUN-based hole punching tends to fail. This offers the strongest security but the lowest success rate for peer-to-peer connections, and is typically what gaming consoles label as "Strict."
Why NAT Type Matters for P2P and Video Calls
WebRTC video calls, VoIP calls, and peer-to-peer game matchmaking generally use a STUN server to discover each side's public IP and port, then attempt a direct connection (hole punching). This works well when both sides are behind some form of cone NAT, but if even one side is behind symmetric NAT, the port the other side discovered will not actually be reusable, and the direct connection fails. In that case, the app falls back to relaying traffic through a TURN server, which adds latency and consumes the relay server's bandwidth.
Improving Your NAT Type
A "double NAT" situation — where your router sits behind another NAT, such as your ISP's modem — tends to produce a more restrictive NAT type. Switching the ISP-side equipment to bridge mode to collapse this down to a single NAT layer, then forwarding the necessary ports directly on your router (or enabling UPnP), can often shift the NAT type that consoles and calling apps detect toward something more open.