Vorbereiten der Firewall für den Einsatz von Asterisk

Szenario

Im folgenden Beispiel-Szenario wird eine typische Netzwerk- und Hardwarekonfiguration dargestellt, wie sie dieser Anleitung zugrunde liegt.

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

Der Asterisk-Server befindet sich in einem separaten VoIP-Netzwerk (z. B. 192.168.10.0/24), das über eine Firewall – hier ein LinkSys-Router mit OpenWRT – vom restlichen Intranet (z. B. 192.168.0.0/24) abgetrennt ist. Dadurch wird sichergestellt, dass der Server vor unberechtigtem Zugriff von außen geschützt ist. Die Netz-Trennung wird durch VLANs umgesetzt.

Der LinkSys-Router wurde wie hier dokumentiert mit Virtuellen LANs konfiguriert, um das Telefonie-Netzwerk explizit vom eigentlichen Datennetzwerk im Intranet abgrenzen zu können.

SIP/RTP – Protokolle für VoIP

Asterisk nutzt zwei Protokolle zur Kommunikation mit SIP-Endgeräten und dem VoIP-Provider (z. B. Telekom):

• SIP (Session Initiation Protocol) – zuständig für den Verbindungsaufbau, -abbau und Verwaltung.
• RTP (Real-Time Transport Protocol) – für die eigentliche Übertragung von Audio- (und ggf. Video-)Datenströmen.

Die Telekom als Provider verwendet unterschiedliche URLs wie tel.t-online.de zur Registrierung ausgehender Verbindungen, abhängig vom bestellten Produkt – was wichtig wird bei der Konfiguration mit FreePBX. Eingehender SIP- und RTP-Verkehr kann aus dem IP-Adressbereich 217.0.0.0/13 kommen, da die Telekom dafür dynamisch wechselnde Server einsetzt.

Firewall-Portweiterleitungen

Damit die Kommunikation mit dem Asterisk-Server funktioniert, müssen auf der Firewall (hier OpenWRT) folgende Portweiterleitungen eingerichtet werden:

SIP-Signalisierung

• Protokoll: UDP
• Quell-IP: 217.0.0.0/13
• Ziel-IP: Öffentliche WAN-IP des Routers
• Ziel-Port: 5060
• Weiterleitung an: 192.168.10.200:5060

RTP-Audioübertragung

• Protokoll: UDP
• Quell-IP: 217.0.0.0/13
• Ziel-Portbereich: 30000–30100
• Weiterleitung an: 192.168.10.200:30000–30100

Konfiguration in in der Datei /etc/asterisk/rtp.conf:

[general]
rtpstart=30000
rtpend=31000

NAT bei SIP-Verbindungen

Anders als bei HTTP oder anderen Protokollen reicht bei SIP ein einfaches NAT (Network Address Translation) nicht aus, um die Kommunikation korrekt umzuschreiben. Warum?

• Bei klassischem NAT wird nur der IP-Header des Pakets geändert.
• SIP enthält aber auch die IP-Adresse im Anwendungsdatenbereich (Payload) – z. B. in SDP-Nachrichten innerhalb der SIP-Pakete.
• Diese internen IP-Adressen (z. B. 192.168.x.x) sind für den Provider ungültig – der Rückkanal funktioniert dann nicht, weil die Gegenstelle nicht weiß, wohin sie die Medienströme senden soll.

SIP-fähiges NAT mit Kernel-Modulen als Lösung

Damit der Router auch die SIP-spezifischen Inhalte korrekt umschreibt, sind spezielle Kernel-Module notwendig:

• nf_conntrack_sip – erkennt SIP-Verbindungen und kann deren Zustand nachverfolgen.
• nf_nat_sip – ermöglicht das Umschreiben der IP-Adressen und Ports auch innerhalb der SIP-Nutzdaten.

Installiert wird das Paket kmod-nf-nathelper-extra geladen werden die Module mit

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

Warum scheitern typische Consumer-Router bei Asterisk?

Geräte wie die Fritzbox, Speedport oder andere Consumer-Router benötigen diese Module in der Regel nicht, weil

• sie selbst direkt mit dem Internet verbunden sind (kein NAT dazwischen).
• das integrierte DSL-Modem bereits an der öffentlichen IP hängt.
• die Geräte intern bereits SIP-Anpassungen eingebaut haben („SIP ALG“), allerdings oft auf proprietäre Weise und nicht transparent konfigurierbar.

1. SIP ALG (Application Layer Gateway):
   • Diese Funktion soll VoIP "helfen", indem sie SIP-Pakete modifiziert (z. B. IP-Adressen darin ersetzt).
   • Das Problem ist, dass bei vielen Consumer-Routern ist das nicht abschaltbar oder nicht sauber implementiert, was mehr Probleme als Lösungen verursacht – z. B. einseitiges Audio oder fehlschlagende Verbindungen.
2. Keine Möglichkeit zur Portweiterleitung oder NAT-Anpassung im Detail:
   • Consumer-Router bieten oft keine oder nur sehr eingeschränkte Konfigurationsmöglichkeiten für NAT, Portweiterleitungen, oder dynamische Firewallregeln.
   • Asterisk benötigt aber eine exakte NAT-Konfiguration, wie:
     • Weiterleitung von SIP-Port (meist 5060 UDP)
     • Weiterleitung von RTP-Ports (Audio, z. B. 10000–20000 UDP)
     • korrekte externip und localnet-Einstellungen in sip.conf oder pjsip.conf
3. Fehlende Transparenz:
   • Die Fritzbox & Co. machen intern viel „automatisch“, was aber für einen Serverbetrieb nicht dokumentiert oder steuerbar ist.
   • Das führt dazu, dass der Asterisk-Server falsche externe IP-Adressen erkennt oder keine Rückkanäle für Audio aufbauen kann.

Wann kann Asterisk trotzdem funktionieren?

• Wenn der Asterisk-Server direkt am öffentlichen Internet hängt (z. B. vServer oder mit öffentlicher IP via Bridge).
• Wenn man NAT und SIP explizit im Griff hat, zum Beispiel mit:
  • OpenWRT mit manueller Portweiterleitung und Firewall-Anpassung
  • SIP ALG deaktiviert ist
  • Asterisk für NAT richtig konfiguriert ist.

Schlussfolgerung

Ein separater Asterisk-Server hinter einem typischen Consumer-Router funktioniert meist schlecht oder gar nicht, wenn man keine tiefergehende Konfigurationen macht oder geeignete Netzwerkgeräte hat. Wer Asterisk betreiben will, sollte auf transparent konfigurierbare Router (z. B. OpenWRT, pfSense, MikroTik) setzen oder den Server direkt mit einer öffentlichen IP betreiben.