What's new

How Does Firewall Behave When Using Full Cone NAT?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

HarryMuscle

Senior Member
Does anyone know how the router firewall would behave when using full cone NAT? My understanding of full cone NAT is that it basically opens up dynamic port forwarding from the outside world to the internal device when the internal device initiates a connection. That port forwarding can then be used by anyone on the internet. But does the firewall get involved here in any way? Does it block or filter any connections that for example might be coming from an external device that the internal device never initiated a connection to? If not then it sounds like full cone NAT can lead to quite a large security exposure, is that correct? Sure the port forwards are dynamically created so don't always exist but when they do exist you're opening your device up to the wild west. Or is my understanding flawed?

But if the firewall does get involved and does block external connections that an internal device never initiated a connection to, wouldn't that cause the firewall to turn full cone NAT back into how symmetric NAT works?

Thanks,
Harry
 
My understanding of full cone NAT is that it basically opens up dynamic port forwarding from the outside world to the internal device when the internal device initiates a connection.
What you describe is Port Triggering, not Fullcone NAT.

Port triggering is a mostly obsolete feature that was largely used back in the day by IRC users, so they could open port 113 for inbound connections to the identd daemon whenever they established an outbound connection to port 6667 (the standard IRC port). Iptables had a special target to handle port triggering.
 
What you describe is Port Triggering, not Fullcone NAT.

Port triggering is a mostly obsolete feature that was largely used back in the day by IRC users, so they could open port 113 for inbound connections to the identd daemon whenever they established an outbound connection to port 6667 (the standard IRC port). Iptables had a special target to handle port triggering.
Doesn't full cone NAT allow any other device on the internet to send data to the internal device once the internal device opens a connection on the NAT (assuming the device on the internet knows which port to send the data to)?
 
Doesn't full cone NAT allow any other device on the internet to send data to the internal device once the internal device opens a connection on the NAT (assuming the device on the internet knows which port to send the data to)?
Read the links people posted in your other thread to learn more on how NAT behaves in one mode versus another.
 
Read the links people posted in your other thread to learn more on how NAT behaves in one mode versus another.
I did but I'm not sure what I'm missing in my understanding. Here's a quote from Wikipedia describing full cone NAT:

"Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort."

That's literally the definition of port forwarding. The only difference is that usually port forwards are permanent while this is temporary and dynamic.

Or am I missing something in my understanding?

Thanks,
Harry
 
I did but I'm not sure what I'm missing in my understanding. Here's a quote from Wikipedia describing full cone NAT:

"Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort."

That's literally the definition of port forwarding. The only difference is that usually port forwards are permanent while this is temporary and dynamic.

Or am I missing something in my understanding?

Thanks,
Harry

Full cone NAT is only related to UDP traffic. It is a necessary evil with UDP that does open up a slight security hole, assuming someone tries that specific IP and port on UDP only when it is open and not in use (before it gets torn down due to inactivity).

Application aware NAT deals perfectly fine with common UDP traffic and protocols (such as DNS) so not sure what you're looking to do beyond that.
 
I do not believe this is the case.

Theoretically it doesn't have to be, but that's the only thing it is actually useful for, a workaround to allow it to behave in a somewhat stateful manner like TCP. Only ever seen it referenced as part of STUN (which introduced the concept/name) or configured as part of UDP.

I guess if you created static PAT mappings you could simulate the behavior with TCP but not sure why you'd want to do that. This terminology is mostly depreciated anyway, in reality there is NAT and PAT (both can either be dynamic or static). With dynamic you can have application awareness that will allow certain behavior that typically would have broken NAT (i.e. UDP response, traditional FTP, etc).

All of this is somewhat irrelevant anyway in terms of Asus routers.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top