Source port rewriting
-
I am trying to troubleshoot some issues I am having with SIP trunks connecting to a PABX behind a pfSense router. I am aware of the articles in the knowledge base regarding getting SIP traffic to work properly behind a pfSense firewall but that's not the issue I am facing here.
I am trying to find out if the SIP session is ever being dropped in the NAT (or state) table on the pfSense router. The way I have tried to do this is by looking at what the new port number is (on the WAN side) after NAT. This port is a random port due to the source port rewriting that pfSense does in its default configuration.
What I don't know is if the router (pfSense) has some kind of logic that would change that port on some kind of timer? I also can't seem to find the default timer for UDP sessions to be closed down?
-
I am not sure if this has been fully answered but it would seem that the source port won't change when the firewall optimisation is set to conservative.
I am not sure if this is due to the UDP timeout being increased or if it changes other things too. Maybe someone could shed some light on this?
-
Yes, as long as the state stays alive the source port reserved for the state on the external interface will stay fixed. As soon as the state goes stale the subsequent traffic that is part of the same "connection" will create a new state with a new random source port.
Ideally the NAT engine would remember the expired states (or at least certain number of the most recent ones) and try to re-use the same source port if possible for traffic that matches an expired state exactly but this is not implemented in PF unfortunately.
-
In some circumstances it is possible to use a static source port in outbound NAT.
https://doc.pfsense.org/index.php/Static_Port
pfctl -st
Firewall mode: Normal
udp.first 60s
udp.single 30s
udp.multiple 60sFirewall mode: Conservative
udp.first 300s
udp.single 150s
udp.multiple 900sEither way, there will need to be some sort of keepalive traffic generated either by the SIP provider or the PBX to keep the states open during idle periods.
-
Thank you for the replies.
I have been using the source port rewrite to prove if the SIP connection state has ever dropped. The issue we were having was originally masked by keeping the source port static and changing all the timers. I just needed to be sure that there was no logic that changed it periodically.
As best practice I would think that creating a static port for SIP connections isn't a bad idea.
-
A static source port will not help keep a session for an expired state alive. If this is an inside PBX to an outside SIP trunk provider, this problem is generally handled by reregistering with the SIP provider every 45 seconds or so.
