VOIP RTP UDP port forwarding in a master/backup setup
hcoin last edited by
Here's a recipe copied from the end of a long debug process. I hope it saves others the grief and time I spent to find it.
VOIP / RTP UDP media forwarding on master/backup pfsense setup:
IF your setup is a primary/backup two pfsense box failover operation:
AND you change a NAT port forward rule OR related filter rule
AND RTP VOIP traffic isn't working (no audio) , WHERE the SIP / PBX / VOIP phones say the call is 'in progress'
AND you see RTP traffic showing up as incoming properly addressed on the WAN side packet capture.
AND you see RTP traffic showing up as outgoing properly addressed on the LAN side packet capture.
BUT you don't see the traffic crossing pfsense and getting out the other interface, despite firewall logs saying 'pass' on the packets involved, but with packet captures showing those packets pfsense never actually sends:
- Delete the nat port forward rule for the UDP packets. Delete any associated filter rule.
- Go to System/Advanced Firewall/NAT/ NAT Reflection mode for port forwards. Set that to disable. Save it.
- Go to the backup pfsense box. Do the same thing. No, pfsync doesn't seem to sync this item.
- Go to any other non-RTP 'port forward' rules you may have and set the reflection mode there to what you would prefer.
in English: 'Use system default' (set above to 'disable' reflection) means traffic coming in over the wire to the interface named in the gui that matches the rule will have its destination re-written as you desire. No other interface will be affected. Due to system quirks traffic that is coming in the interface containing the forward (re-written) address that matches the rule will be lost. You want this for RTP if you are connected to any PBX system that is programmed to deal with NAT and SIP – but wait, don't enter it at this step.
'Enable Pure NAT' -- Does the above, but also puts in a rule so that traffic coming in to ANY interface heading for the named destination in the rule gets re-written to go to the given address, with replies (hopefully) going out the interface named in the GUI for the rule. Once again, owing to system quirks, traffic coming in the interface that holds the final rewritten destination will be lost if it's destination address matches wan/incoming rule. Use only if you are really sure interfaces now or in the future, virtual, vpn or actual, that ever show up on this box will want those ranges forwarded to the named destination, and possibly routed magically in reply in wondrous and unexpected ways that don't lead to being able to talk on the phone.
Enable Nat+Proxy -- Does the above but under verrry special conditions that require all the forwarding when taken together using this feature to not exceed port quantity limits, will do the right thing when traffic arrives at the destination interface that matches the rule, sending it back out that interface. This is the default. God help you if you put in too many ports in one rule or in combination. Add one, increase the range of one, and get out your calculator and tally them all to stay under the limit. If you can think through how you use pfsense so as to avoid sending traffic 'in' to interfaces that are just going to send it right back out the same wire you will be better off and your pfsense implementation will scale to great traffic sizes with more ease. Using dns forwarding so internal lookups give the local destination is one idea.
Back to VOIP
- Go to Diagnostics / States / Reset States on the primary. Hit the reset button. Wait.
- Reboot the primary and the backup. Wait.
7) Add the 'port forward' rule for your RTP range. Create an outbound 'manual outbound nat' rule on the wan interface with anything sourced from the lan, set the wan nat address, Check the 'enable static port' button. Choose 'use system default' for 'nat reflection. Enter one port forward rule for every ISP interface you have. Be sure you set your SIP PBX to limit itself to the RTP range of ports you've chosen. Basically think one port per ongoing conversation. Configure your PBX's 'internal' configuration to send traffic that never needs to leave private address spaces to send calls directly to the pbx/soft phone never using public ip's. PFsense will route to the various vpns and internal subnets correctly.
- Be sure all SIP PBX's on the private side of the NAT are set to 'keep media' and not 'bypass media' for extensions if they will be communicating outside the private spaces unless you have done battle enough to know the extensions are smart enough to deal with NAT issues. Certainly set all calls incoming from the WAN(s) to 'keep media' as odds are negotiating that traffic directly to private side extensions will be troublesome.
What a ride!