Konfiguration der Firewall / des NAT Routers um SwyxWare SIP Trunks betreiben zu können

Zusammenfassung

Ab Version 5.00 der SwyxWare ist es möglich SIP Links zu konfigurieren um Telefongespräche nicht nur über ISDN und Analogleitungen zu führen, sondern auch direkt über IP-Strecken - Stichwort "Internettelefonie". Mit diesen SIP Links können Sie die SwyxWare direkt an einem SIP Provider (z.B. GMX, web.de etc.) anmelden.
Die grundsätzlichen Informationen und Konfigurationsnotwendigkeiten der SwyxWare entnehmen Sie bitte dem Handbuch, in diesem Artikel geht es um notwendige Modifikationen an der Firewall, die das Unternehmensnetzwerk vom Internet trennt um die SIP Links erfolgreich nutzen zu können.

Hinweis: Ab SwyxWare v6.00 wird die Bezeichnung SIP Trunk anstelle SIP Link verwendet

Information

Für die SIP-Anmeldung, SIP-Verbindungsaufbauten und Weiterleitungen der Audiodatenströme ist der Swyx LinkManager verantwortlich. Damit der Swyx Linkmanager erfolgreich mit SIP Providern und Gegenstellen im öffentlichen Internet kommunizieren kann ist eine entspr. Konfiguration der Firewall notwendig.

Es sind mehrere Szenarien vorstellbar wo der Swyx LinkManager im Verhältnis zur Firewall/dem Internet platziert werden kann, in diesem Artikel wird jedoch vom üblichen Szenario ausgegangen, dass der Swyx LinkManager auf der gleichen Servermaschine installiert ist, auf dem auch der SwyxServer installiert ist. Der SwyxServer befindet sich in der Regel im lokalen Netzwerk und hat damit eine private IP Adresse (z.B. 192.168.100.5), die nicht im Internet geroutet werden kann. Auch die Arbeitsstationen der Mitarbeiter mit SwyxIt! und die SwyxPhones befinden sich innerhalb dieses privaten Adressbereiches (192.168.100.x). Der Weg vom privaten IP Bereich in das Internet führt deshalb über einen NAT Router, der meist auch gleichzeitig Firewall ist. Dieser NAT Router steht also mit einem Port innerhalb des privaten IP Adressbereiches (z.B. 192.168.100.1) und mit einem zweiten Port innerhalb des öffentlichen Internet IP Netzes (z.B. 217.194.238.2).

Grundsätzlich funktioniert die Kommunikation aus dem privaten IP Adressbereich nun so, dass über den NAT Router eine Verbindung in das Internet hergestellt wird und z.B. der angesurfte Webserver nur die öffentliche IP Adresse des NAT Routers (217.194.238.2) sieht und seine Antworten bzw. die Webseiteninhalte an diese öffentliche IP Adresse zurücksendet. Der NAT Router hält nun eine Tabelle nach in der er Verbindungen von Clients aus dem privaten IP Bereich hin zum Internet verzeichnet und damit die Antworten aus dem öffentlichen Bereich wieder zurück an den Client im privaten IP Adressbereich leiten kann. Diese Tabelle besteht im wesentlichen aus Einträgen in denen die private IP Adresse + Port eines Clients der öffentlichen IP Adresse + Port des NAT Routers für ein Verbindung über den NAT Router in das Internet zugeordnet werden. Damit können Antworten aus dem Internet an den NAT Router von diesem an den entspr. Client weitergeleitet werden.

Diesen Mechanismus macht sich der Swyx LinkManager zu nutze um mit dem STUN Protokoll beim Start des Services die öffentliche IP Adresse und Port des NAT Routers in Erfahrung zu bringen, die für die SIP Kontrollnachrichten verwendet wird. Ebenfalls wird mit dem STUN Protokoll die öffentliche IP Adresse und Port des NAT Routers für die Audiodatenströme beim Verbindungsaufbau ermittelt. Das STUN Protokoll verwendet verschiedene Strategien um auch die Art der Tabellenverwaltung im NAT Router zu ermittlen. Nähere Informationen über das STUN Protokoll entnehmen Sie bitte dem entspr. RFC Standard (RFC 3489).

Über den NAT Router werden also STUN Nachrichten, die SIP Nachrichten für die Anmeldung am SIP Provider und den Verbindungsaufbau und letztlich die Audiodatenströme selber verschickt.

Damit muss eine evt. vorhandene Firewall für genau diese Kommunikation aufgeschaltet werden. Die hierfür notwendigen Regeln werden im folgenden aufgeführt und müssen auf Ihrer Firewall in der entspr. Syntax konfiguriert werden:

• Der SwyxLinkmanager versendet von Port 65002 die STUN Nachrichten an den konfigurierten STUN Server. Der Zielport für STUN Nachrichten ist meist der Port 3478, es gibt aber auch Ausnahmen, z.B. SIPGate verwendet den Port 10000. Die STUN Antwortnachrichten sollten natürlich auch zugelassen werden.
• Die SIP Nachrichten werden vom SwyxLinkmanger von Port 65002 an den SIP Port des SIP Providers geschickt. Der SIP Port ist meist der WellKnownPort 5060. Auch der umgekehrte Weg für die Antworten sollte aufgeschaltet werden.
• Für den Versand und den Empfang der Audiodatenströme in das Internet verwendet der SwyxLinkmanager der SwyxWare v5.00 die Ports 56000-57000, ab SwyxWare Version 5.01 wird der Portbereich 55000-56000 genutzt! Die Zieladresse und der Zielport lässt sich nicht im vorraus einschränken, da dies allein von der SIP Gegenstelle abhängig ist, die nicht bekannt ist (z.B. X-Lite Client, GMX Netphone o.ae.). Die umgekehrte Richtung muss auch aufgeschaltet sein.

Damit ergibt sich folgendes Regelwerk für die Firewall:

• Freischaltung des Versands von UDP STUN und SIP Nachrichten sowie Audiopaketen von der IP Adresse und den Ports 56000-57000 fuer SwyxWare v5.00 bzw. 55000-56000 fuer SwyxWare v5.01 und 65002 des SwyxLinkmanagers an den STUN Port 3478 eines beliebigen STUN Servers und den SIP Port 5060 eines SIP Providers (Bsp: IP:192.168.100.5, Port:56000-57000 (v5.00), 55000-56000 (> v5.01), 65002 =">" IP:beliebig, Port: 3478, 5060)
• Freischaltung des Empfangs von UDP SIP und STUN Nachrichten an den Port 65002 des Linkmanagers (Bsp: IP:beliebig, Port: beliebig =">" IP:192.168.100.5, Port:65002)
• Freischaltung der ausgehenden Audiodatenströme des Linkmanagers (Bsp: IP:192.168.100.5, Port:56000-57000 (v5.00), 55000-56000 (> v5.01) =">" IP:beliebig, Port:beliebig)
• Freischaltung der eingehenden Audiodatenströme an den Linkmanager (Bsp: IP:beliebig, Port:beliebig =">" IP:192.168.100.5, Port:56000-57000 (v5.00), 55000-56000 (> v5.01))

Natürlich können obige Regeln auch anders zusammengefasst/formuliert werden, aber die Aufteilung in Kontroll- und Audiodatenströme bietet sich an, sofern Ihre Firewall QoS für die Audiodatenströme unterstützt, wie das z.B. die Lancom Router/Firewalls unterstützen mit denen Swyx sehr gute Erfahrungen in diesem Bereich gemacht hat. Damit lassen sich die QoS Regeln direkt diesen Firewallregeln zuordnen.

Eine Besonderheit nehmen noch SIP ENUM Links ein. ENUM Links benötigen keinen getrennten SIP Provider für eine Anmeldung, sondern ein ENUM Link nimmt direkt die SIP Nachrichten der Gegenstelle entgegen. Um dieses Szenario zu unterstützen muss nun auf dem NAT Router ein Portforwarding eingerichtet werden, damit die SIP Nachrichten, die auf der öffentlichen IP Adresse des NAT Routers auf dem WellKnownPort 5060 eingehen auch an den Swyx LinkManager auf Port 65002 im internen Netz weitergeleitet werden. Bitte richten Sie deshalb auf dem NAT Router eine Portforwardingregel ein, die alle auf der öffentlichen IP Adresse und dem Port 5060 eingehenden Nachrichten vom NAT Router in das interne Netz auf die IP Adresse des Linkmanagers und den Port 65002 weiterleitet. Damit ist sichergestellt, dass die SIP Nachrichten auch beim Linkmanager ankommen (Bsp: Port:5060 der ext. Seite des NAT Routers =">" IP:192.168.100.5, Port:65002).

Für die ENUM Nummernauflösung unterstützt die SwyxWare zur Zeit die DNS Adressen *.e164.arpa (offizielles ITU Projekt) und das alternative Projekt *.e164.org.

Die STUN Nachrichten werden mindestens alle 10 Sekunden vom Swyx LinkManager verschickt, sofern kein anderer Datenverkehr über den entspr. Port fliesst, um sicherzustellen, dass die NAT (Masquerading) Tabelle des NAT Routers nicht wieder zerstört wird und um potentielle Änderungen der externen IP Adresse des NAT Routers zu ermittlen. D.h. die SIP Links der SwyxWare können auch hinter einem DSL Anschluss betrieben werden, der alle 24 Stunden vom IP Provider zwangsgetrennt wird und damit eine neue IP Adresse erhält.

Den LinkManager in einer DMZ zu platzieren wird nicht empfohlen, da die Clients (SwyxIt! und SwyxPhones) den LinkManager direkt für die Audiostromübertragung kontaktieren müssen und eine echte DMZ von LAN Clients in der Regel nicht erreicht werden kann.