Slides for the October 2017 pfSense Hangout video

1. Firewall Best Practices for VoIP on pfSense
October 2017 Hangout
Jim Pingle

2. About this Hangout
● Project News
● General information about VoIP,
PBX, Phones, etc.
● Primary focus is on dealing with
VoIP at the firewall
● Identifying the needs of the VoIP
System
● Basic Call Flow
● Preparing the Firewall
● Configuring the firewall for…
● Local Phones to Remote PBX
● Local phones with a Local PBX
– 1:1 NAT Method
– Port Forward+Outbound NAT
Method
– Remote Phones
● QoS Tips
● Troubleshooting

3. Project News
● 2.4.0-RELEASE and 2.4.1-RELEASE!
– FreeBSD 11.1 base, new installer, ARM support, translations, tons more
– Security fixes for KRACK, dnsmasq, and others
– https://www.netgate.com/blog/pfsense-2-4-0-release-now-available.html
– https://www.netgate.com/blog/pfsense-2-4-1-release-now-available.html
– AWS Elastic Networking Adapter now supported
– There is a known issue with PPPoE over VLAN parent interfaces, fix coming shortly
● 2.4.2-RELEASE coming in a week or two as well
– Security and bug fixes for issues found after 2.4.1-RELEASE
● 2.3.5-RELEASE planned for Monday
– Security fixes for users who cannot upgrade to 2.4.x or who wish to stay on 2.3.x for the time being
● SG-3100 now shipping!
– Powerful ARM firewall with a true integrated four port Ethernet switch
– https://www.netgate.com/solutions/pfsense/sg-3100.html

4. Disclaimer
● A lot of the content in this presentation is simplified so we can focus on the firewall
– For example, we will not talk about things like STUN, SBCs even though they may be relevant to your
setup
● We will not cover the PBX itself except in cases when it’s absolutely necessary
●
Some device-specific options will be mentioned but there are far too many different
implementations to cover everything
●
Every PBX, Phone model/software version, or Trunk could be different in various ways
● You must be familiar with your entire VoIP deployment before you can achieve a successful
and complete firewall configuration!
● Bear in mind that your firewall configuration will most likely be correct by the end of this, but
there could still be problems on the Phones, PBX, or Trunks that prevent it from working!

5. Identify Your Needs
● Before configuring the firewall, you must know what type of VoIP configuration you have and
determine what its requirements are
– Where are the phones? Local, remote, or both?
– Where is the PBX? Local or remote?
– For a local PBX, how many trunks are there and how does the PBX reach them?
– For a local PBX, do you have a routed block of IP addresses, other VIPs, or will it share the WAN
address?
● Three main scenarios of concern:
– Local phones, remote/hosted PBX
– Local phones, local PBX
– Remote phones, local PBX
– If both are remote, there is nothing for this firewall to do!

6. Identify Your Needs
● What protocols are in use on the PBX, Trunk, and Phones?
● Common VoIP protocols include:
– Session Initiation Protocol (SIP), used as a control channel to exchange call information
– Real-time Transport Protocol (RTP), used as a carrier for audio data
– Inter-Asterisk eXchange (IAX2, IAX), used for both control and audio
● Ports used for each protocol vary by implementation, but generally are:
– Asterisk/Vonage: UDP 5060-5069 (SIP), 10000-20000 (RTP), 4569 (IAX2 if needed)
– VoicePulse: UDP 16384-16482, 4569
– PanasonicTDA/Hybrid PBX: UDP 8000-8063, 9300-9301, 2747
– 3CX: TCP/UDP 5060 (SIP), UDP 5061 (SIP), UDP 9000-9049 (RTP), TCP/UDP 5090 (Tunnel)
●
May need additional web server ports as well, consult the docs

7. Identify Your Needs
● More specifics later on allowed traffic, but you should have a general idea before starting
●
What must be allowed inbound?
– With a remote PBX, usually nothing
– With a local PBX, it depends on the trunk but typically SIP, RTP, maybe IAX
●
What must be allowed outbound?
– With a remote PBX, SIP and RTP at a minimum, no special handling in many cases
– With a local PBX, probably SIP, RTP, IAX, but could be any traffic outbound going to the trunks
●
And don’t forget they will need regular outbound Internet access for OS updates!
●
Bandwidth requirements
– Varies by codec, could be anywhere from 20Kibit/s (G.723.1) to 90Kibit/s (G.711 or G.722_64k)
– Max number of simultaneous calls

8. Basic Call Flow
●
Local phone registering to remote PBX
– Phone connects to PBX:5060 to login and tell the PBX it is live and how to reach it
– Source port is randomized by outbound NAT, but the PBX will usually contact the phone back on that same port
– Because the NAT state holding the randomized port info is important, the state must be kept around in some way (more on that later)
– During a call, the phone usually will connect out to an RTP port on the PBX and the PBX will send data back, the audio flow is constant
so a state is maintained, thus audio is not usually as big a problem as call initiation
●
Local PBX to remote Trunk
– PBX will register with a Trunk to show that it is online and accepting calls
– Phones talk to the PBX, not to the trunk, this traffic would not leave the local network
– Trunk will attempt to contact the PBX on standard ports (e.g. 5060)
– If a PBX is registered and keeps the registration active, a state will already exist and be passed
– If there is no state, the inbound connection will need to pass through NAT and/or firewall rules to reach the PBX
●
For this reason, inbound calls to a PBX tend to be more problematic than outbound calls
– PBX will insert its own address into the SIP headers (e.g. VIA), the trunk may trust this and misroute the replies if the PBX is behind NAT
●
In either case, outbound calls and audio generally are less problematic
– The phone or PBX can easily establish a new outbound state, replies to that traffic will flow through the established state
●
See RFC 3665 for detailed call flow examples: https://tools.ietf.org/html/rfc3665

9. Firewall Overview
● Firewall needs will vary based on the scenario, several will be covered
●
pfSense does not include a SIP Application Layer Gateway (ALG) to modify the contents
of SIP packets
– The contents of SIP packets are always passed as-is
●
There is a SIP Proxy package, siproxd, but it is almost never necessary and should be
avoided if at all possible
● Firewall Optimization (System > Advanced, Firewall & NAT Tab)
– Normal mode will expire established UDP states in 60s (1 min)
– Conservative mode expires the same states after 900s (15 min)
● Never allow remote administration for your PBX directly over the Internet!
– Use a VPN if you must allow reach it remotely

10. Preparing the Firewall
● Before starting, create a set of Aliases containing significant information about the VoIP system, for example:
– Host alias for the PBX itself, named PBX, containing the local IP address of the PBX
– Network or Host alias called VoIP_Phones, containing the IP addresses of phones
– Network or Host alias called SIP_Trunks for the upstream SIP trunk addresses, if known
● If the SIP_Trunk address/network is not known or changes, do not make an alias and leave these values set to any.
– Port alias called PBX_Ports containing all of the port numbers needed for SIP, RTP, and other control ports mentioned
earlier
● Create a VIP for the PBX external IP address, if necessary
– Extra IP address in WAN subnet, add VIP (Firewall > Virtual IP, either IP Alias or Proxy ARP)
– IP address in routed subnet to use with NAT, no VIP needed
– IP address in routed subnet to use directly (e.g. subnet is on a local DMZ)
● If the phones coexist in the same network as other devices, consider isolating them or at least adding a
DHCP pool for just the phones, to easily identify them for use with rules as needed
– This is very easy if all handsets are from the same OEM, use MAC address control to deny the OUI prefix from the main
pool, allow to the second pool

11. Local Phones to Remote PBX
● Easiest scenario to accommodate
●
Primary problem is keeping the outbound state in the state table so that the PBX can reach the phone for
inbound calls
– Switching the firewall optimization to Conservative mode (System > Advanced, Firewall/NAT) is OK, but has some
drawbacks such as requiring a larger state table and increased resource usage that comes with it, also may not be
enough!
– Setup a keep-alive and/or re-register period on the phone, 30s-60s should be sufficient
●
Implementation and utility of these vary by phone model
●
Some providers may not like a re-register period that low, with Conservative mode you can go up to 600s-800s and still be OK, but lower
is better
● In some cases, the PBX may require the phone to use a static source port of 5060
– An antiquated requirement that is thankfully becoming rare
– With a single phone this can be accommodated with static port outbound NAT
– For multiple phones, this can’t work with only a single WAN address, would need multiple addresses or a proxy such as
siproxd

12. Local Phones to Local PBX
● Rules for Phones
– If the phones are on the same network segment as the PBX, the phones need no special handling as the traffic never leaves the
subnet from the phones
– In some less common cases the phones may be in another subnet, across a VPN, etc, and then they may need to reach the PBX on
the ports mentioned previously, plus some extra ports such as TFTP (udp/69) – again, varies by implementation
● Set local network and external WAN address in the PBX
– FreePBX: Settings > Asterisk SIP Settings, “External Address” and “Local Networks”
– External Address must be set to the public IP address that will be mapped to the PBX
●
Could be WAN IP address or a VIP
●
If it’s dynamic, that is up to the PBX to keep updated in some way, but out of scope for us here
– Local Network must be set to the local subnet containing the phones, plus any other directly connected or VPN networks containing
phones
● Be sure to allow these networks to reach the firewall in rules on those interfaces!
● Outbound Rules
– Normal allow-all style rules are OK, set gateway if using an alternate WAN
– Can use stricter rules if necessary, but be sure to let out everything the PBX needs, including what is needed for the PBX to get OS
updates

13. Local Phones to Local PBX (1:1)
● 1:1 NAT for a dedicated public IP address on the PBX (VIP on WAN)
● 1:1 NAT will handle inbound NAT, plus static port outbound NAT in one step
● Add a 1:1 NAT rule:
– Firewall > NAT, 1:1 tab, add
– Interface: WAN
– External subnet IP: PBX WAN VIP
– Internal IP: Single host, PBX IP address
– Destination, leave on ANY
● If sharing the WAN IP address, this could be set to the SIP_Trunks alias

14. Local Phones to Local PBX (1:1)
● 1:1 NAT still needs firewall rules to pass the traffic in on the WAN tab, the aliases
created earlier make this easy
● Add a rule:
– Firewall > Rules, WAN tab, click Add to top
– Action: Pass
– Protocol: UDP (Or TCP/UDP if your VoIP system needs TCP)
– Source: Single Host or Alias, SIP_Trunks
● Or use Any here if the SIP trunk addresses are unknown, but using Any without a proper PBX config
can be dangerous!
– Destination: Single Host or Alias, PBX
● This is the local/private IP address of the PBX!
– Destination Port Range: (other), PBX_Ports

15. Local Phones to Local PBX
(Port Forwards+Outbound NAT)
● In some cases, such as sharing the WAN IP address, Port Forwards are preferable to 1:1 NAT
●
When port forwards are used, the outbound static port NAT step must be handled with special rules as well
● First, create the port forward:
– Firewall > NAT, Port Forwards tab, click Add to top
– Interface: WAN
– Protocol: UDP (Or TCP/UDP if your VoIP system needs TCP)
– Source: Single Host or Alias: SIP_Trunks
● Or use Any here if the SIP trunk addresses are unknown, but using Any without a proper PBX config can be dangerous!
– Destination: WAN Address, or if a VIP was added, use that specifically
– Destination Port: Other, PBX_Ports
– Redirect target IP: PBX (or the local/private IP address of the PBX!)
– Redirect target port: Other, PBX_Ports
– Filter Rule Association: Leave this on Add associated filter rule
● A firewall rule will be added automatically by pfSense when the port forward is saved, so there is no need to manually
create rules

16. Local Phones to Local PBX
(Port Forwards+Outbound NAT)
●
To handle the outbound connections from a local PBX properly, static port outbound NAT must be setup for the VoIP traffic
●
Setup Outbound NAT:
– Firewall > NAT, Outbound tab
– Select Hybrid Outbound NAT, Save
●
In Hybrid mode, the Mappings on the page are respected, but the automatic rules are also used when the manual mappings do not match, making it much easier
to deal with than full manual outbound NAT
– Click the button to add to the top of the rules list
– Interface: WAN
– Protocol: UDP (Or TCP/UDP if your VoIP system needs TCP)
– Source: Network, PBX (The alias, or the internal address of your PBX with a /32 CIDR)
– Source Port: [blank] (which means ‘any’)
– Destination: Network, SIP_Trunks
●
Can also leave this set to ‘any’ if the trunk addresses are unknown, but it’s better to be specific if possible
– Destination Port: PBX_Ports
●
Can also leave this set to ‘any’, but better to be specific
– Translation Address: Interface address
– Static Port: CHECKED

17. Remote Phones to Local PBX
●
Similar to regular PBX, but you need to allow phones to connect from arbitrary locations
– Port forwards and/or firewall rules must allow from a source of ‘any’
● Needs care to authenticate things properly, you don't want to allow unknown
clients to connect and make outbound calls on your PBX, $$$$$
– We have seen people get stuck with 5-digit+ cost bills due to misconfigured PBX systems
which allowed anyone to register and make calls, don’t let this happen to you!
● VPN can help here, also reduces or eliminates NAT issues
– Some handsets support OpenVPN
– SNOM and Yealink have models with OpenVPN support
– OpenVPN client export package supports formats for these handsets

18. QoS
● Not enough time for a full run of QoS but enough to offer guidance
● Consider a dedicated line for VoIP to eliminate any need for QoS
– Isolating the traffic ensures it always has the priority and throughput it needs
– Make sure it’s a low-latency line
– Use policy routing to ensure PBX or phone traffic exits the correct WAN
● The ALTQ shaper is a popular choice for prioritizing VoIP traffic
– Using PRIQ is effective and easy, HFSC can also be used but is more complicated and error-prone
– HFSC cannot reserve more than 30% of a link, so slow WANs cannot set aside enough room for VoIP in
many common scenarios
– When using the wizard…
● Enable the VoIP screen
● Use the profile that best matches your PBX/Trunks, or use Generic and enter SIP_Trunks alias
● Ignore the bandwidth fields for PRIQ, for HFSC/CBQ enter values sufficient to hold all simultaneous calls

19. QoS
● Limiters can be used to reserve bandwidth as well
– Match all NON-VoIP traffic, limit to the speed of your circuit, less the amount to reserve for VoIP
● Rules to match VoIP for ALTQ or Limiters can be handled in various ways, more accurately
than the ALTQ wizard
– With a known remote trunk, it’s easiest to match all traffic to/from that host or alias
– The DSCP/TOS bit can be matched, but not set, by pfSense assuming that the phones, PBX, and
trunks all set proper DSCP values
– You cannot match a private network source in queue rules outbound on WAN because outbound NAT
applies first, so stick to matching remote systems or queue via pass rules on WAN, or tag on LAN
rules, match on WAN rules
– If all else fails, prioritize all UDP traffic. It is not ideal, but it’s better than nothing and will still help.
● After making any QoS changes, visit Diagnostics > States and reset the state table to
ensure traffic goes into the proper queues or limiters

20. Troubleshooting
● General Advice
– Reset the state table after any rule or QoS change, at least reset states to/from pbx, trunk, phones
– Widen scope of rules (e.g. don't restrict to trunks) when testing, but only if the strict rules do not work
– Check firewall logs for traffic blocked to/from the phones, PBX, or trunk
– In very rare circumstances, scrubbing needs to be disabled under System > Advanced, Firewall/NAT tab. In most cases
this should be left at the default setting (unchecked). Only change this setting if it has been determined it is necessary to
do so. Some phones send malformed packets that will be silently dropped without scrub active (e.g. unfragmented
packets that claim to be fragmented)
– Take a packet capture of the SIP+RTP traffic and load it in wireshark, which has excellent VoIP analysis tools
● Problems establishing calls
– Watch state table contents when testing, ensure that a state exists from the phone or PBX when expected
– Check outbound rules, make sure the local devices can reach remote
– For inbound calls with a PBX, make sure your port forwards and WAN rules are correct, check firewall logs for blocked
traffic

21. Troubleshooting
● One-way audio
– Packet capture the SIP traffic, inspect headers
●
VIA headers must be correct, for PBX this must be the external IP address
●
If the internal IP address is in VIA headers from a PBX out WAN, then PBX ext addr and/or local networks definitions are wrong on the PBX!
– Check states, firewall logs
● VPN connectivity (registration and/or audio)
– If phones cannot register across a VPN, ensure that the traffic is allowed in rules on the firewall AND on the PBX, there may be a local
firewall and/or other settings on the PBX to account for the other phone subnet
– Ensure that the phones can route to the PBX and that the PBX can route to the phones across the VPN
● Problem with more than one phone registering
– Check if the upstream PBX needs a static source port
● Call quality issues
– Typically not much can be helped here at the firewall, maybe QoS but in most cases it’s a provider/upstream issue
– If a VPN is involved, make sure that neither endpoint is exhausting all CPU/resources handling the VPN
● Consider changing the encryption requirements if there are secure options which are faster, perhaps a crypto accelerator

22. Conclusion
● Questions?
● Ideas for hangout topics? Post on forum, comment on the blog
posts, Reddit, etc