PfSense and VoIP - Fix for Dropped Calls
-
There is already some info out there about this but I thought I would just add to it.
If anyone has encountered issues with VoIP dropped calls (external > internal and internal > external) then the issue could be the short state timeouts.
In Advanced -> Firewall Optimization Setting make sure that's set to conservative. That will adjust the state timeouts and will solve many VoIP troubles with dropped calls.
Edit: The preferred method is not to change the firewall option to conservative but to enable/increase periodic VoIP gateway ping's within your SIP configurations. Thank you dhatz and cmb for the info.
If you try to set the state timeout on the rules directly (under Advanced) this will not resolve your problem because on pfSense 2.0-RC1, it will only adjust the timeout for TCP, not UDP. (/etc/inc/filter.inc line 1940 something shows it only affects TCP)
So, the only method I know of is to set the firewall optimization to "conservative".
The only draw back with doing this you will notice a fairly substantial increase in the states. Preferably, it would be great to be able to adjust the timeout right from the rule itself but that doesn't work with UDP. Though, I'm not sure on 2.0.1. If it was not for VoIP traffic I would rather it set to normal. If a DoS attack or other huge spike occurred it would likely increase the risk of running out of resources.
Does anyone know if 2.0.1 added UDP timeout support for the rules?
-
Does anyone know where the firewall optimization values are stored?
I would like to modify the conservative value…
- Conservative -----
pfctl -s t
tcp.first 3600s
tcp.opening 900s
tcp.established 432000s
tcp.closing 3600s
tcp.finwait 600s
tcp.closed 180s
tcp.tsdiff 60s
udp.first 60s
udp.single 30s
udp.multiple 60s
icmp.first 20s
icmp.error 10s
other.first 60s
other.single 30s
other.multiple 60s
frag 30s
interval 10s
adaptive.start 0 states
adaptive.end 0 states
src.track 0s -
The only draw back with doing this you will notice a fairly substantial increase in the states.
Since this would be fairly serious drawback for a production system (considering how ease it is to spoof UDP traffic), wouldn't it be preferrable to simply increase the frequency of periodically "pinging" the SIP peer, to ensure that NAT gateway doesn't expire the relevant UDP states ? (such as Asterisk's qualify=yes directive)
I seem to remember the UDP conservative timeout setting is a pfsense-specific feature. AFAIK there's no rule-specific state timeouts.
-
Yep except not running nat in this case. firewall is operating transparently, mainly used for rate limiting and also some firewall rules/routing.
the conservative setting changes both tcp and udp timeouts but the TCP timeouts are perfect on normal, if I could add (or at least modify) one of the settings to keep the TCP timeouts of normal but use the timeouts from conservative for UDP I think it would be ideal.
Couldn't find those settings anywhere, I looked through filter.inc
Thanks for taking the time to help.
-
The only draw back with doing this you will notice a fairly substantial increase in the states.
Since this would be fairly serious drawback for a production system (considering how ease it is to spoof UDP traffic), wouldn't it be preferrable to simply increase the frequency of periodically "pinging" the SIP peer, to ensure that NAT gateway doesn't expire the relevant UDP states ? (such as Asterisk's qualify=yes directive)
I seem to remember the UDP conservative timeout setting is a pfsense-specific feature. AFAIK there's no rule-specific state timeouts.
Thinking about your post some more, even though I'm not running nat maybe increasing the ping would help… I am guessing pfsense has some type of automated state killing that looks for idle connections or something? as for the draw back yes, in fact since I changed it running 3 times as many states now so would be happy to get it working some other way. not even pushing much traffic tonight.
-
The only draw back with doing this you will notice a fairly substantial increase in the states.
Since this would be fairly serious drawback for a production system (considering how ease it is to spoof UDP traffic), wouldn't it be preferrable to simply increase the frequency of periodically "pinging" the SIP peer, to ensure that NAT gateway doesn't expire the relevant UDP states ? (such as Asterisk's qualify=yes directive)
I seem to remember the UDP conservative timeout setting is a pfsense-specific feature. AFAIK there's no rule-specific state timeouts.
Just wanted to say thank you. Not sure if it will work or not but we're running freeswitch and there is a ping setting in the sip profile. checking the docs says its there to keep states alive so we'll see. I owe you…
-
It is best to decrease keep alive rather than increase state timeouts, though the latter generally works. The problem is the SIP registrations get dropped rather than calls dropping, calls never have idle time to be dropped, but if your SIP registration gets dropped you're going to have a wide range of issues. This is true of all firewalls and everything that does NAT because of the way they have to fake connection tracking for UDP since it's connectionless. You'll have better results with everything by having a lower keepalive on the SIP.
-
@cmb:
It is best to decrease keep alive rather than increase state timeouts, though the latter generally works. The problem is the SIP registrations get dropped rather than calls dropping, calls never have idle time to be dropped, but if your SIP registration gets dropped you're going to have a wide range of issues. This is true of all firewalls and everything that does NAT because of the way they have to fake connection tracking for UDP since it's connectionless. You'll have better results with everything by having a lower keepalive on the SIP.
Thank you cmb!
I agree, when I experimented with the conservative option the states tripled. I started to realize having public DNS servers with a fair amount of queries caused states to build faster then they would expire.
The problems I had were strange, Like you said, a call has no chance to be idle so the only thing I could think of is if the RTP ports were open on a call but the SIP port went idle, then the signaling would have been unavailable.
This might explain why an established call was ok but when the call tried to bridge (conference) another party it would sometimes drop both sides. It immediately cleared up with the conservative option. So far the SIP ping is working, I set the firewall back to normal.
It's amazing, everything can be working perfectly on a network until you introduce real time traffic like VoIP. I even had to setup LLQ QoS on the cisco routers so during traffic peaks it gives voice priority.