FreePBX Firewall: zones, services and Responsive Firewall

Confirm the installed module and platform boundary first

Do not infer the running firewall from the FreePBX major version alone. Record the operating system, Firewall module version and state, System Admin dependency, network interfaces, upstream firewall layers and the exact recovery console. The current release/17.0 module metadata declares FreePBX 17 support and version 17.0.2.1, but it also retains an RHEL-oriented description and a Sysadmin file dependency. That mixed metadata is a reason to inspect the installed system, not proof of availability or support on every FreePBX 17 deployment.

Keep the FreePBX Firewall separate from cloud security groups, hypervisor filters, router ACLs, host rules and fail2ban or intrusion-detection state. One accepted or rejected packet can pass through several owners. Preserve each layer before attributing a symptom to the GUI module.

Map interfaces, known networks and zones before services

Sangoma's getting-started guide says newly discovered interfaces begin in Trusted and warns that leaving an interface there is a misconfiguration. Its technical description also treats an unknown interface as Trusted to reduce lockout risk after NIC replacement, migration or cloning. Inventory the interface identity and assign its intended default zone before relying on a service matrix. A recovery behavior that prevents lockout can also expand trust until the interface is classified.

Add only verified hosts or networks to the intended zone. Separate administrator sources, internal phones, VPN networks, carrier peers and roaming clients. Trusted, Internal, Local, Other and Internet-facing classifications are policy roles, not descriptions that can be copied from another PBX without its topology.

Read Smart Firewall pre-classification as scoped state

The technical order of precedence checks known networks, configured trunks or peers, registered endpoints, blacklists and finally the interface's zone. The permissions guide says Smart Firewall follows changes to trunks and endpoints. That automation is scoped to the recognized peer and protocol; it is not blanket administrative trust, proof of identity outside that transaction, or authorization to place arbitrary calls.

Record which object caused the classification, the observed source address, protocol and time. A hostname, registration or trunk definition can change independently of an upstream network rule. Compare loaded PBX state with the firewall decision instead of adding the same address to Trusted as a universal workaround.

Keep deny-by-default and documented exceptions together

Sangoma describes service permissions as deny-by-default: services are granted to zones and hosts or networks are associated with those zones. The technical page separately lists established or related traffic, certain management and diagnostic traffic, and the configured RTP range as earlier permitted classes. Presenting only the slogan or only the exception would misstate the model.

Build a source, destination, protocol, port and purpose matrix for the installed services. A remote phone's SIP or IAX requirement does not require GUI, SSH, UCP or provisioning access, and opening signaling does not prove the negotiated RTP path. Treat IPv4 and IPv6 independently and retain an authorized console route while changing policy.

Use Responsive Firewall only for unknown signaling clients

Responsive Firewall tentatively passes otherwise rejected SIP or IAX signaling from an unknown host, observes whether it becomes legitimate and applies temporary or longer protocol-specific blocks after repeated unsuccessful traffic. Sangoma notes that Local traffic can already be allowed and Trusted traffic is ignored by the Firewall, so their absence from the Responsive status view is not proof of a fault.

This mechanism does not protect an exposed management interface, replace unique credentials, define dialplan authorization or establish that a mobile or roaming client can receive calls. Preserve the selected protocol, remote address, challenge and registration exchange, Responsive decision, contact state and call result. Do not disable the control merely to turn an unresolved client green.

Change one boundary with recovery and negative controls

Before enabling or altering the module, preserve console access, current configuration, installed versions and upstream policy. Change one interface, network or service boundary at a time. Immediately verify the intended administrator or phone path and an unrelated denied source; then test registration, inbound and outbound calls, media and hangup only for services touched by the change.

If access is lost, use the focused lockout recovery guide to recover one narrow administrator source rather than flushing every rule. Remove temporary trust after repairing the durable zone and service policy. No FreePBX host, Firewall module, interface, zone, rule, registration, endpoint, trunk, RTP path, availability, compatibility or live call was inspected or tested for this guide.

Authorize the observed SIPStation source without broadening trust

When no inbound request reaches Asterisk, the SIPStation diagnostic checks current source, transport, port, NAT and FreePBX Firewall ownership before a bounded rule change.

Separate Admin reachability from authentication

Use the Admin login diagnostic to prove DNS, listener, certificate and firewall reachability before resetting a FreePBX identity.