OpenVPN ATA Tunnels (Grandstream FXS gateways)¶

Per-device OpenVPN tunnels that give Grandstream GXW-series analog (FXS) gateways a stable, encrypted path into Astradial's cloud Asterisk — the OpenVPN counterpart of the WireGuard Customer Tunnels.

Same security model (per-customer isolation, SIP/RTP-only INPUT scope), different transport: the GXW gateways' firmware speaks OpenVPN, not WireGuard, so they cannot use wg1.

Status: Live · Server: 147.93.168.216 (cloud Asterisk host) · First customer: Mithra Scan (2026-06-15)

Why this exists (and why not WireGuard)¶

Grandstream GXW4216V2 (and siblings) are analog telephone adapters: they take physical phone/fax lines on FXS ports and register them to a PBX as SIP endpoints. To reach our cloud Asterisk reliably from a customer site (CGNAT, dynamic IP, NAT pinhole churn — the same problems described in Customer Tunnels), the device needs a stable tunnel.

The GXW firmware (1.0.25.2) ships an OpenVPN client only — no WireGuard. So these devices get their own OpenVPN transport (tun0) that runs in parallel with the WireGuard customer transport (wg1), governed by the same isolation rules.

The device firmware also constrains the crypto (this is why the server config looks "legacy"):

Security model (read this first)¶

ATA tunnels carry external customer traffic and are isolated exactly like the WireGuard customer tunnels.

What enforces isolation¶

What a device CAN reach via its tunnel¶

✅ 10.21.0.1 (cloud Asterisk tunnel IP) on 5060/UDP, 5080/UDP, 10000-20000/UDP (RTP)

What a device CANNOT reach¶

❌ Other ATA devices            — tun0↔tun0 FORWARD DROP + no client-to-client
❌ WireGuard customers (wg1)     — tun0↔wg1 FORWARD DROP
❌ Internal infra (wg0: NUC .2, staging .3) — tun0↔wg0 FORWARD DROP
❌ AstraPBX API (8000) / editor (3001) / DB — tun0 INPUT catch-all DROP
❌ The public internet via us     — split tunnel (no redirect-gateway)

Known parity gap (same as wg1): host ports that UFW allows globally — SSH (22), 80/443, WSS (8089) — are accepted before the per-interface catch-all DROP, so a compromised device could in principle reach them on 10.21.0.1. This matches the existing WireGuard-tunnel posture. To close it for both transports, insert interface-scoped DROPs above the UFW jump (e.g. iptables -I INPUT <n> -i tun0 -p tcp --dport 22 -j DROP). Tracked as future hardening, not done by default to stay consistent with the wg1 model.

Architecture¶

Address allocation¶

When the first /24 fills (16 customers), add 10.21.1.0/24 as a second shard (new server/tun instance) or widen the existing subnet — see the runbook.

Device & customer registry¶

Keep this table current — it is the human-readable source of truth for IP/cert allocation. The machine truth is /etc/openvpn/ccd/ (IPs) and /etc/openvpn/easy-rsa/pki/index.txt (certs) on the server.

On-server layout (147.93.168.216)¶

Components vs the WireGuard tunnels¶

Operational notes & safety¶

• Additive & call-safe. Standing this up touched nothing in the call path: no Asterisk restart/reload, no pjsip change, no wg change. Every firewall rule is scoped to -i tun0 / udp 1194.
• Never ufw reload casually. Both isolation scripts add their rules with raw iptables outside UFW's managed chains (the wg1 rules likewise). A ufw reload flushes and rebuilds the chains, transiently dropping the live wg1 and tun0 customer rules until each service/interface re-triggers its script. If you must reload UFW, re-run both isolation scripts (or bounce wg1 and openvpn-server@astradial-ata) immediately after.
• The OpenVPN port is opened by the isolation script (inserted at the top of INPUT), not by ufw allow — same reason as above. It self-heals on service start / reboot.

See also¶

• Provision a Grandstream ATA onto the VPN — step-by-step runbook + how to retrieve configs & credentials
• Customer Tunnels (WireGuard) — the sibling transport and shared security model