---
title: "🔒 Part 12: Connecting Telephony Servers to Ring2All SBC via WireGuard VPN & Domain Routing"
description: "Documentation for 12. WireGuard Telephony 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?

1. **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.

2. **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.

3. **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.

4. **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

1. **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.

2. **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.

3. **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**.

4. **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`:
```ini
# 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:
```bash
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:
>
> 1. **🖥️ 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.
>
> 2. **📞 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.

1. **Access Ring2All SBC Web UI**:
   Open your browser and navigate to `https://<RING2ALL_SBC_IP>` (e.g. `https://203.0.113.10`).

2. **Navigate to Peers Manager**:
   In the main menu, go to **Security > WireGuard VPN > Peers Manager**.

3. **Enable WireGuard Service**:
   Ensure the **WireGuard VPN Service** toggle at the top of the page is switched to **Active / Enabled**.

4. **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 ]         │
   └─────────────────────────────────────────────────────────┘
   ```

5. **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 ]`

6. **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 ]     │
   └─────────────────────────────────────────────────────────────────┘
   ```

7. **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)

Log in to your remote **Telephony Server** (`192.168.10.41` in Data Center B) via SSH as `root`:

1. **Install WireGuard Tools**:
   ```bash
   apt-get update && apt-get install -y wireguard-tools
   ```

2. **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:
   ```bash
   nano /etc/wireguard/wg0.conf
   ```
   *Paste the configuration, save, and secure permissions:*
   ```bash
   chmod 600 /etc/wireguard/wg0.conf
   ```

   *Your `/etc/wireguard/wg0.conf` file on the remote Telephony Server should look like:*
   ```ini
   [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
   ```

3. **Start and Enable the WireGuard Interface**:
   ```bash
   systemctl enable --now wg-quick@wg0
   ```

4. **Verify Connectivity**:
   Check active tunnel status:
   ```bash
   wg show wg0
   ```
   Ping the Ring2All SBC WireGuard gateway:
   ```bash
   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)

1. Open the **Ring2All Web Dashboard** (`https://192.168.10.40`).
2. Navigate to **System Settings > Telephony Servers**.
3. Edit your Telephony Server (or click **Add Telephony Server**).
4. 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`.
5. 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
```

1. **What the Device Sends**:
   - `Request-URI`: `sip:sip01.ring2all.xyz`
   - `To:` header: `<sip:1001@sip01.ring2all.xyz>`
   - `Outbound Proxy`: `sbc.ring2all.com:5060`

2. **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**.

3. **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:

1. **Configure Sofia Profile (`/etc/freeswitch/sip_profiles/internal.xml`)**:
   Edit `/etc/freeswitch/sip_profiles/internal.xml` to add realm auto-detection and domain parsing:
   ```xml
   <!-- 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}"/> -->
   ```

2. **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:
   ```xml
   <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>
   ```

3. **Reload Telephony Server Sofia Profile**:
   ```bash
   fs_cli -x "sofia profile internal restart"
   ```

---

### 📍 Phase 4: Domain Routing & Dispatcher Setup

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

1. **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`:
   ```sql
   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');
   ```

2. **Map Customer Domain to Dispatcher Group**:
   Map incoming SIP domain traffic (e.g. `sip01.ring2all.xyz`) to Dispatcher Group `10`:
   ```sql
   INSERT INTO public.domains (domain_name, dispatcher_group, enabled, description)
   VALUES ('sip01.ring2all.xyz', 10, true, 'Tenant Domain sip01 Spoke');
   ```

3. **Reload Kamailio Dispatcher Engine**:
   Click **Reload Dispatcher** in the UI or execute:
   ```bash
   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`:
```bash
tcpdump -n -i wg0 port 5060
```

### 2. Packet Capture on CLIENT (Remote Telephony Server in DC B)
Monitor incoming SIP traffic arriving over `wg0`:
```bash
tcpdump -n -i wg0 port 5060
```

### 3. Place Test Call & SIP Registration
Register softphone device with:
- **Username**: `1001`
- **Password**: `SuperSecretPassword123`
- **Domain/Realm**: `sip01.ring2all.xyz`
- **Outbound Proxy**: `sbc.ring2all.com:5060` (Public IP `203.0.113.10`)

You will observe:
1. Ring2All SBC receives the public SIP `REGISTER` on port `5060` in Data Center A.
2. Kamailio matches domain `sip01.ring2all.xyz` to Dispatcher Group `10`.
3. Kamailio forwards the `REGISTER` down the encrypted WireGuard tunnel across Data Centers to `10.9.0.2:5060`.
4. 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

- [x] **Architecture Concept**: Multi-Data Center topology with zero public IP exposure on core Telephony Servers.
- [x] **Performance & Capacity**: Evaluated zero-overhead WireGuard kernel module capable of handling 4,000+ concurrent G.711 channels per node & applied kernel tuning (`sysctl`).
- [x] **Firewall**: Opened UDP port 51820 on Ring2All SBC firewall / Security Group.
- [x] **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.
- [x] **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`.
- [x] **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.
- [x] **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`.
- [x] **Phase 5 (Verification)**: Traced cross-DC SIP signaling, registration, and media packets via `tcpdump -i wg0`.