Practical guide / My PBXs
Your first connection.
On a test system.
Start with a disposable PBX, keep an independent console route and prove each boundary before relying on the connection.
Prepare the PBX and network.
Use FreePBX 17 on Debian 12, with a working HTTPS administration interface and an existing root/console connection. Keep that recovery route available throughout the test.
Confirm WireGuard kernel support, systemd, Python 3 and the wg, ip, nft and iptables tools. The module can install only WireGuard tools after explicit approval; do not assume every prerequisite is supplied.
Plan a reachable WireGuard UDP endpoint, default 51821. In 0.5.0, TELIPHONES manages its FreePBX Firewall permission through a persistent Custom Service; verify generated rules without whitelisting each workstation public IP. Configure any necessary router/NAT forwarding separately. My PBXs supplies no universal NAT traversal or relay and does not close existing public management ports.
Read the platform requirements and known security limitations before changing access policy.
Module first.
Root broker second.
The current 0.6.0 development package and checksum have not been built. Do not install the historical TELIPHONES-0.5.0.tgz archive expecting Open/Closed/Frozen connection states. Follow the package availability page and use only a trusted archive and its matching checksum when a validated build is available. A source ZIP is not an installation package.
Then use Complete Installation on FreePBX 17 from an existing root shell. Use the complete procedure matching the trusted build. It stages trusted files into a root-owned location and installs the broker, SSH authority and firewall listener helper.
Module Admin does not automatically update the separately installed root broker. Disconnect Windows tunnels and confirm no active support session before repeating bootstrap. For a future 0.6.0 package, verify all three installed helpers, broker 0.6.0/protocol 7 and service restart as documented.
Refresh Connectivity > TELIPHONES and inspect System readiness. A module version or operational socket alone is not broker readiness. See package availability and verification.
Keep the application
and SSH helper together.
Obtain an existing successful Windows x64 build and extract it. Keep TELIPHONES.exe beside TELIPHONES-SSH.exe. Record the source/run provenance in build-info.json.
On first launch choose applications, then reuse verified WireGuard or explicitly approve installation. UAC approval is required for tunnel setup. Refusing installation does not download anything, and you can return to Settings later.
Install Windows system OpenSSH Client if you intend to use managed SSH. Choose Windows PowerShell, PowerShell 7, Windows Terminal or Command Prompt. PuTTY is not supported for managed certificates.
Detailed Windows preparation →Request on Windows.
Approve on FreePBX.
Choose the request type
In Add my PBX..., enter a workstation name and choose Web access or Web + SSH access. Web access is selected by default and creates no SSH identity.
Approve the request
A full administrator uses Connectivity > TELIPHONES > Windows workstations over HTTPS. Paste the request, choose temporary or persistent access and enter the reachable WireGuard endpoint.
Approve an account only if required
An SSH-capable request still needs explicit SSH authorisation for an existing Linux account. There is no default root account. The server rejects SSH approval for a web-only request.
Import the bound response
Paste it into the waiting Windows pairing dialog and save. The dialog states whether SSH was authorised, and successful copies use temporary inline feedback. Do not publish request/response strings; private keys are absent, but network metadata remains sensitive.
Connect, check, then open.
Before pairing, provide the actual management services on the PBX, for example https:8443. The first entry becomes the Windows URL. Check Apache listens on the tunnel/wildcard address; permission alone does not make a service reachable. Re-pair saved profiles after URL changes.
Select the saved profile and Connect, approving local tunnel setup. Updated Windows builds check that configured TCP endpoint in Connection Health. A WireGuard handshake or successful TCP probe does not establish correct HTTP, TLS or SSH authentication.
Choose Open FreePBX and sign in normally. If explicitly approved, choose Open SSH; the app automatically requests and verifies a fresh certificate and opens the selected supported terminal.
Do not publish managed SSH or API ports to the Internet. Do not add the workstation interface/subnet to a trusted zone to get around a failure. Use the troubleshooting sequence instead.
A successful login
is the beginning of validation.
Confirm that only intended services are reachable over the workstation tunnel. Compare normal SIP/RTP and unrelated management traffic before, during and after connection. Observe the actual FreePBX watchdog over multiple reported 41-second intervals, including at least five minutes of observation and approved reload testing.
Disconnect and reconnect without extending the original deadline. Close an owned terminal and observe its processes. Revoke a disposable pairing on the PBX and test temporary expiry, including the owned server cgroup and preservation of unrelated SSH sessions.
These are real-PBX acceptance tasks, not claims that the current correction has already passed them. Stop if authority extends unexpectedly, unrelated rules change or cleanup is incomplete. Do not continue on a production PBX.