Overview

Webvault provides a routable private subnet to the customer (for example 10.150.X.0/24) that is advertised into the Webvault network. Customer phones on VLAN2 for example use addresses from this subnet and communicate directly with Webvault's 3CX servers and support systems without Network Address Translation (NAT). This avoids SIP/RTP issues caused by address translation or SIP helpers and eliminates the requirement for SBC devices or VPN based phones.

How it works (high level)

1. Webvault advertises the customer's allocated private subnet (e.g. 10.150.X.0/24) into Webvault's backbone.

2. The customer's router hosts that prefix on the voice VLAN (VLAN 2) and does not apply source NAT to traffic sourced from that prefix bound for the client 3CX server or support endpoints.

3. Traffic from 10.150.X.0/24 to Webvault endpoints (e.g. 103.13.85.x, 103.4.173.195 hosted in Webvault) follows the private route and is not network translated against the customer WAN IP.

4. All other LAN traffic continues to be NATed to the internet as normal.

This model gives end-to-end private IP connectivity for SIP and media streams and removes the need for an SBC in most deployments.

Preconditions & Requirements

• Customer must be on a Webvault-provided internet service (not a third-party ISP).

• Webvault will supply:

  • a routed private subnet (e.g. 10.150.X.0/24)

  • the PBX destination IP(s) and any other support IPs (e.g. 103.13.85.x, 103.4.173.195)

• Client Switches must support 802.1Q VLAN tagging and ideally LLDP-MED or Smart Voice VLAN for auto voice VLAN assignment (The Phones will automatically detect the correct VLAN when plugged in).

• Client router must support multiple tagged VLAN internal interfaces and support advanced NAT/firewall translation rules (usually only enterprise grade business routers).

• Do not enable SIP ALGs, SIP helpers, or DNS rewriting on the voice VLAN.

Network Diagram

The below diagram shows the logical layout of the Direct Route configuration:

      [IP Phones]
             │
             │ VLAN 2 Switch Layer2 – 10.150.x.0/24 (Voice)
             │
     ┌────────────────────────────┐
     │ Customer Router          │
     │  - VLAN2 IP: 10.150.x.254│
     │  - NAT Disabled for      │
     │    10.150.x.0/24 →       │
     │    103.13.85.x           |
     │                          │
     │                          │
     └────────────┬───────────────┘
                  │
                  │ Webvault Internet Link (Routed)
                  │
     ┌─────────────────────────────────────┐
     │        Webvault Network          │
     │  - Routes private subnet         │
     │  - Hosts 3CX 103.13.85.x         │
     │    103.4.173.195                 │
     └─────────────────────────────────────┘

END RESULT:
10.150.X.0/24  <─── NAT & FIREWALL EXCLUSION ───>  103.13.85.X    (Example 3CX PBX)
10.150.X.0/24  <─── NAT & FIREWALL EXCLUSION ───>  103.4.173.195  (Support/Monitoring)

Steps

1. Create voice VLAN on router & switches (commonly VLAN 2) and assign the Webvault routed subnet to it:

   • Example: VLAN 2 — 10.150.x.254 (Customer Router Interface on VLAN2) with DHCP pool for phones on 10.150.53.0/24

   • Enable LLDP/Voice VLAN on switches to enable phones to automatically detect the correct Voice VLAN.

2. Add DHCP Option strings for the Voice VLAN provided by Webvault. This will tell the phones how to provision when they retrieve their IP information off the router for VLAN2.
   EG. (option 66 ascii http://myserver.voiceservers.com.au/provisioning/gjUhady287da)

3. Create NAT exemptions AND firewall exclusion rules to bypass NAT AND Firewall for the following Source10.150.53.0/24 (VLAN2 ) through to destinations:

   • 103.13.85.X (Customer 3CX destination, adjust mask per Webvault)

   • 103.4.173.195 (Support/monitoring IP)

   Keep NAT for other LAN subnets (internet access should remain NATed normally).

4. Add static route(s) if necessary pointing Webvault-destined networks to the upstream/Webvault next hop (as provided). Usually not required for single internet connected premises using Webvault internet connections provided default route is in place)

5. Disable SIP helpers / ALGs on the voice VLAN and on any NAT policy.

6. Test registration, calls, and media; verify NAT translations and route paths.

Example Configuration

Cisco IOS Router Selective NAT Bypass (illustrative)

!
! Voice SVI (VLAN 2) using Webvault-routed private subnet
!
interface Vlan2
 description INTERNAL_VLAN2_PHONES
 ip address 10.150.x.254 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1452
!
! WAN/Internet-facing interface (example)
! interface Dialer0
!  ip nat outside
!
! Default route via WAN
ip route 0.0.0.0 0.0.0.0 Dialer0
!
! NAT policy:
!  - DENY (no-NAT) phones -> 3CX PBX and Webvault Support
!  - PERMIT NAT for other LANs (e.g., 192.168.2.0/24) and phones -> anywhere else
!
ip access-list extended NAT_ADDRESSES
 remark === NO-NAT to Webvault PBX & Support ===
 deny   ip 10.150.x.0 0.0.0.255 host 103.13.85.x
 deny   ip 10.150.x.0 0.0.0.255 host 103.4.173.195
 remark === NAT for general internet for VLAN1 and VLAN2 ===
 permit ip 192.168.2.0 0.0.0.255 any
 permit ip 10.150.x.0 0.0.0.255 any
!
! Apply NAT using the ACL above (phones to PBX/support are excluded by the denies)
ip nat inside source list NAT_ADDRESSES interface Dialer0 overload
!

Testing and Verification Procedures

Once the configuration is complete, perform the following tests to confirm correct routing and NAT exemption behaviour:

1. Ping from the Router to the 3CX Server
   On the customer router, issue a ping to the 3CX PBX IP (e.g. 103.13.85.x) specifying the VLAN 2 source IP as the origin. Example:

   ping 103.13.85.x source 10.150.x.254
   

2. Ping from the 3CX Server Back to the Router or Phone
   SSH into the 3CX server hosted within Webvault and test connectivity back to the customer's site:

   ping 10.150.x.254     # Router VLAN 2 interface
   ping 10.150.x.<phone> # Example phone device
   

   These pings should return successfully.
   If these fail, the customer's routing is not configured correctly, or NAT/firewall rules are still blocking return traffic.

3. Traceroute from 3CX Server
   From the 3CX server, perform a traceroute to ensure the route to the customer voice subnet passes correctly through the Webvault core to the customer WAN IP:

   traceroute 10.150.x.254
   

   The final hop should be the customer’s Webvault-assigned WAN IP, confirming proper bidirectional routing of the private subnet.

If tests fail, review static routes, NAT exclusions, and firewall rule placement. The most common issue is NAT still being applied to the 10.150.x.x source traffic or firewall rules have not been whitelisted to allow incoming traffic from the 3cx server or support endpoints.