Ports Required for FreePBX + Asterisk: Complete Firewall Guide for SIP, RTP, WebRTC, ARI, and AMI

FreePBX and Asterisk are often installed correctly — but calls still fail because the firewall is missing 1–2 critical ports, or because too many ports are exposed to the internet.

This guide gives a production-safe firewall checklist for FreePBX + Asterisk, covering: SIP (UDP/TCP/TLS), RTP media, WebRTC, ARI, AMI, and the FreePBX admin UI — with practical commands for validation.

You will also learn the most common real-world problems: one-way audio, registration fails, WebRTC WSS not connecting, and “it works on LAN but fails from outside”.

Reference links used in this guide: Asterisk Official Docs, FreePBX Wiki, RFC 3261 (SIP), RFC 3550 (RTP), RFC 5764 (DTLS-SRTP).

At a Glance: What Should Be Exposed vs What Should Never Be Public

• OK to expose (with IP restrictions): SIP (5060/5061) and RTP (media range), if you must accept remote phones/trunks directly.
• Better: do NOT expose SIP at all: Use VPN (WireGuard/OpenVPN), SBC, or carrier-managed trunks.
• Never expose publicly unless you have a strong reason: AMI (5038), ARI (8088/8089), FreePBX admin ports (80/443) without hardening.

The #1 production mistake is leaving SIP + Web UI open to the world without IP allowlisting. Asterisk boxes get scanned constantly.

SVG Diagram: FreePBX + Asterisk Port Flow (SIP Signaling vs RTP Media)

This diagram shows why “SIP opens but no audio” happens: SIP (signaling) can connect on one port, but RTP (media) needs a whole UDP range.

If SIP is open but RTP range is blocked, calls may ring/answer but audio is silent or one-way.

Required Ports Table for FreePBX + Asterisk

Use this as your base reference. Always verify your own configured ports because deployments vary.

If you are using WebRTC clients (browser phones), you will usually need HTTPS + WSS reachable, and correct RTP handling (often SRTP). The exact WebRTC ports depend on your stack and whether you proxy WSS via NGINX.

Before You Touch Firewall Rules: Confirm Your Actual Listening Ports

Many teams open the “standard” ports but their server is listening somewhere else. Run these checks first.

1) Check listening ports (Linux)

sudo ss -lntup
sudo ss -lnup | grep -E '5060|5061|5038|8088|8089|443|80'

2) Check Asterisk SIP transports

sudo asterisk -rx "pjsip show transports"
sudo asterisk -rx "pjsip show settings"

3) Check RTP range Asterisk will use

sudo asterisk -rx "rtp show settings"

If your RTP range is not 10000–20000, open the range shown by rtp show settings (and update your firewall accordingly).

Safe Default Strategy: Allowlist First, Then Open Only What You Need

Production best practice:

• Allow SSH only from your office/VPN IPs.
• Allow FreePBX Web UI (443) only from your admin IPs.
• Allow SIP + RTP only from carrier IPs or known remote offices (or use VPN).
• Keep AMI/ARI internal only.

If you cannot allowlist (dynamic remote agents), use VPN. Opening SIP to the full internet is a high-risk choice.

Firewall Rules Example (Ubuntu/Debian): UFW (Simple and Clear)

If you use UFW, start from a deny-by-default policy, then allow only required ports. Replace IPs with your real office/VPN/carrier IPs.

1) Baseline

sudo ufw default deny incoming
sudo ufw default allow outgoing

2) SSH from a trusted admin IP only

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp

3) FreePBX Web UI from trusted IPs only

sudo ufw allow from 203.0.113.10 to any port 443 proto tcp

4) SIP + RTP only from your SIP provider IP(s)

# SIP
sudo ufw allow from 198.51.100.20 to any port 5060 proto udp
sudo ufw allow from 198.51.100.20 to any port 5060 proto tcp

# SIP TLS (only if you use it)
sudo ufw allow from 198.51.100.20 to any port 5061 proto tcp

# RTP range (match your rtp.conf)
sudo ufw allow from 198.51.100.20 to any port 10000:20000 proto udp

5) Enable and verify

sudo ufw enable
sudo ufw status verbose

If you have multiple provider IPs, repeat the allow rules per IP. Avoid “allow from any”.

Firewall Rules Example (Ubuntu/Debian): nftables (Modern Production Option)

Many Debian/Ubuntu servers now use nftables. Below is a minimal example conceptually. You should integrate into your existing nftables policy instead of pasting blindly.

# View existing ruleset
sudo nft list ruleset

Minimal inbound allowlist idea (example only):

sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Allow established traffic
sudo nft add rule inet filter input ct state established,related accept

# Allow loopback
sudo nft add rule inet filter input iif lo accept

# Allow SSH from trusted admin IP
sudo nft add rule inet filter input ip saddr 203.0.113.10 tcp dport 22 accept

# Allow HTTPS admin UI from trusted IP
sudo nft add rule inet filter input ip saddr 203.0.113.10 tcp dport 443 accept

# Allow SIP + RTP from provider IP
sudo nft add rule inet filter input ip saddr 198.51.100.20 udp dport 5060 accept
sudo nft add rule inet filter input ip saddr 198.51.100.20 tcp dport 5060 accept
sudo nft add rule inet filter input ip saddr 198.51.100.20 tcp dport 5061 accept
sudo nft add rule inet filter input ip saddr 198.51.100.20 udp dport 10000-20000 accept

You must also ensure the nftables rules persist on reboot (method depends on your distro setup).

FreePBX Firewall Module: What to Configure So You Don’t Lock Yourself Out

FreePBX includes a firewall module in many editions. If you use it:

• Add your office IPs to Trusted before enabling strict policies.
• Keep FreePBX UI in Trusted zone only.
• Put SIP providers in a dedicated zone (or trusted if you allowlist).
• Do not expose ARI/AMI to public zones.

If you are unsure, apply OS firewall rules first (UFW/nftables) and then carefully align FreePBX firewall rules.

Problem: “Calls Ring and Answer, But No Audio” (One-Way / No-Way Audio)

This is almost always RTP blocked or NAT misconfigured:

• Firewall missing the RTP UDP port range used by Asterisk
• Router/NAT not forwarding correctly (if server is behind NAT)
• Incorrect external/public IP set in SIP settings
• SIP ALG interfering on the router

Fast checks

sudo asterisk -rx "rtp show settings"
sudo asterisk -rx "pjsip show settings"
sudo asterisk -rx "pjsip show transports"

Confirm RTP packets are arriving

# Replace eth0 with your interface
sudo tcpdump -n -i eth0 udp portrange 10000-20000

If SIP works but tcpdump shows no RTP traffic during a live call, your RTP range is blocked upstream.

Problem: “SIP Registration Fails (401/403) After Firewall Changes”

Firewall changes can cause SIP to look like “auth failures” because packets are missing or source IP changes. Common causes:

• Provider expects traffic from a fixed public IP, but you’re behind NAT or IP changed
• Port 5060 opened only for UDP, but your setup is using TCP (or vice versa)
• Fail2ban or FreePBX firewall is blocking provider IP after repeated retries

Verify transport and registration attempts

sudo asterisk -rx "pjsip show registrations"
sudo asterisk -rx "pjsip set logger on"

Watch logs during registration. If you see no inbound responses, it’s often network/firewall — not credentials.

Problem: “WebRTC Phone Doesn’t Connect (WSS/DTLS/SRTP Issues)”

WebRTC introduces additional requirements:

• Browser needs HTTPS for the app
• Signaling often uses WebSocket/WSS
• Media typically uses SRTP (still carried in UDP RTP ports)

Typical symptoms:

• Web app loads, but “Registering…” forever
• Call starts but audio fails
• Works on LAN, fails from outside

Verify Asterisk HTTP server status

sudo asterisk -rx "http show status"

If your WebRTC stack uses NGINX as a reverse proxy, confirm you allow WebSocket upgrade headers and the correct backend port (commonly 8088/8089 depending on setup).

Problem: “ARI/AMI Integrations Fail (Timeout / Connection Refused)”

If you are integrating tools like dialers, CRMs, or AI calling (ARI/AMI), these are the key points:

• AMI (5038): high-risk management interface. Keep internal/VPN only.
• ARI (usually via Asterisk HTTP server 8088/8089): also keep internal/VPN only.
• Do not forward these ports to the internet.

Check AMI listening

sudo ss -lntp | grep 5038
sudo asterisk -rx "manager show settings"

Check ARI/HTTP listening

sudo ss -lntp | grep -E "8088|8089"
sudo asterisk -rx "http show status"

If your integration server is separate, connect it over VPN or private LAN.

SVG Diagram: Safe Exposure Pattern (Recommended)

This is the safest real-world pattern: expose as little as possible publicly, and use VPN for admin + internal APIs.

Hardening Checklist After Ports Are Correct

• Use strong admin passwords and disable unused accounts.
• Restrict FreePBX Admin UI by IP (OS firewall + FreePBX firewall).
• Use Fail2ban (or FreePBX firewall equivalent) and monitor bans carefully.
• Disable unused protocols (IAX2, chan_sip if not used, etc.).
• Keep system updated and minimize exposed services.

Security is not just “open the right ports” — it is “open the minimum ports” and restrict who can reach them.

Final Verification: Live Test Workflow (What to Check When Calls Still Fail)

1) Confirm server is reachable on required ports

# On a remote machine (replace IP)
nc -vz your-public-ip 443
nc -vz your-public-ip 5061
# UDP checks are trickier; use packet capture + Asterisk logs for SIP UDP

2) Watch SIP logs during a real call

sudo asterisk -rx "pjsip set logger on"

3) Watch RTP during the same call

sudo tcpdump -n -i eth0 udp portrange 10000-20000

With these three checks, you can quickly tell whether the problem is: (a) signaling, (b) media, or (c) a routing/NAT issue.

Key Takeaway

A correct FreePBX + Asterisk firewall is not “open everything telecom-related.” It is: open only what your topology requires, restrict by IP, and validate with real SIP + RTP tests.

If you want, next we can produce a companion article: “Router Configuration for SIP/VoIP: NAT, Port Forwarding, and SIP ALG” to cover the upstream side of the same issues.