3CX NAT Configuration:
Firewall & SBC Recommendations

🔍 Why NAT Causes Problems in 3CX (and VoIP Generally)

Network Address Translation (NAT) was designed to allow multiple devices on a private network to share a single public IP address. It works brilliantly for web browsing and email. But it creates serious problems for SIP-based VoIP systems like 3CX — and understanding why is the foundation of fixing it.

The core issue: SIP embeds IP address and port information inside the message body (in the SDP — Session Description Protocol), not just in the packet headers. When a SIP INVITE message leaves your 3CX server on a private IP (e.g., 192.168.1.10), it contains that private address in the SDP payload. Your NAT router rewrites the packet header but has no idea that the same IP is also embedded in the message body. The receiving SIP proxy or trunk provider sees a mismatched address and either fails to establish the call, or — more frustratingly — audio flows only one way.

The result is the classic set of VoIP symptoms that plague untuned 3CX deployments: one-way audio (you can hear them, they can't hear you — or vice versa), calls that ring but never connect, calls that work internally but fail for external numbers, and intermittent registration dropping. Every one of these can be traced back to NAT handling.

⚙️ 3CX Built-In NAT Settings — Where to Configure

3CX has a dedicated NAT configuration section that — when set correctly — tells the system how to handle the discrepancy between its private LAN IP and its public internet IP. This is your first line of defense.

Accessing 3CX NAT Settings

In the 3CX Management Console, navigate to: Admin → Settings → Network → NAT. This section controls how 3CX advertises its IP address in SIP and SDP messages.

Public IP:      203.0.113.45       ← your static WAN IP
Local IP:       192.168.1.10       ← 3CX server's LAN IP
STUN Server:    stun.3cx.com       ← fallback for dynamic IPs
Local Subnets:  192.168.1.0/24     ← add ALL internal subnets
External FQDN:  pbx.yourdomain.com ← must resolve to Public IP
    

🔢 Required Ports for 3CX — Full Port Reference Table

3CX uses a specific set of ports that must be open both inbound and outbound through your firewall. Missing even one can cause specific, hard-to-diagnose call failures. Here is the complete 2026 port reference:

🔥 Firewall Rules & Port Forwarding for 3CX

Proper firewall configuration for 3CX involves two separate concerns: port forwarding (directing inbound traffic from your router to the 3CX server) and firewall rules (determining what traffic is allowed in and out, and from which source IPs).

Port Forwarding Rules (Router / NAT Gateway)

# Forward these ports to your 3CX server's LAN IP (e.g., 192.168.1.10)

External Port   Protocol   Internal Port   Destination
5060            UDP+TCP    5060            192.168.1.10
5061            TCP        5061            192.168.1.10
5090            UDP+TCP    5090            192.168.1.10
9000-10999      UDP        9000-10999      192.168.1.10
443             TCP        443             192.168.1.10
5001            TCP        5001            192.168.1.10
    

Inbound Firewall Rules — Best Practices

🚫 SIP ALG — Why You Must Disable It & How

SIP ALG (Application Layer Gateway) is a feature built into many consumer and small-business routers that attempts to help SIP traverse NAT by rewriting IP addresses in SIP packets. The intention is good. The execution is almost universally broken. SIP ALG is one of the most consistent causes of 3CX call failures, one-way audio, and registration problems in real-world deployments.

🔐 Session Border Controller (SBC) — When & Which to Use

A Session Border Controller sits at the edge of your network and handles all SIP traffic — rewriting SDP addresses, enforcing security policies, managing NAT traversal, and normalizing codec and protocol variations. For 3CX deployments with remote workers, multiple sites, or complex SIP trunk requirements, an SBC is the cleanest solution to NAT challenges.

When Do You Need an SBC vs Just STUN?

🔧 SBC Configuration Step by Step

For most 3CX deployments, the built-in 3CX SBC is the right choice. Here's how to configure it correctly:

🔍 Diagnosing NAT Issues in 3CX — Troubleshooting Guide

✅ 3CX NAT Configuration Checklist

Run through this checklist after every new 3CX deployment or major configuration change:

• 3CX Public IP field set to correct static WAN IP (or STUN for dynamic IPs)
• 3CX Local IP field set to server's static LAN IP
• All internal subnets added to 3CX Local Subnets list
• External FQDN configured and resolves correctly to public IP
• SIP ALG disabled on all routers and firewalls in the network path
• Port 5060 (UDP+TCP) forwarded to 3CX server's LAN IP
• Port 5061 (TCP) forwarded for TLS if using encrypted SIP
• UDP ports 9000–10999 forwarded for RTP media
• Port 5090 (UDP+TCP) forwarded for SBC tunnel / remote phones
• Port 443 and/or 5001 forwarded for 3CX Web Client
• Inbound SIP on 5060 restricted to SIP trunk provider IP ranges only
• 3CX Firewall Checker run and all tests pass (green)
• Test call made — two-way audio verified from internal and external phone
• Remote worker phone tested via SBC tunnel — two-way audio confirmed
• NAT UDP timeout on router set to 180 seconds or higher
• QoS configured on router to prioritize voice (DSCP EF / CS3)
• 911 / Emergency services address registered for all extensions