Preparing the firewall for Asterisk

Scenario

The following example scenario shows a typical network and hardware configuration, which is the basis for this guide.

Asterisk Server (Raspberry Pi)	192.168.10.200
Allnet ALL-BM100VDSL2v	WAN IP
LinkSys router (OpenWRT) hinter DLS modem	192.168.10.1
SIP phone (OpenStage, Snom, Zoiper client)	192.168.10.11	+49 211 562 152 01
SIP phone (OpenStage, Snom, Zoiper client)	192.168.10.12	+49 211 562 152 02
SIP phone (OpenStage, Snom, Zoiper client)	192.168.10.13	+49 211 562 152 03

The Asterisk server is located in a separate VoIP network (e.g., 192.168.10.0/24), which is separated from the rest of the intranet (e.g., 192.168.0.0/24) by a firewall—here, a LinkSys router with OpenWRT. This ensures that the server is protected from unauthorized external access. The network separation is implemented using VLANs.

The LinkSys router was configured with virtual LANs as documented here in order to explicitly separate the telephony network from the actual data network in the intranet.

SIP/RTP – Protocols for VoIP

Asterisk uses two protocols to communicate with SIP devices and the VoIP provider (e.g. Telekom):

• SIP (Session Initiation Protocol) – responsible for connection setup, termination and administration.
• RTP (Real-Time Transport Protocol) – for the actual transmission of audio (and possibly video) data streams.

As a provider, Telekom uses different URLs such as tel.t-online.de to register outgoing connections, depending on the product ordered – which becomes important when configuring with FreePBX. Incoming SIP and RTP traffic can come from the IP address range 217.0.0.0/13, as Telekom uses dynamically changing servers for this purpose.

Firewall port forwarding

In order for communication with the Asterisk server to work, the following port forwarding must be set up on the firewall (here OpenWRT):

SIP Signaling

• Protocol: UDP
• Source IP: 217.0.0.0/13
• Destination IP: Public WAN IP of the router
• Destination port: 5060
• Forwarding to: 192.168.10.200:5060

RTP audio transmission

• Protocol: UDP
• Source IP: 217.0.0.0/13
• Destination IP: 30000–30100
• Forwarding to: 192.168.10.200:30000–30100

Configuration in the file /etc/asterisk/rtp.conf:

[general]
rtpstart=30000
rtpend=31000

NAT for SIP connections

Unlike HTTP or other protocols, with SIP, a simple NAT (Network Address Translation) is not sufficient to correctly rewrite communication. Why?

• With classic NAT, only the IP header of the packet is changed.
• However, SIP also contains the IP address in the application data area (payload) – e.g. in SDP messages within the SIP packets.
• These internal IP addresses (e.g. 192.168.x.x) are invalid for the provider – the return channel then does not work because the remote station does not know where to send the media streams.

SIP-enabled NAT with kernel modules as a solution

In order for the router to correctly rewrite the SIP-specific content, special kernel modules are required:

• nf_conntrack_sip – detects SIP connections and can track their status.
• nf_nat_sip – enables rewriting IP addresses and ports within the SIP payload.

The package kmod-nf-nathelper-extra is installed and the modules are loaded with

~# opkg install kmod-nf-nathelper-extra
~# modprobe -v nf_conntrack_sip nf_nat_sip

Why do typical consumer routers fail with Asterisk?

Devices such as the Fritzbox, Speedport or other consumer routers do not usually require these modules because

• they themselves are directly connected to the Internet (no NAT in between).
• the integrated DSL modem is already connected to the public IP.
• the devices already have SIP adaptations built in internally (“SIP ALG”), but often in a proprietary way and not transparently configurable.

1. SIP ALG (Application Layer Gateway):
   • This feature is intended to "help" VoIP by modifying SIP packets (e.g., replacing IP addresses in them).
   • The problem, however, is that on many consumer routers, this cannot be turned off or is not implemented properly, which causes more problems than solutions - e.g. one-sided audio or failed connections.
2. No possibility for port forwarding or NAT customization in detail:
   • Consumer routers often offer no or very limited configuration options for NAT, port forwarding, or dynamic firewall rules.
   • However, Asterisk requires an exact NAT configuration, such as:
     • SIP port forwarding (usually 5060 UDP)
     • RTP port forwarding (audio, e.g. 10000–20000 UDP)
     • correct externip and localnet settings in sip.conf or pjsip.conf
3. Lack of transparency:
   • The Fritzbox & Co. do a lot of things internally “automatically”, but this is not documented or controllable for server operation.
   • This results in the Asterisk server detecting incorrect external IP addresses or being unable to establish return channels for audio.

When can Asterisk still work?

• If the Asterisk server is directly connected to the public Internet (e.g. vServer or with public IP via bridge).
• If you have NAT and SIP explicitly under control, for example with:
  • OpenWRT with manual port forwarding and firewall customization
  • SIP ALG is deactivated
  • Asterisk is correctly configured for NAT.

Conclusion

A separate Asterisk server behind a typical consumer router usually works poorly or not at all without in-depth configuration or suitable network equipment. Anyone who wants to run Asterisk should rely on transparently configurable routers (e.g., OpenWRT, pfSense, MikroTik) or run the server directly with a public IP address.