FreePBX firewall lockout: recover one trusted admin path

Prove which firewall layer rejected the path

Record the administrator's source address, destination address, protocol, port, timestamp and exact symptom. Compare local console access, GUI access from the same trusted network, and one deliberately external path without changing policy. The FreePBX Firewall, operating-system rules, cloud security controls, edge firewall and reverse proxy can all block the same connection; access from the console does not prove the internet path is permitted.

Preserve recent denial evidence and the current interface, network-zone and service-permission settings. A failed GUI page, SSH timeout and phone registration failure are different observations. Do not widen SIP or web access until the rejected layer and intended source are known.

Use a controlled console path first

Use a local console, hypervisor or provider console, or an SSH session that is already authorized. Sangoma documents fwconsole firewall --help for the installed command set and fwconsole firewall list trusted for current Trusted-zone entries. Record the exact output and installed Firewall module version before changing it.

Do not start with fwconsole firewall stop or disable. Sangoma says both immediately flush the module's iptables rules, and disable persists across reboot. That is a broad security change, not a scoped unlock. Safe Mode is also not a universal rescue switch: it must already be enabled, requires two completed reboots within five minutes and delays rules for only five minutes. Rebooting a live PBX can interrupt calls and should not be improvised.

Recover one verified administrator source

If the FreePBX Firewall is the confirmed blocking layer, verify the public source address from an independent channel and add only that host or deliberately bounded administration network through the supported control. Sangoma documents fwconsole firewall trust <host-or-network> and the equivalent add trusted form. Avoid trusting an entire ISP, carrier, mobile or internet range merely because the address may change.

Confirm the entry with fwconsole firewall list trusted, then retry only the required management service. A successful GUI login proves that source-to-service path; it does not prove SSH, SIP, RTP, IPv6 or another administrator's path. If the address cannot be bounded reliably, use the organization's managed VPN or access gateway instead of making the Trusted zone elastic.

Repair zones and services without losing the recovery path

In the GUI, compare every interface's assigned zone, the source network classification and the service permissions with the approved access matrix. Sangoma describes FreePBX Firewall as deny-by-default and warns that an interface left in Trusted is a misconfiguration. Its getting-started guide also distinguishes known Internal or Local networks from the Internet-facing interface and says the default External zone does not allow SIP.

Change one boundary at a time and keep the console session available. Trunks discovered by FreePBX have their own integration; do not add a carrier network to Trusted just to make signaling pass. Responsive Firewall exposes selected signaling for roaming clients and is not a substitute for management-plane authorization.

Remove temporary trust and verify both allow and deny cases

After the intended zone or access path works, remove a temporary host with the documented fwconsole firewall untrust <host-or-network> command and confirm the list again. Test GUI access from the approved administrator path and rejection from an unapproved source. If SSH is intentionally available, test it separately. Then verify registration, one inbound and outbound call, two-way audio and hangup only for services touched by the change.

Record the before-and-after entries, operator, time, source address, module version, rollback and remaining upstream rules. Redact public addresses and credentials from shared evidence. No PBX, firewall, cloud rule, edge device, GUI, SSH, SIP, media or live-call behavior was tested for this guide; command availability and labels depend on the installed module version.

Check module and interface identity before trusting a source

Record the installed Firewall module version, operating system and interface identity before applying a recovery command. FreePBX 17's current release branch declares module support but retains mixed platform metadata, while Sangoma's technical guide treats an unknown interface as Trusted to reduce migration lockouts. A renamed or replaced interface can therefore change classification independently of the administrator's source network.

After recovering reachability, prove the Admin identity separately

A recovered firewall path does not prove authentication or module access. Continue with the Admin login diagnostic.