PBX protection best practices

In environments where an on-premise IP-based PBX systems need to balance functionality with security, it can sometimes be difficult to achieve. This guide addresses many typical technical details, that when applied correctly, allow a PBX to be completely functional with SIP-based trunks and internal SIP connections to endpoints.

PBX SIP trunking

Breaking down the components


This can be a commercial, open source, or even a commercial vendor relying on open source for the PBX functionality. The role of the PBX is to facilitate voice connections from IP phones to the Public Switched Telephone Network (PSTN)

Trunk Provider

They vary in their service offering, such as:

  • SIP support, most common, but requires SIP+NAT handling to be consistent throughout the setup
  • IAX support, less common, but much more NAT compatible
  • STUN
  • Often require a public IP at your PBX site/edge gateway (if you have an ISP connection with a Carrier Grade NAT (CGN) IP address, this requirements makes such a provider incompatible with your network)
  • VPN connection (PBX:Provider)


Most business and enterprise-grade ISPs offer one or more public IPv4 addresses. This is ideal and provides for maximum compatibilities.

However, a lot of modern, regional ISPs, especially WISPs, don’t even offer public IPv4 addresses, and make all IPv4 connections over CGN. In CGN situations, your Trunk Provider must not require any port forwarding, and your PBX must provide a configuration and functionality for all connections to be made outbound, with the same outbound connection being use for bi-directional RTP traffic.

SASE / UTM / Firewall / Gateway

In this case, we are referencing only adam:ONE® as the Secure Access Service Edge (SASE). It must be aware of any and all inbound/outbound connections the PBX may require. It also manages the Network Address Translation (NAT) to translate internal networks to be able to reach and get a response from the ISP and the Internet. Note that in the event of a CGN connection, the NAT happens one more time at the ISP level.

Technical steps for best-practices consideration

  1. The PBX should be on its own network segment, along with IP phones, but no other devices should be on the Voice network. This way layer 2 and 3 Quality of Service can be applied, if needed. For example:
    Network Segment #1: for LAN user devices
    Network Segment #2: for Voice devices, including the PBX

  2. The PBX must have both a static IP address as well as an IP reservation on the DHCP server. This way, if/when the IP stack is reset, the IP address remains the same at all times.

  3. The PBX DNS settings and Gateway settings must be the same ( for gateway, for DNS, for example)

  4. Create a rule/list of all domains (including subdomains) that the PBX+Trunk Provider require, for example:


  5. Create a VoIP/PBX Allowlist/Whitelist policy with the above Rule enabled as well as connectivity check domains included (Holding Tank subscription, for example)

  6. Assign this policy to the PBX.

  7. Create a list of IPv4 ranges that RTP traffic uses without DNS. For example, Vonage requires the following:

    IPv4 Destination Range Protocol Port/Range UDP 69 UDP 80 UDP 123 UDP 5060 UDP 5061 UDP 10000-20000

    Which can be expressed in this enabler form:|ud69,ud80,ud123,ud5060,ud5061,ud10000-20000

  8. Turn on this enabler for the PBX/VoIP policy

  9. Make use of mytools.management/log → Traffic log to confirm all necessary traffic is flowing as required.

  10. If required, modify the outbound NAT rule for SIP server UDP/TCP traffic to port 5060 is setup with STATIC NAT MAPPING. This often solves the issue of no inbound calls arriving at the PBX.


  1. Why bother placing the PBX behind ZTc to begin with? Why not just rely on host-based firewall protection?
    Answer: One of the core principles of ZTc is to assume breach. An out-of-band protection mechanism is required for leakproof egress control.