SIP (VoIP) und Firewall

Bei der Konfiguration von Voice-over-IP (VoIP) über SIP kommt es immer wieder zu Problemen aufgrund fehlerhafter Firewall-Konfiguration. Leider ist dieses Protokoll auch nicht sehr "firewall-freundlich". Erschwerend kommt hinzu, dass seitens der Telefontechniker oft kontraproduktive Anforderungen bezüglich der Firewall-Konfiguration formuliert werden.

Das SIP-Protokoll (TCP oder UDP Port 5060) dient lediglich der Signalisierung. Das Telefon bzw. die Telefonanlage meldet sich über SIP beim SIP-Provider an und die Anrufe selbst werden darüber gesteuert (wer ruft wen an, Angerufener nimmt den Hörer ab, Gespräch wird beendet usw.).

Die eigentlichen Sprachdaten werden hingegen über das RTP-Protokoll gesendet. Es handelt sich dabei um UDP-Datenströme über frei ausgehandelte Portnummern. Und genau hier entsteht die Schwierigkeit für NAT-Router und Firewalls: Die Portnummer ist nicht festgelegt sondern wird über das SIP-Protokoll dynamisch ausgehandelt und zwar unabhängig für die ausgehende und die eingehende Gesprächsrichtung. Erschwerend kommt hinzu, dass die Gesprächsdaten nicht zwingend über die gleichen IP-Adressen laufen müssen wie das SIP-Protokoll. So könnten die lokale SIP-Telefonanlage und der SIP-Provider aushandeln, dass die RTP-Kanäle direkt zwischen der IP des lokalen Telefons und der IP eines RTP-Proxies beim Provider aufgebaut werden sollen. RTP-Proxies kommen in der Praxis häufig zum Einsatz.

Ein vereinfachtes Beispiel:

• Schritt 1: Die TK-Anlage mit der internen IP 192.168.0.1 öffnet eine Verbindung zum SIP-Provider mit der IP 203.0.113.1 auf Port 5060. Die TK-Anlage meldet sich über diese Verbindung beim SIP-Provider an (REGISTER) und hält die Verbindung offen.
• Schritt 2: Einige Zeit später signalisiert der SIP-Provider über diese Verbindung einen Anruf (INVITE). Als Teil dieser Nachricht legt der SIP-Provider fest, dass Sprachdaten (RTP) an die IP des RTP-Proxies 203.0.113.99 auf Port 7000 gesendet werden sollen.
• Schritt 3: Die TK-Anlage meldet den Fortschritt (Trying, Ringing) und schließlich, dass der Teilnehmer abgenommen hat (OK). Mit dem OK teilt die TK-Anlage mit, dass Sprachdaten (RTP) an die IP der TK-Anlage 192.168.0.1, Port 14000 gesendet werden sollen.

Schritt 1 ist eine einfache, ausgehende Verbindung zu Port 5060 über TCP oder UDP, die jeder NAT-Router bewerkstelligen kann. Bei einer Verbindung über UDP ist wichtig, dass der NAT-Router die Verbindung nicht zu schnell "vergisst". Der Kanal muss offen bleiben, da der SIP-Provider eingehende Anrufe darüber signalisieren muss. In der Praxis ist dies üblicherweise kein Problem, denn die TK-Anlage erneuert regelmäßig die Registrierung.

Auch bei Schritt 2 handelt es sich um eine einfache ausgehende Verbindung über NAT. Timeouts sind kein Problem, da alle 10-20ms ein Sprachpaket gesendet wird.

Schwierig wird es mit Schritt 3. Zum einen wird die interne IP der TK-Anlage an den Provider geschickt (im Beispiel 192.168.0.1). Diese ist aber für den SIP-Provider aus dem Internet nicht direkt ansprechbar. Zum anderen wird der Provider nach Aufbau des Gesprächs RTP-Pakete an den von der TK-Anlage übermittelten Port schicken (im Beispiel Port 14000), die der NAT-Router an die TK-Anlage weiterleiten muss.

Auch hier ist Schritt 1 unproblematisch. Für die TK-Anlage muss lediglich ausgehend der Port 5060 freigegeben werden.

Für Schritt 2 werden ausgehende Verbindungen zu beliebigen UDP-Ports von 1024 an aufwärts benötigen. Meist ist die Freigabe nur für die IP der TK-Anlage erforderlich. Eventuell müssen aber auch die IPs der SIP-Telefone erlaubt werden. Der tatsächlich genutzte Portbereich ist in der Regel kleiner. Prüfen Sie bitte die Unterlagen Ihres Providers, ob er Ihnen einen definierten Portbereich mitgeteilt hat.

Andersherum verlangt Schritt 3 die Weiterleitung aller eingehenden UDP-Verbindungen für Ports ab 1024 zur TK-Anlage. Hier kann der Konfiguration der TK-Anlage entnommen werden, welcher Portbereich tatsächlich eingehend weitergeleitet werden muss. Eine direkte Weiterleitung an Telefone ist in der Regel nicht notwendig und wäre in der Praxis nur über unterschiedliche Port-Bereiche machbar.

Die DEFENDO-Firewall entält ein Application-Layer-Gateway (ALG) für SIP. Es löst sowohl das NAT- als auch das Firewall-Problem optimal. Dazu überwacht es die Kommunikation von Verbindungen zu Port 5060. Wird ein ein- oder ausgehender RTP-Sprachkanal angefordert, richtet das SIP-ALG automatisch temporäre Freigaben in der Firewall ein - und zwar nur genau für die beteiligten IP-Adressen und Ports. Wird das Gespräch beendet, werden auch die Freigaben in der Firewall entfernt. Im selben Zuge kümmert sich das ALG auch um NAT: Ist für die SIP-Verbindung NAT erforderlich, wird auch für die RTP-Verbindungen SNAT bzw. DNAT genutzt. Ferner werden interne IP-Adressen bei der Signalisierung (interne IP-Adresse der TK-Anlage oder der Telefone, Schritt 3) durch die externe IP des DEFENDOs ersetzt, so dass der SIP-Provider eine gültige IP-Adresse erhält, die er auch tatsächlich kontaktieren kann.

Zur Konfiguration ist im DEFENDO lediglich eine Weiterleitungs-Regel in der Firewall-Konfiguration der Internet-Schnittstelle erforderlich, die das Protokoll SIP von der TK-Anlage zum SIP-Provider erlaubt. Zusätzlich eventuelle Ports zur Aktualisierung der Telefonanlagen-Software.

In der Welt der Telefontechniker haben SIP-ALGs keinen guten Ruf. Häufig wird von Anfang an gefordert, das SIP-ALG zu deaktivieren. Bei verschlüsselten Verbindungen kann das SIP-ALG nicht mitlesen und ist somit außen vor.

Falls das SIP-ALG des DEFENDOs dennoch deaktiviert werden soll: Diese Einstellung kann derzeit nur vom technischen Support via Fernwartung vorgenommen werden. Das SIP-ALG kann sowohl komplett als auch für Verbindungen zu einzelnen SIP-Servern deaktiviert werden.

Folgende Weiterleitungs-Regeln sind in der Internet-Schnittstelle des DEFENDOs zu konfigurieren:

• SIP bzw. SIPS von der IP der TK-Anlage zum SIP-Provider (nutzen Sie DNS-IP-Objekte, wenn nur ein DNS-Name oder DNS-SRV-Record vom SIP-Provider bekannt ist, hilfsweise ein Geolokations-Objekt z.B. für Land "DE")
• UDP von der IP der TK-Anlage ins Internet (sofern die Information verfügbar ist: nur zu den vom Provider mitgeteilten Ports und/oder IP-Bereichen, hilfsweise ein Geolokations-Objekt, sofern alle Gespräche über nationale RTP-Proxies des Providers laufen)
• Ggf. STUN von der IP der TK-Anlage zu den in der TK-Anlage konfigurierten STUN-Servern (nutzen Sie DNS-IP-Objekte, wenn nur ein DNS-Name oder DNS-SRV-Record vom SIP-Provider bekannt ist). Die TK-Anlage ermittelt über STUN die externe IP-Adresse des DEFENDOs und verwendet diese externe IP anstelle der eigenen internen IP bei der Signalisierung (siehe Schritt 3).
• Zusätzlich eventuelle Ports zur Aktualisierung der Telefonanlagen-Software

DNAT-Regeln sind in der Internet-Schnittstelle des DEFENDOs nicht erforderlich, falls symmetrisches RTP zum Einsatz kommt. Dabei werden die über SIP ausgehandelten RTP-Ziel-Ports zugleich als Quell-Port für den Kommunikationskanal in der Gegenrichtung verwendet. Das erste ausgehende Sprachpaket schaltet die Verbindung frei, eingehende Sprachpakete werden dann automatisch als Antwortpaket akzeptiert. Es kann dabei vorkommen, dass die ersten eingehenden Pakete noch von der Firewall verworfen werden.

Ohne symmetrisches RTP ist eine DNAT-Regel erforderlich. Leiten Sie UDP-Pakete zu den in der TK-Anlage konfigurierten RTP-Ports an die IP der TK-Anlage weiter. Schränken Sie dabei die Quelle wenn möglich auf vom Provider mitgeteilte IP-Bereiche ein. Nutzen Sie hilfsweise ein Geolokations-Objekt z.B. für Land "DE").

Weitere DNAT-Regeln sind für die Anbindung einer TK-Anlage an einen SIP-Provider nicht erforderlich! Insbesondere ist es nicht erforderlich, den SIP-Port per DNAT an die TK-Anlage weiterzuleiten. Das Internet wird laufend nach offenen SIP-Ports durchsucht!

Viele Hersteller von TK-Anlagen bieten eigene, proprietäre Applikation oder Apps zur Anbindung externer Geräte. In der Regel müssen dazu einzelne Ports per DNAT an die TK-Anlage weitergeleitet werden. Achten Sie auf Verschlüsselung und schränken Sie den Zugang ggf. zeitlich und/oder über Geolokations-Objekte ein.

Sollen SIP-Telefone (Hard- oder Software) angebunden werden, raten wir von einer Freigabe des Ports 5060 ab. Nutzen Sie nach Möglichkeit ein VPN. Sollte ein VPN nicht möglich sein, nutzen Sie die Kombination aus SIPS und SRTP. Dazu ist eine eingehende DNAT-Regel für SIPS erforderlich. Schränken Sie diese ggf. zeitlich und/oder über Geolokations-Objekte ein. Für SRTP sind UDP-Weiterleitungsregeln ins Internet erforderlich (Port-Bereich wie in den SIP-Telefonen konfiguriert), außerdem die DNAT-Regel zur TK-Anlage für die in der TK-Anlage konfigurierten Ports.

Sofern ein Fernwartungszugang für die TK-Anlage per DNAT erwünscht ist, sollten Sie die Regel nur bei Bedarf temporär aktivieren (Regel aktivieren bis Datum und Uhrzeit) und/oder nur für den IP-Bereich des entsprechenden Unternehmens freigeben (nutzen Sie DNS-IP-Objekte, wenn nur ein DNS-Name bekannt ist, hilfsweise ein Geolokations-Objekt z.B. für Land "DE").

AGFEO-Anlagen an Telekom-Anschluss: Wenn Gespräche nach mehreren Minuten einfach Abbrechen und der Anschluss zeitweise nicht erreichbar ist, liegt das an unterschiedlichen Zeitintervallen für die Neuregistrierung. Die Telekom meldet 660 Sekunden, die Anlage besteht aber offenbar auf die voreingestellten 1200 Sekunden. Ändern Sie in der AGFEO TK-Anlage bitte die Einstellung "Gewünschte Gültigkeitsdauer einer Registrierung (Sek.)" auf z.B. 600.