📄 Remote Access to Vertex Units (Vertex Configuration Stuck on Refreshing)
Sign in

Remote Access to Vertex Units (Vertex Configuration Stuck on Refreshing)

Common ways customers and technicians ask this question:

  • How do I access a Vertex unit on a remote network?
  • Vertex Configuration says "Connected" but keeps cycling red "Refreshing" — what's wrong?
  • I can ping the Vertex over Tailscale (or ZeroTier) but the configuration tool will not load. Why?
  • Can I reach a Vertex through a VPN or over the internet using port forwarding?
  • How do I run Location Manager on customer Vertex units without having to jump-host onsite?
  • Why does broadcast (DDDD / output type B) not work over a VPN?

Short Answer

You cannot reach a Vertex in Broadcast mode (output set to DDDD, type B) across a router, NAT, WAN, or layer-3 VPN such as Tailscale or ZeroTier in default mode. Vertex broadcast traffic is sent to 255.255.255.255 on UDP port 3520 and only travels on the local LAN segment. Ping works because ICMP is unicast and routable; the Vertex's broadcast simply never leaves the customer LAN, so Vertex Configuration shows "Connected" (TCP control channel up) but never receives a status reply and stays stuck on red "Refreshing".

The CallerID.com standard solution is to install a small Vertex Bridge on the customer LAN and reach it over a unicast Tailscale tunnel. The customer's Vertex devices stay in Broadcast mode — no on-site reconfiguration is required.

Why Each Common Approach Fails

  • WAN + port forwarding. Port forwarding can deliver one inbound packet, but the Vertex sends its replies to local broadcast and they never return to the WAN side. You end up with one-way traffic that the configuration tool cannot complete a handshake on.
  • Tailscale (default). Tailscale is a layer-3 routed overlay. It carries unicast IP packets between virtual peers and explicitly does not carry broadcast or multicast. Pings work; Vertex broadcast does not.
  • ZeroTier (default). Same as Tailscale by default. (ZeroTier does have a layer-2 Bridge mode that works, but it requires per-site administration and is fragile if reconfigured.)
  • Reconfiguring every Vertex to Unicast. Works per device but requires editing every Vertex on every site and re-pointing whenever the technician's IP changes — not scalable.

Standard Solution: Vertex Bridge on the Customer LAN + Tailscale Tunnel

Install a small always-on host (a POS PC, mini-PC, or NUC) on the customer's LAN that runs the CallerID Vertex Bridge service. The bridge is the only thing that needs to talk UDP/3520 broadcast on the local segment. The technician reaches the bridge over an encrypted unicast Tailscale tunnel, and Vertex Configuration / Location Manager talks to the bridge instead of the device.

Architecture

CALLERID TECHNICIAN                          CUSTOMER SITE LAN
+-------------------+    Tailscale     +--------------------------+
|  Tech Workstation |  unicast tunnel  |  Bridge Host (always-on) |
|  - Vertex Config  | <==============> |  - Tailscale client      |
|  - Loc. Manager   |   TCP/WebSocket  |  - Vertex Bridge service |
+-------------------+   (port 8765)    +-----------+--------------+
                                                   |
                                          UDP/3520 broadcast
                                                   |
                                       +-----------v-----------+
                                       | Vertex Units (DDDD)   |
                                       | unchanged, in Broadcast|
                                       +-----------------------+

Deployment Steps (Per Customer Site)

  1. Provision a bridge host. Any always-on Windows or Linux machine on the customer LAN — an existing POS PC, mini-PC, or NUC works fine. Give it a static IP or DHCP reservation.
  2. Install Tailscale on the bridge host. Authenticate to the CallerID.com Tailscale tailnet using a tagged auth key (for example tag:vertex-bridge). Confirm the host appears in the Tailscale admin console.
  3. Install the CallerID Vertex Bridge service and start it as a service. It listens on ws://0.0.0.0:8765 and translates WebSocket requests into UDP/3520 broadcasts on the LAN.
  4. Tag and label the host in Tailscale with the customer name (for example customer-acme-bridge) so the support team can find it later.
  5. Verify from the technician's workstation. Open Vertex Configuration or Location Manager, point it at the bridge's Tailscale IP on port 8765, and confirm devices appear and status updates stay green — no red "Refreshing".
  6. Document the bridge host's Tailscale name, customer site, and contact in the Location Manager site directory.

Quick Diagnostic Checklist

  • Ping works, Vertex Configuration shows red "Refreshing": broadcast is not crossing the tunnel. Deploy a Vertex Bridge, or as a temporary fix set the Vertex output to Unicast pointed at the technician's Tailscale IP.
  • Cannot ping the device at all: NAT, firewall, or missing subnet route. Add a Tailscale subnet route on the bridge host advertising the customer LAN, then approve the route in the Tailscale admin console.
  • Bridge reachable but no devices listed: the Vertex Bridge service is not running, or it is bound to the wrong network adapter. Restart the service and confirm it is listening on the LAN-facing interface, not a virtual adapter.

Bottom Line

Stop trying to push UDP broadcast across the WAN or a routed VPN — by design, it cannot work. Place a small Vertex Bridge inside every customer's LAN, reach it through a unicast Tailscale tunnel, and Location Manager works the same way for every site without any change to the customer's Vertex devices.

Related

  • Vertex Installation Guide (VoIP)
  • VoIP Troubleshooting — Complete Guide
  • Vertex EEE — Troubleshooting Guide