Approval belongs
on the PBX.

One listener policy.
Three deliberate states.

FreePBX administrators can choose Open, Closed or Frozen. Open permits new pairing and existing approved connections. Closed removes the listener and workstation tunnels while retaining pairings and their original deadlines. Frozen blocks new WireGuard identities while preserving existing pairings.

New installations default to Closed; an upgrade with valid existing pairings migrates to Open to preserve access. Locked pairings use dedicated WireGuard listeners with IPv4/IPv6 address, CIDR or DNS-source restrictions; unlocked workstations retain the shared listener. FreePBX provides post-pair lock/unlock and source-list controls, and the broker enforces a simultaneous-session limit that defaults to one. Windows displays the effective policy, verified public source, DNS failures and actual session occupancy; source-list and unlock requests require administrator approval.

Changed listener configuration is delivered to the same authenticated Windows identity. The broker revokes its management lease, limits the old tunnel to session control, and retires it only after the new tunnel acknowledges. Broker restarts retain the pending transition. Portable tests pass; the native Windows UI/service path and live FreePBX/WireGuard acceptance remain unverified. Do not treat this experimental policy as production-certified.

One platform.
A deliberate starting point.

The supported target is FreePBX 17 on Debian 12. FreePBX 16 is not supported. This is a manually installed community module, not a listing in the FreePBX online module repository.

• Use HTTPS for the FreePBX administration interface; pairing and gateway enrolment require it.
• Keep an existing root/console route for installation, recovery and testing.
• The broker needs systemd, Python 3, the FreePBX asterisk account and the relevant Linux network tools.
• Workstation access requires WireGuard kernel support, wg, ip, nft and iptables.
• The WireGuard UDP endpoint must be reachable through the router, host and FreePBX Firewall.

The module can install only wireguard-tools, and only after explicit approval. Other missing prerequisites are a platform administrator's responsibility. The nft command is required; enabling nftables.service is not.

The web interface is not root.

Module Admin installs the FreePBX-facing files. A separate, documented root bootstrap installs protected broker code and services. The web application validates full-administrator permission, CSRF and a fixed action allow-list, then sends a structured request over a restricted Unix socket.

The bootstrap installs protected copies of support_broker.py, ssh_authority.py and FirewallListener.php, retaining previous helper files for rollback. Run it from an existing root shell using a trusted, verified module installation. Use the complete source guide rather than an abbreviated privileged script copied from a marketing page.

Approve exactly the access
you mean to give.

Open Connectivity > TELIPHONES > Windows workstations. Paste the workstation request, set the externally reachable WireGuard endpoint and choose temporary or persistent approval.

GUI-only requests remain web-only. Managed SSH needs an SSH-capable request and explicit selection of an existing Linux account. There is no default root login and no new system account. For Locked pairings, protocol 9 binds the managed SSH listener and certificate API to the workstation's dedicated tunnel interface and address; firewall policy scopes the ports to that peer.

The response binds the workstation key and nonce. Managed pairing additionally pins the host and CA identities and supplies dedicated ports. New managed pairings do not receive access to the ordinary system SSH listener on TCP 22; legacy SSH-approved version-1 pairings retain their original network permissions.

Coexistence.
Not a trusted subnet.

The broker's owned nftables table restricts workstation traffic to the PBX address, approved services and peer sources, dropping forwarding. A second layer integrates narrowly with FreePBX Firewall through the marked teliphones-ws chain.

The marked jump is placed inside fpbxfirewall, after INPUT's Fail2Ban processing, never above FreePBX's INPUT hook. The jump covers shared and dedicated interfaces; each ACCEPT remains scoped to the precise TELIPHONES interface, peer and PBX addresses, and port.

The shared and dedicated public WireGuard UDP listeners are managed as persistent FreePBX Firewall Custom Services. FreePBX generates the rules; the broker does not install competing public UDP rules. Unlocked pairings may roam from any public IP; Locked pairings are admitted only from their configured sources. Reject zones, blacklists and Fail2Ban remain authoritative.

• No trusted workstation subnet or trusted interface.
• No Custom Rules workaround or disabling FreePBX Firewall.
• No changes to unrelated SIP/RTP, SSH or management services.
• Journalled ownership recovers interrupted service creation and updates.
• Generated IPv4 service/zone rules and removal are checked before success; transient failures retain recovery state and retry.

Local packet tests pass, but genuine FreePBX watchdog/reload behaviour and real WireGuard roaming remain unverified. External privileged firewall flushes can create exposure windows before detection; there is no zero-exposure or guaranteed recovery-time claim.

Your web ports.
Not an assumption.

Set the actual management services under Windows workstations > Management web services, for example http:8080, https:8443. Standard HTTP 80 and HTTPS 443 continue to work. The first entry supplies the Windows management URL, and both enforcement layers replace obsolete management-port permissions for authorised peers only.

The pairing form suggests the current direct server port where useful; reverse proxies need an explicit backend-listener override. This does not reconfigure Apache. Check that the service listens on the tunnel or wildcard address, and verify HTTP, TLS and redirects through the tunnel. A listening socket alone is not proof.

Use an updated Windows 0.8.0 build. After a management URL change, re-pair saved Windows profiles so launch and Connection Health use the new endpoint.

Upgrading to 0.6.0:
refresh the installed broker.

When a validated 0.6.0 package is available, install it through Module Admin, confirm no active support session and disconnect Windows tunnels before repeating the root bootstrap. A module upgrade does not automatically update the separately installed root-owned broker.

Verify module/broker 0.6.0, protocol 7, all three protected helpers and service restart using the complete guide. Preserve pairing data, the PBX key and original authorisation deadlines. Do not downgrade one component alone.

Windows is independently versioned at 0.8.0 and distributed separately. Check build provenance as well as version before relying on updated pairing controls.

Failure must be visible.

Admission depends on verified enforcement. Unfamiliar owned-table namesakes are not overwritten. If cleanup cannot be verified, recovery state remains and the operation fails explicitly. Do not “repair” this by flushing the firewall, loosening permissions or deleting pairing data.

Managed listeners have separate owned systemd/cgroup services. Certificate expiry limits new authentication; established sessions depend on pairing lifetime and owned service controls. Complete real systemd termination and unrelated-session preservation remain test-host gates.

After uninstalling, verify that owned interfaces, jumps, chains, listeners, jobs and session processes are absent. An uninstall error requires investigation, not an assumption that access has ended.