Frequently Asked Question
NATSNATForwards for AsteriskFreePBX
What ports do I need to forward for an Asterisk server behind NAT?
Below is an overview of the minimum port‑forwarding that most SIP trunk deployments require. It is deliberately not tied to any particular firewall model – you can apply the same concepts on a home router, a small‑business UTM, or a cloud‑hosted security group.
1. SIP signalling – UDP 5060 (or the port you have configured)
| Direction | Why it is needed | Where it goes |
|---|---|---|
| Inbound | The ITSP sends INVITE, REGISTER, BYE, etc. to your Asterisk. | Forward UDP 5060 from the ITSP’s public IP (or the whole ITSP subnet) to the internal IP address of the Asterisk server. |
| Outbound | Your Asterisk must be able to reach the ITSP to register the trunk and send calls. | Allow outbound UDP 5060 from the Asterisk server to the ITSP’s subnet. No NAT translation is required beyond the normal external IP of your router. |
If you have moved the SIP signalling port to something other than 5060 (e.g. 5160), replace 5060 with that number in both directions.
2. RTP media – UDP 10000‑20000 (or the range you have defined)
| Direction | Why it is needed | Where it goes |
|---|---|---|
| Inbound | The ITSP sends the audio streams (RTP) back to you. | Forward the entire UDP range 10000‑20000 from the ITSP subnet to the Asterisk server’s internal IP. |
| Outbound | Asterisk sends its own RTP packets to the ITSP. | Permit outbound UDP 10000‑20000 from the Asterisk server to the ITSP subnet. |
Tip: Keep the RTP range as narrow as possible – the default 10000‑20000 is safe for most installations, but you can reduce it (e.g. 10000‑12000) if you know you will never need more simultaneous calls.
3. What must NOT be exposed to the Internet
| Port / Service | Reason to keep it private |
|---|---|
| HTTP/HTTPS (e.g. 80, 443) for the Asterisk web UI (FreePBX, Sangoma UI, etc.) | Allows anyone on the Internet to attempt brute‑force logins or exploit web‑application bugs. |
| Any other management ports (SSH 22, VNC, RDP, etc.) | Same risk – expose only on a trusted internal network or via a VPN. |
| SIP over TCP/TLS if you are not using them | Unnecessary exposure adds attack surface. |
Bottom line: Only the two UDP ranges above should be reachable from the ITSP. All other inbound traffic should be blocked at the perimeter firewall.
4. Built‑in Sangoma firewall – should it be disabled?
- The Sangoma firewall (the one that ships with the Sangoma appliance) is a very basic, state‑ful filter that can interfere with SIP and RTP traffic, especially when NAT is involved.
- For a clean, predictable setup, disable the Sangoma firewall and manage all rules from your external firewall/router.
- Keep Intrusion detection - fail2ban unless there is a reason not to.
Fail2ban will automatically block IPs that repeatedly send malformed SIP requests or try to guess passwords, providing a lightweight intrusion‑prevention layer.
5. Authentication – make it hard to break in
| Item | Recommended practice |
|---|---|
| Trunk authentication | Use IP‑based authentication or username/password (or both). If the ITSP supports IP whitelisting, lock the trunk to the ITSP’s public IP range. |
| PJSIP endpoints (extensions) | - Enable authentication for every endpoint. - Use strong, unique passwords (minimum 12 characters, mix of upper‑/lower‑case, numbers and symbols). - Prefer digest authentication over plain‑text if supported. |
| IP‑based rules (optional but highly recommended) | use match/permit to specify the fixed IP of the endpoint |
| TLS (if available) | If the ITSP offers TLS signalling, switch to TCP 5061 (or the port they give) and enable TLS certificates – this encrypts SIP signalling but brings with it much complexity. |
Following these steps will give you a tight, NAT‑friendly configuration that only exposes the ports the ITSP truly needs, while keeping the rest of your server safely behind the firewall.
