PfSense & Full Cone NAT
-
Strange to me that the default NAT type is:
Stun Status: Symmetric NAT
I use version 2.1-DEVELOPMENT (i386) built on Fri Nov 25 14:30:42 EST 2011 FreeBSD 8.1-RELEASE-p6
Where I'm wrong? -
Going by Wikipedia's definition.
"Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent through eAddr:ePort.
Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort."Edit: we don't do that (note the "ANY external host") and no one should ever do that.
Our default NAT is Symmetric NAT. It's perfectly fine for SIP in most all cases, it's used and recommended by numerous VoIP providers.
-
cmb … on wiki definition, full cone is akin to 1:1 NAT. This is not done by default in pfSense. The default behavior of pfSense is more like the symmetric, wouldn't you say?
This is why there are proxies for SIP. Which work great and one of the many reasons I use pfSense.
If you need full cone, you can set that up in 1:1 NAT area. -
They don't mean 1:1 NAT in that definition in the way that we and other similar firewalls refer to 1:1 NAT.
-
Does pfSense supports Full Cone NAT, or not?
I ask because it is very important for the proper working of SIP applications.
Thanks in advance.AFAIK pf (the packet filter used by pfsense) implements symmetric NAT, the most restrictive (and secure) type of NAT.
Check http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-3/anatomy.html for the differences.
Wrt SIP there are several NAT traversal technologies (STUN, ICE etc) used by different VoIP software.
-
@cmb:
Going by Wikipedia's definition.
"Once an internal address (iAddr:iPort) is mapped to an external address (eAddr:ePort), any packets from iAddr:iPort will be sent through eAddr:ePort.
Any external host can send packets to iAddr:iPort by sending packets to eAddr:ePort."The key is the last part. With pf's outbound NAT, only the external host that the internal host attempted to access can send packets back to the internal host through the entry in the state table. Full Cone NAT allows any external host to use the existing state table entry to access the internal host, kind of like a temporary port forward. By the definition you posted, pf is definitely not doing Full Cone NAT.
-
ah yes I glanced over that description WAY too quickly. Definitely not any source, that would be very, very bad. Edited my earlier post.
-
@Efonne:
….Full Cone NAT allows any external host to use the existing state table entry to access the internal host, kind of like a temporary port forward.....
This is exactly what I need.
I read only good reviews for pfSense, and I wanted it to use it, but with Symmetric NAT I will not be possible to use it.
I understand that a Full Cone NAT decreased security, but a home user like me it is not essential. -
In what way does Full Cone NAT help you that setting up a port forward would not?
-
Port forwarding is required, but not enough in my case.
Only in this way I can solve problems like 1-way audio and dropped calls.
When the SIP client is in a 3G network Full Cone NAT is the only way to make a connection.
