let me get very specific with the issue being faced.
We have a device that communicates with a STUN/TURN Server running ICE on public Nw. We wish to test some algorithm that can break ICE and force it to fail over to TURN.
My problem is as below:
The algorithm can fail only IF the NAT is symmetric. More specifically, if a Host A sends a packet to Host B, the packet is translated to X:P1, where X is the Natted IP, and P1 is the port. Let the source IP and packet be A:p1.
the requirement is, if the same host A sends another packet as A:p1, the binding should change to X:P2, which is not the case now. It stays bound to X:P1, which allows the device to punch through a hole and not failover.
This is the functioanlity of Symmetric NAT, wherein, every outgoing packet has a unique binding. Is pfsense 2.0.3 a symmetric NAT using Automatic NAT rules? If not, how can one make it do so?
To the good guys at pfsense!
pls reply asap, we are kinda stuck!
thx for the reply. But I had posted my query after thoroughly going through all related topics on this Forum. I just need a simple answer to my query, is the pfsense by default (Automatic NAT rule) a symmetric NAT? IF yes, do we have any known tool which can tell us the kind of NAT we are behind?
A simple answer can help me to look inside our Code and ask our Dev Team to have a re-look.
Automatic outbound NAT does PAT (Port address translation) for every port but udp/500, so the source ports get randomized.
If you want the source ports to be static, you'll need to either use 1:1 NAT, or change to manual outbound NAT and set static port on some NAT rules. You can't use static port for multiple clients going from the same source port to the same destination IP/port though, unless you have multiple IPs to use for outbound connections.
Looking at Diagnostics > States and seeing how the connections are translated there would tell you all you need to know about what it's doing.
So I take it that no one knows if pfsense is using symmetric NAT or not since the question was asked requesting a simple yes or no twice?
It's not as simple as yes/no.
The simplest answer could be: Yes, as long as a state is active.
With automatic outbound NAT, any port (besides 500) gets remapped:
a.a.a.a:YYYY -> x.x.x.x:ZZZZ -> b.b.b.b:WWWW
Return traffic flows just fine using that other port:
a.a.a.a:YYYY <- x.x.x.x:ZZZZ <- b.b.b.b:WWWW
Unless the state expires, at which point that second traffic would fail and be blocked. A new connection from the inside out would get a new port
a.a.a.a:YYYY -> x.x.x.x:VVVV -> b.b.b.b:WWWW
State timeouts can be lengthened by changing to Conservative mode, among other methods. Using a keep-alive for SIP registrations is best.
Thanks - Long ago I realized that having all SIP devices behind pfsense recheck their registration often was best practice.
As much as I can get away with. The default long registrations ALWAYS time out.
cmb last edited by
Most defaults aren't long. There is no "rechecking", it's SIP keepalive that you don't want too high, and that's true with every NAT device in existence.
Sorry for the lack of proper terms.
The SIP adapter / client I use behind pfsense on a fios connection had to have its re-registration times cut from 3600 to about 60?
I didn't see a keep alive option on that one.
Of course "recheck" isn't an option.
This was a change in behavior 100% related to pfsense though. Minor annoyance. Easily handled.
BTW - The reason I was looking at this old thread again is because my son wants to use my xmpp server there for video/audio behind pfsense / NAT.
Figured it out. Just needed to use a STUN server. Thanks.