Why many routers use symmetric NAT / Advanatges of symmectric NAT

[ndrp]

Many routers use symmetric NAT. Wikipedia says that symmetric NAT tends to be found in large corporate networks. Many web pages tell about disadvantages of symmetric NAT, basic NAT traversal does not work between two symmetric NAT or between symmetric NAT and port restricted cone NAT [1]. I have not found any documents describing advantages of symmetric NAT.

So why symmetric NAT might be better than full cone NAT, restricted NAT or port restricted NAT?

NAT analyser: http://nattest.net.in.tum.de/index.php

[1] Chapter 5, https://tools.ietf.org/id/draft-takeda-symmetric-nat-traversal-00.txt

 

[sfx2000]

Wow, that's a blast from the past - the internet draft is from '03, and I was following that whole effort...

Basically, consumer grade routers implement Symmetric NAT because

1) It's easy to do
2) Not so many clients behind a residential device

So not so much downside - but it falls apart when dealing with many clients, and perhaps NAT's behind NAT's, and there, the overhead gets to be a big problem - mostly for applications outside that need to talk to clients that are behind the NAT's - it's what many refer to as "hole punching"

Consider that you have a SIP VOIP client on your laptop (not Skype, they have their own way), one fires up the App, it registers with the SIP server out on the public internet - this establishes the initial NAT rule thru the NAT, and perhaps also thru the firewall... make a call, and everything is good...

One doesn't even need to build port forwarding rules for that...

Now, later on someone else calls the SIP client, if the NAT rule isn't in place, it will be essentially blocked, and the SIP page will fail - remember in Symmetric NAT's, the port must be reserved, and that reservation will take up memory on the NAT gateway, so most of the time, they are not persistent and are flushed from memory...

The way around that is to build a static port forward rule, and then the incoming SIP page will always make it back to the VOIP client...

That also becomes a problem, because let's say in a Carrier/Enteprise network, one can have hundreds, if not tens of thousands of SIP clients, and each would have to have a static rule...

See the problem?

Takeda explains the problem well enough... and follow on efforts in the SIP, STUN, TURN, and ICE have solved many of the problem with NAT traversal - not all of the problems, but many of them...

 

[ndrp]

Basically, consumer grade routers implement Symmetric NAT because

1) It's easy to do
2) Not so many clients behind a residential device

So not so much downside - but it falls apart when dealing with many clients, and perhaps NAT's behind NAT's, and there, the overhead gets to be a big problem - mostly for applications outside that need to talk to clients that are behind the NAT's - it's what many refer to as "hole punching"

Consider that you have a SIP VOIP client on your laptop (not Skype, they have their own way), one fires up the App, it registers with the SIP server out on the public internet - this establishes the initial NAT rule thru the NAT, and perhaps also thru the firewall... make a call, and everything is good...

One doesn't even need to build port forwarding rules for that...

Now, later on someone else calls the SIP client, if the NAT rule isn't in place, it will be essentially blocked, and the SIP page will fail - remember in Symmetric NAT's, the port must be reserved, and that reservation will take up memory on the NAT gateway, so most of the time, they are not persistent and are flushed from memory...

The way around that is to build a static port forward rule, and then the incoming SIP page will always make it back to the VOIP client...

That also becomes a problem, because let's say in a Carrier/Enteprise network, one can have hundreds, if not tens of thousands of SIP clients, and each would have to have a static rule...

See the problem?

How is this a symmetric NAT specific problem? Port restricted NAT have to keep track of al used ports but does not change port number (router's eAddr:ePort, https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation) if LAN client use same destination address and connects to a new server. Is it easier or harder to manage connections when ports are changed?

Isn't restricted NAT even more simple than symmetric and port restricted NAT? Restricted NAT doesn't need to check source port when packets are coming from Internet. This looks less secure thatn port restricted or symmetric NAT.

PS. I'm NAT newbie

 

[sfx2000]

How is this a symmetric NAT specific problem? Port restricted NAT have to keep track of al used ports but does not change port number (router's eAddr:ePort, https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation) if LAN client use same destination address and connects to a new server. Is it easier or harder to manage connections when ports are changed?

Isn't restricted NAT even more simple than symmetric and port restricted NAT? Restricted NAT doesn't need to check source port when packets are coming from Internet. This looks less secure thatn port restricted or symmetric NAT.

It doesn't scale very well...

It's perfectly fine for a Home/Small Business Network, but when building out to Enterprise/Carrier level, symmetric NAT's run out of resources...

 

[htismaqe]

Symmetric NAT fails in a corporate environment fairly quickly.

In most enterprises, you'll be using more than one type of NAT anyway. 1:1 NAT for DMZ/portal apps facing the internet, symmetric for some user blocks, etc.

 

[htismaqe]

As a self-professed NAT n00b, I would recommend you read the Wiki page just below the table describing the NAT types:

This terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior.[2] Many NAT implementations combine these types, and it is therefore better to refer to specific individual NAT behaviors instead of using the Cone/Symmetric terminology. Especially, most NATs combine symmetric NAT for outgoing connections with static port mapping, where incoming packets addressed to the external address and port are redirected to a specific internal address and port. Some products can redirect packets to several internal hosts, e.g. to divide the load between a few servers. However, this introduces problems with more sophisticated communications that have many interconnected packets, and thus is rarely used.

 

[ndrp]

Especially, most NATs combine symmetric NAT for outgoing connections with static port mapping, where incoming packets addressed to the external address and port are redirected to a specific internal address and port.

Isn't that just a symmetric NAT and a port forwading or DMZ?

Netgear MR314: Full Cone NAT for UDP and Symetric NAT for TCP
http://www.voip-info.org/wiki/view/NAT+survey

Port restricted NAT seems to be the most commom NAT type. http://nattest.net.in.tum.de/results.php

 

[ChatmanR]

So then, Full Cone is best in a home environment with 30-50 devices connected at any time? I'm using the AC86U with 384.14_2.

 

[cplay]

So then, Full Cone is best in a home environment with 30-50 devices connected at any time? I'm using the AC86U with 384.14_2.

I believe that to be the general consensus.
@RMerlin, @Val D. , @L&LD , @OzarkEdge , thoughts for home networks based on speed and compatibility of cone vs symmetric?

 

[OzarkEdge]

I believe that to be the general consensus.
@RMerlin, @Val D. , @L&LD , @OzarkEdge , thoughts for home networks based on speed and compatibility of cone vs symmetric?

I'm no expert on routing... but I am pretty good with a map and compass (Internet and Google)...

Here's a link that briefly summaries NAT considerations as they might relate to VoIP which is an increasingly common, router/NAT sensitive real-time application:
https://wiki.4psa.com/display/KB/SIP+protocol+and+NAT+problems

VoIP prefers a restricted-cone NAT (to prevent anonymous SIP) and reduced registration times. And I've had issue with my Line3+Line4 ATA using UDP and not maintaining registration over a wireless AiMesh backhaul... switching it to TCP transport seems to cure this. Meanwhile, my L1+L2 ATA on the AiMesh router maintains registration with the same service provider using the default UDP transport.

OE

 

[cplay]

I'm no expert on routing... but I am pretty good with a map and compass (Internet and Google)...

Here's a link that briefly summaries NAT considerations as they might relate to VoIP which is an increasingly common, router/NAT sensitive real-time application:
https://wiki.4psa.com/display/KB/SIP+protocol+and+NAT+problems

VoIP prefers a restricted-cone NAT (to prevent anonymous SIP) and reduced registration times. And I've had issue with my Line3+Line4 ATA using UDP and not maintaining registration over a wireless AiMesh backhaul... switching it to TCP transport seems to cure this. Meanwhile, my L1+L2 ATA on the AiMesh router maintains registration with the same service provider using the default UDP transport.

OE

I'm pretty good with a map and compass too

Cheers for the link and explanation of your setup!