SBC mit NAT

Nicht immer werden Sie ihren Session Border Controller direkt mit einem Bein ans Internet hängen. Es ist eher üblich, dass Sie auch die öffentliche Seite in ein eigenes Subnetz hängen und über eine Firewall eine 1:1 NAT-Regel konfigurieren. Hier beschreibe ich für einen Audiocodes die erforderlichen Einstellungen.

Worum geht es

Ein Session Border Controller ist meine präferierte Lösung, um zwei Netzwerke hinsichtlich VoIP zu koppeln die ansonsten per Routing nicht miteinander kommunizieren könnten. Der SBC steht daher z.B. zwischen einem privaten Netzwerk mit Clients und Servern und einem Transfer-Netzwerk oder gar dem Internet auf der anderen Seite. Nun gibt es Firmen, in denen es immer kritisch ist, Gerät direkt mit einer öffentlichen IP-Adresse ans Internet zu klemmen. Dort muss alles durch eine Firewall und wenn Sie dann in dem internen Netzwerk keine öffentlichen IP-Adressen nutzen, dann setzt die Firewall die Adressen in den Paketen eben per NAT um.

Das funktioniert für TCP-Verbindungen schon sehr gut und ist ausgereift. Für SIP geht das ebenfalls. Der SBC sendet seine SIP-Pakete per TCP einfach zur Gegenstelle und die Firewall setzt ausgehend die Quell-IP um. Für eingehende Verbindungen muss auf der Firewall natürlich eine Port-Veröffentlichung stattfinden, d.h. eingehende Verbindungen von einer externen Gegenstelle werden auf eine öffentliche IP-Adresse der Firewall geroutet, die dann die Zieladresse umschreibt und das Paket nach intern weiter gibt.

Das ist aber nur eine Lösung für die Signalisierung. Die Aushandlung der Endpunkte für Audio/Video erfolgt aber als Teil der Nutzlast von SIP. Wenn hier SIP/TLS eingesetzt wird, kann sieht die Firewall das sowieso nicht und selbst ohne Verschlüsselung müsste die Firewall dann schon SIP verstehen und umschreiben. Aber genau dafür haben Sie ja einen Session Border Controller im Einsatz.

NAT mit Audiocodes

Der SBC weiß aber von Hause aus erst mal nicht, mit welcher öffentlichen IP-Adresse er erreichbar ist und auch nicht, welche Port-Range für RTP vorgesehen ist. Das ist entsprechend zu definieren. Zuerst gehe ich also in die Konfiguration hinsichtlich der verwendeten RTP-Ports:

Hier habe ich einfach mal unter den Media Realms vorgegeben, dass es ein Realm mit dem Namen "MR_DMZ-Extern" gibt, welches die Portrange 9000-9999 verwenden soll.

Im nächsten Schritt gehe ich dann auf die "NAT Translation" im Beriech "IP Netzwork" - "Core Entities". Hier stelle ich nun ein, dass der SBC für ausgehende Pakete bei Nutzung der entsprechenden Ports die reale IP-Adresse des Interface durch die vorgegeben "NAT-IP-Adresse" ersetzt

Ich gehe hier nun nicht auf die Konzepte ein, wann man mehrere IP-Interfaces etc. einrichtet. Ein SBC kann ja über eine IP-Adresse durchaus mehrere SIP-Verbindungen aufrecht erhalten und unterschiedliche Einstellungen erfordern.

Achten Sie genau auf die PortRange. Der Gegenseite wird jeweils ein Port als RTP-Kandidat angeboten. Sie müssen also alle angebotenen Ports in der NAT-Regel aufnehmen und auch in der Firewall mit einer 1:1 Veröffentlichungsregel bereitstellen. Es ist sehr nervig hier Tippfehler zu analysieren, wenn Anrufe eben nur "manchmal" nicht funktionieren.

Vorher/Nachher

Wenn Sie die SIP-Kommunikation des Audiocodes Mediant per SYSLOG protokollieren lassen, dann sehen Sie recht gut die Auswirkungen der Änderungen im SDP:

Vorher Nachher

Der Mediant nutzt seine "Real-IP" des Interface. hier eben eine interne Adresse. Damit kann natürlich Microsoft Teams nichts anfangen, da es diese Adresse nicht ansprechen kann.

Hier wird nun die öffentliche IP-Adresse als Kandidat eingesetzt. Für die Firewall selbst sind diese Änderungen eigentlich unsichtbar, wenn die Kommunikation per TLS abgesichert ist.

Die Herausforderung ist natürlich keine Besonderheit eines SIP-Trunks zu Microsoft Teams, sondern gilt jeden SIP-Trunk, der sich auf die Kandidaten des SPP verlässt.

NAT mit Sonus/NET/Ribbon

Jens Collasch hat mir dankenswerterweise ein Screen-Capture mit den Einstellungen auf einem Sonus-SBC gesendet.

Auch hier können Sie unter der "Signaling Group" bei den "SIP IP Details" erst einmal die "private IP-Adresse" für diese Verbindung auswählen. Über die Option "Static NAT outbound" können Sie dann eine andere "öffentliche" Adresse vorgeben, die anstelle der privaten Adresse im SDP-Record verwendet wird.

Andere SBCs und Gateway

Diese Funktion ist keine Besonderheit von Audiocodes sondern jeder SBC muss diese Funktion unterstützen, wenn es hinter einer NAT-Firewall betrieben werden soll. Leider habe ich auf die Schnelle noch keine direkten Links zu anderen Gateways oder Anleitungen gefunden.

Ich werde die Links ergänzen, sobald ich passende Blog-Einträge gefunden oder andere Gateways entsprechend konfiguriert habe.

Sonderfall Dynamische IP / Symmetrisches RTP / Telekom SIP-Trunk

Wenn nun aber ein großer TK-Dienstleister wie die Telekom immer mehr Kunden auf SIP umstellt, dann müsste ja jeder Kunde eine statische IP-Adresse haben, die sich auch nie ändert dürfte. Ansonsten muss der Kunde ja die Konfiguration seines SBCs entsprechend anpassen. Für den Einsatz mit dynamischen IP-Adressen gibt es aber Lösungen:

  • SBC als PPPoE-Endpunkt
    Wer die Internet-Leitung per DSL mit dynamischen IP-Adressen nur für Telefonie nutzt, der kann z.B. seine Fritz!Box zum DSL-Router degradieren und die Zugangsdaten zum Internet im SBC hinterlegen. Der SBC wählt sich dann über die PPPoE-Verbindung ins Internet ein und erhält direkt die öffentliche IP-Adresse. Diese kann er dann einfach nutzen.
  • DSL-Router mit statischen Weiterleitungen
    Die zweite Lösung nutzt die Funktion "Symmetrisches RTP". Normalerweise ist die SIP-Kommunikation und der RTP-Handshake voneinander getrennt. Die Endpunkte müssen nicht die gleichen sein aber in den meisten Fällen sind sie es dann doch, d.h. die IP-Adresse, mit der ein SIP-Pakete ankommt, ist zugleich auch der Media-Endpunkt.
    Diesen Trick macht sich z.B.: die Telekom zu nutzen und prüft, ob die SDP-Kandidaten aus dem Bereich der privaten IP-Adressen sind. Wenn dies der Fall ist und eine RTP-Verbindung so ja nie zustande kommen könnte, dann nutzt die Telekom die IP-Adresse, von der das SIP-Paket gekommen ist.

Mit diesem Hintergrundwissen können Sie einen SIP-Trunk auch einfach direkt hinter einer Fritz!Box oder einem anderen anderen NAT-Zugang betreiben. Sie müssen allerdings darauf achten, dass die Port-Range, die ihre SBC der Gegenseite anbietet, durch eine NAT-Veröffentlichung 1:1 auf das interne System umgesetzt wird.

Hier habe ich analog zu der obigen Konfiguration von Audiocodes auch den Bereich 9000-9999 genommen. Hier noch zwei Zitate anderer Hersteller.

Elmeg: Grundlegende Informationen zu STUN und NAT bei SIP-Anschlüssen der Deutschen Telekom (DeutschlandLAN)
Erfolgt die SIP-Kommunikation der IP-fähigen TK-Anlage mit privaten IP-Adressen (nach RFC1918) schaltet die Plattform der DTAG in den sog. „symmetrischen RTP-Modus“, d. h. die IP-Kommunikation wird nicht auf Basis der SIP-Daten etabliert, sondern auf Basis der IP-Header.
http://faq.bintec-elmeg.com/index.php?title=Grundlegende_Informationen_zu_STUN_und_NAT_bei_SIP-Anschl%C3%BCssen_der_Deutschen_Telekom_(DeutschlandLAN)

Lancom 2.33.2.14 Symmetrisch-RTP
https://www.lancom-systems.de/docs/LCOS-Menu/9.20-Rel/DE/topics/2_33_2_14.html
Dieser Parameter schaltet die strenge Prüfung des RTP-Absenders ab. In der Regel findet eine bidirektionale RTP-Kommunikationen zwischen zwei Socket-Adressen (IP:Port) statt; d.h. die Media-Datenquellen (ausgehend) sind gleichzeitig auch Media-Datensenken (eingehend). Der Datenfluss ist symmetrisch. Es gibt allerdings auch Media-Server, deren Implementierungen hiervon abweichen und die RTP-Quelle und das RTP-Ziel nicht die gleiche Socket-Adresse aufweisen. Deaktivieren Sie in solchen Fällen die Option "Symmetrisch-RTP".

Weitere Links