🔒 Part 12: Connecting Telephony Servers to Ring2All SBC via WireGuard VPN & Domain Routing

Welcome to the twelfth installment of our “Debian 13 Clustering & Distribution” series. In previous articles, we deployed our custom APT repository server, compiled Telephony Server and Kamailio, set up database clusters, and built the core Ring2All SBC. In this guide, we provide a step-by-step walkthrough on how to securely connect remote Telephony Servers (running Telephony Server) to a central Ring2All SBC gateway across different Data Centers or private clouds using the built-in Ring2All SBC Web UI Peer Manager and a private WireGuard VPN tunnel. We clearly delineate which tasks are executed on the Server (Ring2All SBC Web UI) and which are performed on the Client (Telephony Server).

🏗️ Architecture Overview: Multi-Data Center & Zero Public IP Exposure

In modern multi-tenant softswitch architecture, Telephony Servers (Telephony nodes) are frequently deployed in different Data Centers, private clouds, or on-premise infrastructure far away from the edge SBC.

Exposing SIP (port 5060) and RTP media ports directly to the public internet on your core telephony nodes introduces significant security risks, exposing PBX engines to automated scanners, SIP brute-force register attempts, and distributed denial-of-service (DDoS) attacks.

                     ┌──────────────────────────────────────────────────┐
                     │            🌐 PUBLIC INTERNET / CARRIERS        │
                     └────────────────────────┬─────────────────────────┘
                                              │ (Public SIP Traffic: 5060/5061)
                                              ▼
 ┌────────────────────────────────────────────────────────────────────────────────────────┐
 │ DATA CENTER A (Edge Gateway)                                                           │
 │ 🖥️  RING2ALL SBC (Kamailio Core)                                                         │
 │ Public IP: 203.0.113.10  │  WireGuard Server IP: 10.9.0.1                              │
 └────────────────────────────────────────────┬───────────────────────────────────────────┘
                                              │
                    🔒 Encrypted WireGuard Transit Tunnel (wg0)
                    UDP Port 51820  │  Subnet: 10.9.0.0/24
                                              │
 ┌────────────────────────────────────────────┴───────────────────────────────────────────┐
 │ DATA CENTER B / PRIVATE CLOUD / ON-PREMISE (Remote Telephony Node)                     │
 │ 📞 CLIENT: TELEPHONY SERVER (Telephony Core)                                           │
 │ LAN IP Only: 192.168.10.41 (NO PUBLIC IP EXPOSURE) │ WireGuard Client IP: 10.9.0.2     │
 │ Ring2All Telephony Engine bound to local_ip_v4 = 10.9.0.2                                      │
 └────────────────────────────────────────────────────────────────────────────────────────┘

Why Use WireGuard for Remote Telephony Nodes?

Zero Public IP Exposure (Complete Shielding): Telephony Servers do NOT require a public IP address. They remain safely tucked inside a private LAN or isolated cloud network (192.168.10.0/24) behind NAT firewalls.
Multi-Data Center Interconnect: Connect core telephony nodes located in disparate Data Centers (e.g. Hetzner, AWS, Equinix, or private data centers) seamlessly back to the central Ring2All SBC edge cluster without leasing expensive private MPLS circuits.
NAT Traversal & Topology Hiding: Telephony Server establishes an outbound WireGuard connection over UDP 51820 to Ring2All SBC. Because WireGuard handles NAT traversal automatically, no complex NAT helpers or public port forwarding are required on the remote Data Center firewall.
Encrypted Media & Signaling: Standard UDP/TCP SIP signaling and RTP audio streams are encrypted end-to-end inside the kernel-level WireGuard layer (10.9.0.0/24), protecting tenant voice privacy.

Endpoint Roles & Responsibilities Summary

Endpoint	Data Center Location	Primary IP	WireGuard IP	Key Responsibilities
🖥️ Ring2All SBC	Data Center A (Edge)	`203.0.113.10` (Public)	`10.9.0.1`	Manages peers, generates client keys, routes domains & load balances
📞 Telephony Server	Data Center B (Private)	`192.168.10.41` (LAN Only)	`10.9.0.2`	Connects tunnel, runs Telephony core for call execution

⚡ Performance, MTU & Concurrent Call Capacity

A common question when tunneling VoIP signaling and RTP media inside VPNs is: “Does WireGuard introduce performance bottlenecks or limit concurrent calls?”

Short answer: No, WireGuard has virtually ZERO negative impact on call capacity. In fact, kernel-level WireGuard handles thousands of simultaneous audio channels effortlessly.

📊 Capacity & Throughput Math

Kernel-Level Performance: WireGuard runs directly as a Linux kernel module (wireguard.ko) using ChaCha20-Poly1305 state-of-the-art crypto primitives. Unlike legacy user-space VPNs (such as OpenVPN), WireGuard can achieve 3 to 5+ Gbps throughput on standard modern CPUs with minimal CPU overhead.
Voice Bandwidth Requirements:
- G.711 (PCMU/PCMA): ~80 kbps per call bidirectional (including RTP/UDP headers).
- Opus / G.729: ~32 to 64 kbps per call bidirectional.
- 1,000 Concurrent Calls (G.711): Requires only ~80 Mbps total network bandwidth and ~50,000 packets per second (pps).
- Result: A modest 4-core server running WireGuard can easily process 200,000+ pps, accommodating over 4,000 to 5,000 concurrent G.711 calls over a single tunnel without packet loss or jitter.
RTP Packet Overhead & MTU Safety:
- Standard Ethernet MTU is 1500 bytes.
- WireGuard adds a tiny 60-byte overhead (20B IPv4 + 8B UDP + 32B WG encapsulation), resulting in MTU = 1420.
- Standard 20ms G.711 RTP audio packets are only 172 bytes long. Since 172 bytes is far below 1420 bytes, RTP audio packets NEVER fragment.
Option for Signaling-Only Tunneling (Bypass Media / Direct RTP): If your Ring2All SBC operates in Direct RTP / Bypass Media mode (where Kamailio routes only SIP signaling down the WireGuard tunnel while RTP streams flow directly or via RTPEngine edge proxies), the tunnel handles virtually UNLIMITED concurrent calls (10,000+ CPS) because SIP signaling packets generate negligible bandwidth.

🔧 Kernel Tuning for High-Capacity VoIP Tunnels

To ensure Linux handles thousands of concurrent RTP streams over WireGuard without packet buffer drops, apply these kernel tuning parameters on both Ring2All SBC and Telephony Servers:

Create /etc/sysctl.d/99-voip-wireguard.conf:

# Maximize UDP socket buffers for high packet rates
net.core.rmem_max = 33554432
net.core.wmem_max = 33554432
net.core.rmem_default = 16777216
net.core.wmem_default = 16777216

# Increase network interface packet queue length
net.core.netdev_max_backlog = 10000

Apply immediately:

sysctl --system

🛡️ Firewall & Network Requirements

[!IMPORTANT] Required Firewall Rules (UDP Port 51820): WireGuard operates over a single UDP port (default: 51820). Before starting, ensure this port is open in host firewalls and cloud Security Groups:

🖥️ Ring2All SBC (Data Center A - Server):

Inbound Rule: Allow UDP port 51820 from any source IP (or restrict to your remote Data Center’s public gateway IP).

UFW Command: ufw allow 51820/udp

nftables Rule: nft add rule inet filter input udp dport 51820 accept

Cloud Firewalls: Open UDP 51820 in AWS Security Groups, Hetzner Cloud Firewall, DigitalOcean, or GCP.

📞 Telephony Server (Data Center B - Client):

Outbound Rule: Allow UDP port 51820 outbound traffic towards the Ring2All SBC Public IP (203.0.113.10).

🛠️ Step-by-Step Implementation Guide

📍 Phase 1: WireGuard Peer Creation via Ring2All SBC Web UI

🖥️ Action on SERVER (Ring2All SBC Web UI)

Instead of manually generating keys on the CLI, Ring2All SBC provides a built-in graphical Peers Manager that automatically generates the client cryptographic keypair and produces the ready-to-use configuration file.

Access Ring2All SBC Web UI: Open your browser and navigate to https://<RING2ALL_SBC_IP> (e.g. https://203.0.113.10).
Navigate to Peers Manager: In the main menu, go to Security > WireGuard VPN > Peers Manager.
Enable WireGuard Service: Ensure the WireGuard VPN Service toggle at the top of the page is switched to Active / Enabled.

Click “Add Peer”: Click the Add Peer button to open the peer creation modal:

┌─────────────────────────────────────────────────────────┐
│ ⚙️ Add WireGuard Peer                                 x │
├─────────────────────────────────────────────────────────┤
│ Name *                                                  │
│ [ e.g. Telephony-Node-DC2                              ] │
│                                                         │
│ Description                                             │
│ [ Remote Data Center B Telephony Node                 ] │
│                                                         │
│ VPN IP Address *                                        │
│ [ 10.9.0. ][ 2 ]                                        │
│ ✓ 10.9.0.2/32 is available                             │
│ Once created, the IP is permanent and used as the SIP   │
│ Endpoint address.                                       │
│                                                         │
│                     [ Cancel ]  [ Create Peer ]         │
└─────────────────────────────────────────────────────────┘

Fill in Peer Details:
- Name *: Telephony-Node-DC2 (or PBX-Miami-01)
- Description: Remote Data Center B Telephony Node
- VPN IP Address *: 10.9.0. [ 2 ]

Click “Create Peer”: Upon clicking Create Peer, Ring2All SBC automatically registers the peer in the server kernel and presents the Peer Configuration modal:

┌─────────────────────────────────────────────────────────────────┐
│ 🛡️ Peer Configuration                                          x │
├─────────────────────────────────────────────────────────────────┤
│ ⚠️  This is the only time the private key will be shown.          │
│     Copy or download the configuration file before closing.     │
│     It cannot be recovered — use "Regenerate Keys" to create.   │
├─────────────────────────────────────────────────────────────────┤
│ PRIVATE KEY                                            [ Copy ] │
│ [ uNB1fwvPxN1D2kKHQrlJiDY104z97qUJkb7EA3/BLW0=                ] │
│                                                                 │
│ WG0.CONF (FOR PBX)                            [ Copy ] [Download]│
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ [Interface]                                                 │ │
│ │ PrivateKey = uNB1fwvPxN1D2kKHQrlJiDY104z97qUJkb7EA3/BLW0=    │ │
│ │ Address = 10.9.0.2/32                                       │ │
│ │ MTU = 1420                                                  │ │
│ │                                                             │ │
│ │ [Peer]                                                      │ │
│ │ PublicKey = 76As0SDAmuhdA+bW2vBcNtT3h7IT04F3fhGia3304Rk=     │ │
│ │ Endpoint = 203.0.113.10:51820                               │ │
│ │ AllowedIPs = 10.9.0.0/24                                    │ │
│ │ PersistentKeepalive = 25                                    │ │
│ └─────────────────────────────────────────────────────────────┘ │
│                                                                 │
│                    [ Done — I've saved the configuration ]     │
└─────────────────────────────────────────────────────────────────┘

Copy or Download the Configuration:
- Click Copy (or Download) under WG0.CONF (FOR PBX) to copy the complete wg0.conf configuration text to your clipboard.
- Once saved safely, click Done — I’ve saved the configuration to close the modal.

📍 Phase 2: Client Installation & Tunnel Activation

📞 Action on CLIENT (Remote Telephony Server SSH in DC B)

Install WireGuard Tools:

apt-get update && apt-get install -y wireguard-tools

Save the Client Configuration File: Create /etc/wireguard/wg0.conf and paste the exact configuration text copied from the Peer Configuration modal in Phase 1:
Terminal window
```
nano /etc/wireguard/wg0.conf
```
Paste the configuration, save, and secure permissions:
Terminal window
```
chmod 600 /etc/wireguard/wg0.conf
```
Your /etc/wireguard/wg0.conf file on the remote Telephony Server should look like:
```
[Interface]
PrivateKey = uNB1fwvPxN1D2kKHQrlJiDY104z97qUJkb7EA3/BLW0=
Address = 10.9.0.2/32
MTU = 1420

[Peer]
PublicKey = 76As0SDAmuhdA+bW2vBcNtT3h7IT04F3fhGia3304Rk=
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.9.0.0/24
PersistentKeepalive = 25
```
Start and Enable the WireGuard Interface:
Terminal window
```
systemctl enable --now wg-quick@wg0
```
Verify Connectivity: Check active tunnel status:
Terminal window
```
wg show wg0
```
Ping the Ring2All SBC WireGuard gateway:
Terminal window
```
ping -c 3 10.9.0.1
```
(You should see 0% packet loss, confirming the encrypted tunnel across Data Centers is active).

📍 Phase 3: Telephony Server Binding & SIP Domain Alignment

To ensure SIP signaling (Via, Contact headers) and RTP SDP media lines contain the VPN IP (10.9.0.2), Telephony Server must be bound to the WireGuard interface. Furthermore, we must align the tenant domains so Telephony Server accepts registration requests proxied by Ring2All SBC.

🌐 Option A: Automated via Ring2All Web UI (Recommended)

Open the Ring2All Web Dashboard (https://192.168.10.40).
Navigate to System Settings > Telephony Servers.
Edit your Telephony Server (or click Add Telephony Server).
Locate the Configuración de Red y VPN (Telephony Server Binding) card:
- Interfaz de Red (SIP/RTP): Select WireGuard Tunnel (auto-ip:wg0).
- Usar Conexión VPN: Enable toggle Yes.
- IP del Túnel VPN / Remota: Enter 10.9.0.2.
Click Save. The backend automatically SSHs into the Telephony Server, updates /etc/freeswitch/vars.xml to local_ip_v4=10.9.0.2, and reloads Telephony Server XML.

🧠 Understanding SIP Registration Headers & Domain Matching

When a user device (SIP Phone/Softphone) registers through Ring2All SBC:

  [ SIP Device ] ─────────────> [ Ring2All SBC ] ─────────────> [ Telephony Node ]
  Domain: sip01.ring2all.xyz    Edge Proxy: sbc.ring2all.com    VPN IP: 10.9.0.2
  Proxy: sbc.ring2all.com       Matches domain in DB            Validates Digest Auth

What the Device Sends:
- Request-URI: sip:sip01.ring2all.xyz
- To: header: <sip:1001@sip01.ring2all.xyz>
- Outbound Proxy: sbc.ring2all.com:5060
What Ring2All SBC Forwards: Kamailio matches sip01.ring2all.xyz to Dispatcher Group 10 (sip:10.9.0.2:5060) and forwards the REGISTER request over the WireGuard tunnel. The original To: header (sip:1001@sip01.ring2all.xyz) is preserved.
Why Telephony Server May Reject the REGISTER (404/403 Error): If Telephony Server only recognizes its local IP (192.168.10.41 or 10.9.0.2) as $${domain} and does not have sip01.ring2all.xyz defined in its SIP directory, Telephony Server rejects the registration with “404 Not Served” or “403 Forbidden”.

🔧 Telephony Server Multi-Domain & Realm Configuration

To configure Telephony Server on the Telephony Server to accept tenant domain registrations forwarded by Ring2All SBC:

Configure Sofia Profile (/etc/freeswitch/sip_profiles/internal.xml): Edit /etc/freeswitch/sip_profiles/internal.xml to add realm auto-detection and domain parsing:

<!-- Tell Telephony Server to use the To: header domain (e.g. sip01.ring2all.xyz) for Digest Authentication -->
<param name="challenge-realm" value="auto_to"/>

<!-- Parse all incoming INVITE/REGISTER domain headers -->
<param name="parse-all-invite-headers" value="true"/>

<!-- Optional: Force alias all incoming tenant domains to default domain -->
<!-- <param name="force-register-domain" value="$${domain}"/> -->

Define Tenant Domain in Directory (/etc/freeswitch/directory/sip01.ring2all.xyz.xml): Ensure the domain matching the tenant in Ring2All SBC (sip01.ring2all.xyz) exists in Telephony Server’s XML directory or is served dynamically via XML Curl:

<domain name="sip01.ring2all.xyz">
  <params>
    <param name="dial-string" value="{presence_id=$1@$2}${sofia_contact($1@$2)}"/>
  </params>
  <groups>
    <group name="default">
      <users>
        <user id="1001">
          <params>
            <param name="password" value="SuperSecretPassword123"/>
          </params>
        </user>
      </users>
    </group>
  </groups>
</domain>

Reload Telephony Server Sofia Profile:
Terminal window
```
fs_cli -x "sofia profile internal restart"
```

📍 Phase 4: Domain Routing & Dispatcher Setup

🖥️ Action on SERVER (Ring2All SBC Web UI / DB)

Add Telephony Server to Kamailio Dispatcher: In Ring2All SBC Web UI under Calls Routing > Dispatchers (or via DB SQL query), add destination sip:10.9.0.2:5060 under Dispatcher Group 10:

INSERT INTO public.dispatcher (groupid, destination, flags, priority, attrs, description)
VALUES (10, 'sip:10.9.0.2:5060', 0, 1, 'duid=node1', 'Remote Telephony Server DC B Spoke');

Map Customer Domain to Dispatcher Group: Map incoming SIP domain traffic (e.g. sip01.ring2all.xyz) to Dispatcher Group 10:

INSERT INTO public.domains (domain_name, dispatcher_group, enabled, description)
VALUES ('sip01.ring2all.xyz', 10, true, 'Tenant Domain sip01 Spoke');

Reload Kamailio Dispatcher Engine: Click Reload Dispatcher in the UI or execute:
Terminal window
```
kamcmd dispatcher.reload
kamcmd dispatcher.dump
```
Confirm that state for sip:10.9.0.2:5060 displays active/AP (Active/Probing).

🔍 Phase 5: End-to-End Verification & Packet Tracing

To test and confirm call flow end-to-end:

1. Packet Capture on SERVER (Ring2All SBC in DC A)

Monitor SIP traffic flowing through the VPN interface wg0:

tcpdump -n -i wg0 port 5060

2. Packet Capture on CLIENT (Remote Telephony Server in DC B)

Monitor incoming SIP traffic arriving over wg0:

tcpdump -n -i wg0 port 5060

3. Place Test Call & SIP Registration

Username: 1001
Password: SuperSecretPassword123
Domain/Realm: sip01.ring2all.xyz
Outbound Proxy: sbc.ring2all.com:5060 (Public IP 203.0.113.10)

You will observe:

Ring2All SBC receives the public SIP REGISTER on port 5060 in Data Center A.
Kamailio matches domain sip01.ring2all.xyz to Dispatcher Group 10.
Kamailio forwards the REGISTER down the encrypted WireGuard tunnel across Data Centers to 10.9.0.2:5060.
Telephony Server in Data Center B uses challenge-realm="auto_to", matches sip01.ring2all.xyz, validates digest authentication password for user 1001, and returns 200 OK via the tunnel.

💡 Summary Checklist

Architecture Concept: Multi-Data Center topology with zero public IP exposure on core Telephony Servers.
Performance & Capacity: Evaluated zero-overhead WireGuard kernel module capable of handling 4,000+ concurrent G.711 channels per node & applied kernel tuning (sysctl).
Firewall: Opened UDP port 51820 on Ring2All SBC firewall / Security Group.
Phase 1 (Server Web UI): Created Peer in Ring2All SBC Web UI (Security > WireGuard VPN > Peers Manager -> Add Peer -> Create Peer). Copied generated wg0.conf from the Peer Configuration modal.
Phase 2 (Client SSH): Saved configuration into /etc/wireguard/wg0.conf on remote Telephony Server in Data Center B, started wg-quick@wg0, and verified ping 10.9.0.1.
Phase 3 (Client Web UI / SSH): Bound Telephony Server to local_ip_v4=10.9.0.2 via Ring2All Web UI (System Settings > Telephony Servers -> Configuración de Red y VPN) and configured challenge-realm="auto_to" for domain matching.
Phase 4 (Server Web UI / DB): Added destination sip:10.9.0.2:5060 to Kamailio Dispatcher Group 10 and mapped SIP domain sip01.ring2all.xyz.
Phase 5 (Verification): Traced cross-DC SIP signaling, registration, and media packets via tcpdump -i wg0.