VoIP PBX Remote Access for MSPs: Reach FreePBX, 3CX, and Grandstream Consoles Without Opening Ports

Every business an MSP supports runs a phone system, and the phone system is one of the few boxes on the network you can never put an agent on. Whether it is an on-premise FreePBX or Asterisk server, a 3CX appliance, a Grandstream UCM, or a Yeastar, it runs embedded or locked-down firmware with a web admin console, a shell in some cases, and SIP listening for extensions and trunks. When trunks drop at 9am, an extension will not register, or a firmware bulletin lands, someone has to reach that admin interface, and the two traditional ways of doing it are both bad.

This guide shows how to give your team browser access to the admin console of every PBX across your client sites, over one outbound tunnel, with no static IP, no open ports, and nothing installed on the PBX itself.

Why a PBX is dangerous to expose and hard to reach

SIP, the protocol every modern PBX speaks, listens on UDP port 5060 by default, with TLS on 5061. An exposed 5060 is not a theoretical risk. Automated tools like SIPVicious sweep the internet for SIP services on that port: svmap finds the host, svwar enumerates valid extensions from the PBX's differing responses, and svcrack brute-forces the registration secret. A single cracked extension or trunk becomes toll fraud, and a compromised account can run up thousands in calls to high-cost destinations within hours. The web console and SSH should never face the public internet either; the FreePBX documentation itself advises that the admin GUI and SSH not be opened to untrusted networks.

So the PBX gets locked onto its own voice VLAN with no route out, and the MSP is left with two poor options. Forwarding the admin port or 5060 publishes exactly what the scanners are hunting for. A per-engineer client VPN is heavy to roll out across dozens of sites and still has to route the voice VLAN correctly at the far end. Some vendors offer a cloud relay of their own, such as Grandstream's RemoteConnect, but that routes your session through the vendor's cloud and only ever reaches that one PBX, not the switch or the NVR on the same rack.

Reach the voice VLAN through one tunnel

ProxyLink works from the inside out. You install one WireGuard tunnel on the site's router or gateway: a MikroTik, a pfSense or OPNsense box, an OpenWrt or EdgeRouter, or any Linux host down to a Raspberry Pi. The tunnel dials outbound to ProxyLink and holds itself open with a keepalive, so the site never accepts an inbound connection, needs no static IP, and works fine behind carrier-grade NAT. Declare the voice VLAN as an additional subnet on the tunnel, alongside the main LAN, and the PBX becomes reachable with nothing installed on it at all.

The links you create

Once the tunnel is up, you create a proxy link per service on the PBX:

• Web admin console (HTTP or HTTPS): a proxy link to the PBX on its admin port gives you the full console in a browser tab, the FreePBX dashboard, the 3CX Management Console, or the Grandstream UCM web UI, for extension changes, call routing, and SIP trunk diagnostics. ProxyLink's default appliance mode rewrites the Origin and Referer headers so the console's built-in same-origin check accepts the proxied request, the same handling that makes Synology, UniFi, and pfSense UIs work through it.
• SSH (port 22): for Asterisk-based systems, a ProxyLink browser SSH terminal puts you on the shell with no client on your laptop, for an asterisk -rvvv console, a log tail, or a service restart the web UI will not do.
• SIP signaling (UDP): because ProxyLink also proxies UDP, and SIP's default transport is UDP on 5060, the same tunnel can carry SIP signaling to the PBX. TCP and UDP links are tied to the tunnel for security and must have one.

What this looks like for an MSP

One tunnel per client site covers the voice VLAN and everything else on the network through the same peer. An engineer opens ProxyLink, clicks the site's PBX, and is on its admin console in a browser with no VPN client to launch and no vendor cloud account to manage per device. Every session is tied to an engineer identity, with the target IP, port, start time, and duration recorded, and access requires a ProxyLink login. The PBX keeps zero open inbound ports and stays invisible to the SIPVicious sweeps and Shodan indexing that catch out exposed phone systems. Traffic runs over open WireGuard, and the relay is hosted in the EU on German infrastructure with no third-party routing of the session.

Access is scoped through the team model: each client is a group, engineers are granted only the sites they manage, and peer isolation keeps every customer's traffic separate at the network layer. This is the class of access agent-based tools cannot give you, because TeamViewer and AnyDesk reach an operating system and a PBX appliance has none. When a trunk drops or an extension will not register, a browser tab beats a drive across town.

Try ProxyLink free at app.proxylink.dev, no card required, free during early access. Setup guides for MikroTik, pfSense, OPNsense, and Linux gateways are in the docs.