The details
that matter.

TELIPHONES connects a native Windows application to a FreePBX module for administrator-approved private access. My PBXs brings workstation pairing, WireGuard, private GUI access, managed SSH, connection health and diagnostics into one workflow. Remote Support is a separate architecture for temporary engineer access.

The target is FreePBX 17 on Debian 12. FreePBX 16 is not supported. Root console access and the documented network/system prerequisites are required. The local experimental module/broker package is 0.6.0. Windows is independently versioned at 0.8.0 and downloaded separately; no matching native build has been verified here.

Windows 10 and 11 x64. There are no macOS, Linux, mobile or browser clients. Integrated WireGuard installation requires native Intel/AMD x64, not x64 emulation on ARM64. The current Windows development target is 0.8.0; native UI validation has not been performed in this environment.

Open permits new pairings and existing approved workstations. Closed removes the workstation listener and tunnels but retains pairings. Frozen blocks new WireGuard identities while retaining existing pairings. New installations default to Closed; an upgrade with valid pairings migrates to Open. The broker enforces per-workstation Locked sources and atomic session leases (default limit one). Existing Windows identities receive listener migration over the authenticated tunnel; the old management path remains blocked until the new tunnel acknowledges. Live FreePBX and native Windows acceptance remain outstanding.

Yes. The application stores multiple approved PBX profiles. Only one connection is active at a time. Each PBX pairing has its own identity, permission and lifetime; approval on one does not confer access to another.

No. Local regression tests and portable Windows core tests do not establish real FreePBX behaviour or native MFC UI validation. Earlier native SSH and live login results are operator-reported. Real-PBX WireGuard roaming, watchdog behaviour, Apache/TLS custom ports, systemd recovery and validation of the 0.6.0/0.8.0 changes remain acceptance gates.

Not automatically. After installing the local 0.6.0 package, repeat the authoritative root bootstrap with no active support session and Windows tunnels disconnected. Verify the protected helpers, broker 0.6.0/protocol 12 and service restart. Preserve existing pairing identities and original deadlines. The current source-lock, session admission, migration and SSH elevation changes pass local regression tests, but live PBX acceptance remains outstanding.

Managed My PBXs SSH runs through WireGuard on an isolated per-workstation listener. It does not require public exposure of ordinary SSH or the certificate API. The WireGuard UDP endpoint must be reachable. TELIPHONES does not automatically close any existing public SSH exposure; verify surrounding firewall/router policy yourself.

No. TELIPHONES places a marked jump inside fpbxfirewall, after INPUT's Fail2Ban hooks. The jump covers both shared and dedicated interfaces, while each ACCEPT remains scoped to the exact interface, peer, PBX address and port. FreePBX owns generated UDP listener rules; the broker restricts tunnel services. Fail2Ban and unrelated rules remain. No Custom Rules workaround, trusted subnet or disabled firewall is required. Live watchdog behaviour still needs validation.

Unlocked pairings use the shared listener and may roam without an individual workstation IP whitelist. A Locked pairing instead uses a dedicated UDP port and admits handshakes only from its approved IPs, CIDRs or domain-resolved sources. Reachable UDP is not trust in an IP, web sign-in or SSH permission. Reject zones, blacklists, Fail2Ban and upstream policy still apply. Real roaming with actual WireGuard handshakes remains unverified.

Yes. Configure the actual HTTP/HTTPS services, for example http:8080, https:8443; the first entry determines the paired URL. Both firewall layers permit only approved ports for authorised peers and replace obsolete rules. Standard 80/443 remains supported. The pairing form can suggest the direct server port, but proxies need an explicit backend override.

Apache must listen on the tunnel/wildcard address. Updated Windows builds retain, launch and health-probe the configured URL's port. Re-pair saved profiles after URL changes; a TCP probe is not an HTTP/TLS validation.

Yes. Windows uses official WireGuard for Windows, reused if verified or installed only after explicit approval. It is not bundled. The PBX needs kernel support and userspace tools. Settings/profile browsing can be used without a tunnel, but pairing and connections require verified Windows WireGuard.

Only where the workstation can reach the configured PBX WireGuard UDP endpoint. Router port forwarding or other deliberate network policy may be necessary. Restrictive or carrier-grade NAT can prevent direct access. Universal NAT traversal, a relay and hosted rendezvous are not implemented.

No. My PBXs adds the PBX tunnel address as a host route. It does not add a general Internet route or forward workstation traffic to the wider PBX network. Approved web/SSH access is distinct from SIP/RTP and other PBX services.

The implementation does not intentionally change unrelated rules or services, and isolated packet tests preserve permitted LAN SIP/RTP and management traffic on both iptables backends. That is not a real PBX guarantee. Verify actual calls, bidirectional RTP and unrelated management traffic during connection, firewall rebuild, revoke and uninstall.

Managed My PBXs SSH uses temporary certificates for a fresh in-memory session key, with an approved existing account and pinned host/CA checks. It does not distribute a permanent administrator SSH private key or fall back to passwords. The permanent workstation signing identity is distinct and DPAPI-encrypted. Legacy/system SSH and Remote Support have separate credential paths.

No. The PBX administrator explicitly selects an existing account. Root is not implicit. Unsupported effective account, Match, multi-factor or forced-command policy fails closed rather than being weakened. Ordinary system SSH configuration remains separate.

Yes. My PBXs supports temporary approval for 60, 240, 480 or 1440 minutes, or persistent access until revoked. Remote Support is always a separate temporary window of 5–240 minutes. Reconnecting does not extend an original deadline.

The implementation withdraws access according to the original pairing deadline and stops owned sessions. Complete real-PBX systemd/cgroup termination remains under validation. This is different from certificate expiry: a short certificate expiring prevents a new login but does not itself kill a shell that is already authenticated.

The PBX withdraws its authority and verifies owned cleanup, reporting failure rather than assuming success. Windows has no server-pushed revocation channel, so its status can lag. Verify server-side access removal and empty owned cgroups; seeing a terminal close is not complete proof. Revoke on the PBX before deleting the local profile.

No. Disconnect closes the owned managed SSH connection and local tunnel while retaining approval. Remove deletes local profile data, not PBX authority. Revoke in FreePBX withdraws that authority. A lost or retired workstation should be revoked even if its local profile is gone.

PuTTY is supported by the separate Remote Support launch path. It is not compatible with managed My PBXs certificates in the current implementation. Managed SSH uses Windows OpenSSH hosted in Windows PowerShell, PowerShell 7, Windows Terminal or Command Prompt. Secure managed PuTTY compatibility is a conditional future objective, not an available feature.

The unreleased Windows source contains an experimental built-in SSH console that reuses the approved managed certificate, pinned host key and owned SSH session. Its source now includes libvterm-based screen emulation and a ConPTY-backed OpenSSH resize path; portable emulator tests pass. Native Windows/ConPTY integration, full-screen applications and real SSH behavior remain unverified, so this is not presented as a production-validated feature.

No. My PBXs is direct workstation pairing for an administrator's own PBX access. Remote Support is a customer-authorised engineer window using separately operated Connect, Checker and Console integrations. Their identities, interfaces and authority lifetimes are independent.

Direct My PBXs access has no hosted TELIPHONES service or subscription mechanism in the inspected implementation. The software is GPL version 3 or later. No hosted gateway, support subscription, service-level agreement or commercial terms are offered by this website; separately operated infrastructure has its own arrangements.

Module Admin runs in the web application's privilege context. Privileged network, service and SSH operations belong to a protected root-owned broker. The documented bootstrap installs it from trusted staged files and must be repeated after upgrades. Uploading the module alone does not prove that the installed broker changed.

Start with the troubleshooting guide, then use FreePBX UK support or the project repository for appropriate non-sensitive reports. Suspected vulnerabilities and sensitive diagnostic data must go privately. Never post keys, credentials, complete pairing strings or grants.