Asterisk an VoIP-Anschluss der Telekom Deutschland GmbH

Es ist absolut nachvollziehbar, das die Telekom angesichts der Fülle möglicher Hard- und Softwarekonfigurationen auf Kundenseite keine individuellen Konfigurationsanleitungen bereitstellen kann, die alle Varianten abdecken. Das Kundencenter beschränkt sich daher auf Informationen zu den Fragen "Welche Einstellungen sind für die IP-Telefonie mit anderen Clients notwendig? " und "Welche Ports muss ich für die IP-Telefonie in der Firewall freigeben? " . Für die Anbindung eines Asterisk-Servers hinter einer NAT-Firewall haben diese Informationen für mich nicht ausgereicht. Deshalb habe ich hier einige ergänzende Details zusammengestellt.
Ich habe zudem beobachtet, dass die Telekom gelegentlich Konfigurationsparameter verändert, so dass eine zunächst funktionierende Konfiguration nicht mehr läuft. Deshalb sei nochmals explizit darauf hingeweisen, dass diese Informationen den Sachstand zum Zeitpunkt der Erstellung dieser Seite wiedergeben.

Die Portangaben auf den beiden verlinkten Seiten sind etwas widersprüchlich und vergleichsweise umfangreich. Sie gleichen einem "Rundumschlag", der vermutlich für möglichst viele Konfigurationen passen soll. Aus Sicherheitsgründen ist es jedoch ratsam, nicht mehr Ports für eingehenden Datenverkehr freigeben, als unbedingt notwendig:

• Freigabe von UDP 5060 IN, dem Standard-Port für SIP. Es ist allerdings unklar, ob die Telekom diesen Port für SIP-Signalisierung verwendet.
• Freigabe von UDP 5070 IN, untypisch für SIP, aber von den oben zitierten Links gefordert.
• Freigabe von UDP 30000-30099 IN für RTP. Das Kundencenter fordert widersprüchlich 30000-30005 auf der einen Seite und 30000-31000 auf der anderen. Der kleine Bereich scheint zu genügen, allerdings blockiert eine einzelne Verbindung bereits 2 Ports und Asterisk scheint benutzte Ports auch nicht immer sofort wieder frei zu geben, so dass bei Freigabe von nur 30000-30005 für Asterisk schon mal die freien Ports ausgehen können.
• Die von den Links benannten Port UDP 3478 IN und UDP 3479 IN sind offenbar nur bei der Verwendung von STUN notwendig. Wenn man seine externe IP-Adresse anderweitig ermittelt (siehe unten) und kein STUN verwendet, dann braucht man auch diese Ports nicht freizugeben.
• Die typischen Firewalls für den Privathaushalt filtern standardmäßig den ausgehenden Datenverkehr nicht, so dass für ausgehende Verbindungen keine besonderen Einstellungen erforderlich sind. Im Fall der Filterung sollten UDP 5060 OUT (für SIP) und UDP 30000-30099 OUT (für RTP) genügen (ohne Berücksichtigung von STUN).
• Die Notwendigkeit der übrigen in den den Links benannten Ports (UDP 40000-40100 IN/OUT oder TCP 80 IN/OUT) für die SIP-Telefonie erschliesst sich nicht, diese Ports können geschlossen bleiben, sofern keine anderen Anwendungen diese erfordern.
• Die zu verwendenden RTP-Ports müssen Asterisk mitgeteilt werden. Dazu im File rtp.conf die Parameter rtpstart=30000 und rtpend=30099 setzen. Für eine RTP-Verbindung verwendet Asterisk offenbar immer einen Port mit gerader Nummer und zusätzlich den Port mit der um 1 höheren Nummer. Der Portbereich für eingehenden RTP-Verkehr an der Firewall muss daher auf der ungeraden Nummer enden.
• Es versteht sich von selbst, dass die freigeschalteten Ports auch per Port-Forwarding auf den Asterisk-Server durchgeschaltet werden müssen und dort durch interne/Software-Firewalls nicht blockiert werden dürfen.

Um darüber hinaus Anrufe von der Telekom empfangen zu können, muss sich Asterisk beim Telekom-Server registrieren:

• In der sip.conf braucht es dazu unter [general] einen Eintrag register => aaa:bbb:ccc-ddd@t-online.de@tel.t-online.de/eee mit folgenden Daten
  • aaa Rufnummer mit Vorwahl, ohne Leerzeichen
  • bbb Ziffernkombination des persönlichen Kennwortes (aus dem Schreiben "Ihre persönlichen Zugangsdaten")
  • ccc Zugangsdaten, vormals T-Online Nummer (aus dem Schreiben "Ihre persönlichen Zugangsdaten")
  • ddd Mitbenutzernummer (aus dem Schreiben "Ihre persönlichen Zugangsdaten"), typisch 0001
  • eee die Extension, mit der Asterisk in den Dialplan einsteigt, wenn eine SIP-Signalisierung von dem hier registrierten User (d.h. von "aaa:bbb:ccc-ddd@t-online.de") eintrifft. Zur Vermeidung von Verwirrung kann man hier die eigene Rufnummer angeben, d.h. die Nummer aus aaa ohne Vorwahl.
• Diese Registrierung muss für jede eigene Rufnummer ausgeführt werden, die aus dem Telekom-Netz angewählt werden können soll, also typisch drei mal mit den jeweiligen Nummern aaa.

Es ist wichtig zu verstehen, dass die Registrierung des Asterisk-Servers bei den Telekom-Servern nichts mit Authentifizierung von eingehenden Telefonaten auf unserer Seite zu tun hat. Das bedeutet, dass über die geöffneten eingehenden Ports an der Firewall jedermann (und nicht nur die Telekom) Daten und SIP-Pakete an Asterisk senden kann und schlimmstenfalls, insbesondere bei einer Fehlkonfiguration von Asterisk, über den eigenen Anschluss Anrufe tätigen kann. Um dieses Risiko zu reduzieren, kann man die Firewall so konfigurieren, dass die eingehenden IP-Pakete an den oben beschriebenen Ports nur dann akzeptiert werden, wenn sie von der Telekom kommen. Das Problem besteht nun darin, dass die Telekom Loadbalancing einsetzt, so dass zwar die Registrierung bei tel.t-online erfolgt, die SIP-Signalisierung für eingehende Anrufe aber von einem ganz anderen Server, z.B. m-ipp-a01.isp.t-ipnet.de kommt, der durchaus eine ganz andere IP-Adresse haben kann (je nach Region und Last scheinen sich hier unterschiedliche Server zu melden). Allerdings scheinen alle VoIP-Server der Telekom im Addressbereich 217.0.0.0 bis 217.7.255.255 zu liegen, so dass der aus dem Telekom-Netz eingehende VoIP-Verkehr (SIP und RTP) per Firewall auf diesen IP-Adressbereich eingeschränkt werden kann.

Weitere Konfigurationseinstellungen für Asterisk in der sip.conf im [general] Kontext:

• context=xyz definiert den Default-Kontext. Dort landen alle Anrufe, die nicht anderweitig zugeordnet werden können. Wie oben beschrieben, kann durch die geöffneten Ports jedes SIP-Paket zum Asterisk vordringen, selbst wenn es nicht von der Telekom kommt. Umso wichtiger ist es, dass im Default-Kontext keine Verbindungen aufgebaut werden können und schon gar nicht raustelefoniert werden kann. Der Default-Kontext sollte daher einen Namen wie "fake", "forbidden", "unspecified" oder ähnlich bekommen (d.h. xyz entsprechend ersetzen), in extensions.conf definiert sein, aber ausser einem Hangup nichts weiter enthalten. Die eigentliche Telefonie sollte über dedizierte Kontexte laufen. Es gibt einige Seiten im Netz über die Absicherung von Asterisk, die das näher beschreiben.
• allowguest=no verhindert anonyme Anrufe und erhöht die Sicherheit. Verschiedentlich wird im Netz empfohlen, hier ein "yes" zu setzen, um das oben geschilderte Loadbalancing-Problem zu umgehen. Das ist jedoch riskant und auch nicht notwendig.
• srvlookup=yes sorgt dafür, dass ausgehende Anrufe beim Telekom-Server landen.
• allow=alaw. Die Telekom unterstützt, ganz im ISDN-Stil, nur den Alaw-Codec für die VoIP-Telefonie. Es ist nicht schädlich, wenn in sip.conf noch andere Codecs erlaubt sind, aber der Alaw-Codec darf nicht fehlen.
• alwaysauthreject=yes. Nicht unbedingt notwendig für die Anbindung an die Telekom, sondern eine Steigerung der Sicherheit gegen unerlaubte SIP-Telefonie auf Grund der geöffneten Firewall. Bewirkt, dass bei Ablehnung einer Verbindung anstatt einer aussagekräftigen Fehlermeldung einfach der angefragte Nutzernamen wieder zurückgeschickt wird, so dass die Gegenseite nicht erkennen kann, ob dieser Nutzer tatsächlich existiert.
• contactdeny=0.0.0.0/0.0.0.0 und contactpermit=n.n.n.n/m.m.m.m (in dieser Reihenfolge) bewirken, dass eingehende Registrierungen nur aus dem contactpermit-Netz zulässig sind. Hier muss das eigene/interne Netzwerk gesetzt werden (also z.B. 192.168.0.0/255.255.255.0) in dem die lokalen Telefone leben, so dass von extern keine Regstrierungen möglich sind.
• localnet=n.n.n.n/m.m.m.m macht Asterisk klar, was das eigene Netzwerk ist (und was folglich nicht das eigene Netzwerk ist). Wird für NAT-Firewalls (also eigentlich immer im Privatbereich) benötigt und muss mit dem lokalen Netz konfiguriert werden (also z.B. 192.168.0.0/255.255.255.0).
• externhost=meinhost.dyndns.org teilt Asterisk die externe IP-Adresse mit, die für die Funktion hinter einer NAT-Firewall erforderlich ist. Alternativ könnte man STUN konfigurieren. Viele Firewalls verfügen aber über die Möglichkeit, einen Wechsel der externen IP-Adresse an einen Dynamic DNS Service zu melden. Jeder dieser Services ist in Ordnung, es muss nicht dyndns.org sein. Gibt man Asterisk hier den entsprechenden eigenen Hostnamen beim Dynamic DNS Service an, so ergibt die Namensauflösung per DNS für Asterisk genau die gesuchte externe IP-Adresse (diejenige auf der Außenseite der Firewall). Zusätzliche Features für den Umgang mit NAT müssen dann nicht mehr konfiguriert werden.
• nat=no schaltet daher alle zusätzlichen Features und internen Tricks von Asterisk zum Umgang mit NAT ab, denn die externe Adresse ist für Asterisk aus der vorstehenden Konfiguration bekannt bzw. ermittelbar.
• Die Aktivierung von SIP-Domain-Support (Parameter autodomain, allowexternaldomains, domain) scheint zunächst sinnvoll zur weiteren Erhöhung der Sicherheit und um unerwünschte (d.h. nicht von den Telekom-Servern) SIP-Kontakte zu blocken. Die Domains müssen allerdings fest in sip.conf angegeben sein und allowexternaldomains muss auf yes gesetzt sein, damit ein Anruf von außen (d.h. der Telekom) durchdringen kann. Die SIP-Signalisierung der Telekom wird durch deren Server jedoch an die SIP-Adresse "rufnummer@externe_ip_adresse" gesendet, so dass diese in den zulässigen Domains enthalten sein müsste. Hat man jedoch eine dynamische IP-Adresse, so kann man diese ja nicht fest konfigurieren, so dass bei einer Zuweisung einer anderen IP-Adresse Anrufe geblockt werden. Man kann zwar über autodomain=yes die externe IP-Adresse dynamisch zu den erlaubten Domains hinzufügen, allerdings lässt man damit wieder alle SIP-Pakete an "irgendwas@externe_ip_adresse" zu, was den Sicherheitsgewinn wieder zunichte macht. Daher muss man in Kombination mit einem Telekom-VoIP-Anschluss auf SIP-Domain-Filterung durch Asterisk verzichten.

Es empfielt sich, in der sip.conf verschiedenen Kontexte für ein- und ausgehende Gespräche anzulegen, wie dies auch auf Webseiten zur Sicherheit von Asterisk empfohlen wird. Im Fall der Telekom benötigen beide Kontexte unterschiedliche (und überraschend wenige) Konfigurationsparameter (zur Bedeutung von bbb,ccc,ddd siehe oben):

[telekom_in]
type=peer
context=telekom_incoming
insecure=invite
host=tel.t-online.de
fromdomain=tel.t-online.de
canreinvite=no

[telekom_out]
type=peer
defaultuser=ccc-ddd@tel.t-online.de
secret=bbb
host=tel.t-online.de
fromdomain=tel.t-online.de
canreinvite=no

Eingehende Anrufe der Telekom landen nun im Kontext [telekom_incoming], den natürlich in der extensions.conf definiert sein muss. insecure=invite bedeutet, dass wir die Telekom bei einem eingehenden Anruf (INVITE) zu keiner weiteren Authentifizierung zwingen (was sie vermutlich nicht mitmachen würde). canreinvite=no ist notwendig, um eine nachträgliche änderung der Verbindungsparameter per REINVITE durch Asterisk zu verhindern, was die Telekom-Server nicht mitmachen würden. Hier ist auch ersichtlich, dass eine Authentifizierung gegenüber der Telekom nur bei ausgehenden Anrufen erforderlich ist, nicht aber bei eingehenden, was die obigen Ausführungen bzgl. Sicherheit nochmals unterstreicht.

Als letzten Schritt bleibt nun nur noch, die extensions.conf entsprechend zu konfigurieren. Dort muss der (leere) Default-Kontext sowie der hier definierte Kontext [telekom_incoming] angelegt werden, aus dem dann an die internen Telefone weitervermittelt werden kann. Für das hier definierte SIP-Gerät [telekom_out] muss bzw. darf kein Kontext angelegt werden. Dieses SIP-Gerät dient nur zum Raustelefonieren über den Telekom-Anschluss, d.h. kann aus anderen Kontexten über die Dial()-Funktion angesprochen werden. Sinnvoll ist zudem, aus dem Kontext [telekom_incoming] keine Verbindung (d.h. Dial()) zum SIP-Gerät [telekom_out] zuzulassen, damit ein Anrufer auf keinen Fall über unseren Anschluss wieder raustelefonieren kann. Für die Konfiguration der extensions.conf sind auch für Telekom-VoIP-Anschlüsse zahlreiche Beispiele im Netz zu finden, so dass hier auf entsprechende Ausführungen verzichtet wird.