pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss

JeGr

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Habt ihr im Zuge der Umstellung auf SIP-Trunk überhaupt nichts in der pfSense geändert?
Also auch keine UDP Timeout-Limits, etc.? Ich setzte dabei natürlich voraus, dass die Firewall Rule jeglichen Datenverkehr zum WAN zulässt.

Also um den Punkt mal kurz aufzugreifen: Wir mussten bislang an so gut wie keiner Kundeninstallation bezüglich VoIP irgendwelche UDP Timeouts erhöhen, wenn alle Ports und Kommunikationsbeziehungen ordentlich definiert und freigegeben waren. Denn dann fordert entweder die Anlage selbst einen Keepalive an bzw. sendet einen, oder bekommt vom SIP Trunk/Anbieter entsprechend ihr Signalling von extern rein. Aber UDP State Timeouts o.ä. mussten wir noch nirgends verlängern, egal ob mit multiplen SIP Clients oder mit SIP Anlage gearbeitet wurde.

ramup

@jegr said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Wir mussten bislang an so gut wie keiner Kundeninstallation bezüglich VoIP irgendwelche UDP Timeouts erhöhen, wenn alle Ports und Kommunikationsbeziehungen ordentlich definiert und freigegeben waren.

@JeGr Danke für die Stellungnahme. Hast du dabei konkrete Erfahrungen zu den von dir genannten "Definitionen und Freigaben" der Ports und Kommunikationsbeziehungen beim Telekom SIP-Trunk, da es mir gerade darum geht dies vorzubereiten?

slu

wie eingangs geschrieben ist das eine "Unify OpenScape Business X5W".

Hab ich übersehen, sorry.

Nach einer Google Suche gehe ich davon aus, dass ihr eine Asterisk Anlage habt.

Was google alles weiß, ja eine STARFACE PBX.

Habt ihr im Zuge der Umstellung auf SIP-Trunk überhaupt nichts in der pfSense geändert?

Nein, ich hab auf der STARFACE nur das qualify=yes aktiviert, läuft wie eine eins.

An einem Standort haben wir noch den Telekom SIP Trunk, am großen Standort sind wir von der Telekom weg bzw. haben direkt von ISDN auf einen anderen SIP Anbieter gewechselt.

JeGr

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Definitionen und Freigaben" der Ports und Kommunikationsbeziehungen beim Telekom SIP-Trunk, da es mir gerade darum geht dies vorzubereiten?

Dazu gibt es im Normalfall auch bei der Telekom irgendwo Dokumentation, welche Ports und IPs hier zur Kommunikation freigegeben bzw. -geschaltet werden müssen. 5060/udp als SIP Port wird definitiv dabei sein und ansonsten sind noch einige RTP/RTSP Port-Ranges mit dabei, was aber wie gesagt stark vom Anbieter und Anlage abhängig ist. Da wir selbst Telekom nicht nutzen, kann ich dazu leider keine Doku verlinken, die solltest du aber auf Nachfrage sicher irgendwo bei der Telekom finden oder bekommen.

Grüße

ramup

@JeGr : Ok, dank dir. Da haben wir wohl etwas aneinander vorbeigesprochen. Dir geht es um die "Firewall Rules" für das betroffene, lokale Interface an dem die TA hängt, damit diese entsprechenden (ausreichenden) Zugriff auf das WAN hat.
Mir geht es mehr um die Frage ob im Sinne des NAT aufgrund der Systematik des SIP-Trunk etwas beachtet werden muss, bei der Interaktion zwischen Interface und WAN.
Die TA hat bei uns vollen Internetzugriff (alle Ports und alle Protokolle) unter Ausschluss des Zugriffs auf andere lokale Netzwerke. Die TA hängt mittlerweile als einzelne IP in einem eigenen Subnetz an einem eigenen physischen Port der pfSense.

Deiner Aussage entnehme ich inzident jedoch, dass bei euch am NAT nichts geändert werden musste. Mal sehen wie es bei der Telekom ist. Laut @slu scheinbar ebenfalls ohne "besonderes" NAT und vielleicht kann @tpf ja auch nach der Umstellung noch etwas beitragen.

@slu Mich würde noch interessieren ob du noch etwas bezüglich QoS / Traffic Shaping an den Anschlüssen gemacht hast um VoIP zu priorisieren? Nach dem Telekomdokument liest sich das so, dass die Telekom "für die Leitung" automatisch eine Priorisierung des VoIP Verkehrs vornimmt und demnach in der pfSense kein Traffic Shaping erforderlich wäre?

JeGr

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

@JeGr : Ok, dank dir. Da haben wir wohl etwas aneinander vorbeigesprochen. Dir geht es um die "Firewall Rules" für das betroffene, lokale Interface an dem die TA hängt, damit diese entsprechenden (ausreichenden) Zugriff auf das WAN hat.

Nein mir geht es um EIN- wie ausgehende Verbindungen. Man muss SIP auch zur Anlage reinlassen, sonst hat man wieder ganz andere Probleme.

Mir geht es mehr um die Frage ob im Sinne des NAT aufgrund der Systematik des SIP-Trunk etwas beachtet werden muss, bei der Interaktion zwischen Interface und WAN.

Ja wurde auch mehrfach gesagt. 5060/udp muss rein wie raus können und dazu nicht randomisiert werden, also abgehend 5060 muss 5060 bleiben, daher "static port".

Die TA hängt mittlerweile als einzelne IP in einem eigenen Subnetz an einem eigenen physischen Port der pfSense.

Dann muss die abgehende NAT Regel für die Anlage entsprechend angepasst sein.

tpf

Ich habe das mit den UDP-Timeouts auf 35 Sekunden gesetzt, da z.B. die AGFEO ES516 zu selten einen KeepAlive gesendet hat. Bei einer Fritte geht das ja alle 30 Sek.

Ansonsten betone ich noch einmal: ausgehend frei, eingehend nichts geändert. Einzig static port für die TK-Anlage definiert und gut. Funzt, bis auf die AGFEO, und die hatte wohl Firmwareprobleme, überall einwandfrei. Ich werde selbige Konfig auch für den Trunk verwenden.

ramup

@tpf
Meiner vorläufigen Einschätzung nach wird das mit dem Static Port bei SIP-Trunk nicht funktionieren bzw. wird zumindest nicht empfohlen.
Bei SIP-Trunk gibt es den "registered mode" und den "static mode", wobei ersterer seitens der Telekom gewählt werden sollte. Hierzu verweise ich auf Ziffer 2 Zeile 11, Ziffer 4.5 und insbesondere Ziffer 11.3 der technischen Unterlage der Telekom zum SIP-Trunk: PDF
Ein "listening Port" für SIP ist nur im "static mode" erforderlich.

Die Aussage von @slu scheint das ja zu bestätigen. Ich lasse mich aber gerne eines besseren belehren und würde es begrüßen, wenn du nach der Umstellung ein kurzes Feedback geben könntest. Ich weiß insoweit nicht ob pfSense hier eine "Besonderheit" macht mit den "randomized ports" beim NAT.

@JeGr Ich kenne die Vorgehensweise bei den von dir konfigurierten Anbietern nicht, aber bei der Telekom muss man keine Öffnung von außen (WAN) vornehmen. So wie ich es verstehe nutzt die Telekom eine ausgehende Verbindung (state) von der Anlage kommend quasi als Rückverbindung für die Erreichbarkeit der Anlage und das ist ja grundsätzlich automatisch der Fall (Stateful Packet Inspection), da sonst schon keine ausgehende Verbindung möglich wäre. Daher ist auch das NAT keep-alive erforderlich bzw. erhöhte UPD Timeouts (je nach Dauer des keep-alive der Anlage, wenn dies "zu lange" ist).
Vorausgesetzt ist aber sicherlich, dass die TK-Anlage (bzw pfSense) die ausgehende Verbindung zur Telekom auf den notwendigen Ports, etc. vornehmen kann, also entsprechende Verbindungen auf dem Interface gestattet sind (Zugriff vom Interface der Telefonanlage eingehend bei pfSense auf das WAN).

tpf

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

@tpf
Meiner vorläufigen Einschätzung nach wird das mit dem Static Port bei SIP-Trunk nicht funktionieren bzw. wird zumindest nicht empfohlen.
Bei SIP-Trunk gibt es den "registered mode" und den "static mode", wobei ersterer seitens der Telekom gewählt werden sollte. Hierzu verweise ich auf Ziffer 2 Zeile 11, Ziffer 4.5 und insbesondere Ziffer 11.3 der technischen Unterlage der Telekom zum SIP-Trunk: PDF
Ein "listening Port" für SIP ist nur im "static mode" erforderlich.

Die Aussage von @slu scheint das ja zu bestätigen. Ich lasse mich aber gerne eines besseren belehren und würde es begrüßen, wenn du nach der Umstellung ein kurzes Feedback geben könntest. Ich weiß insoweit nicht ob pfSense hier eine "Besonderheit" macht mit den "randomized ports" beim NAT.

Ich lese das PDF so: es ist keine eingehende NAT-/Firewallkonfig vorzunehmen, um Verkehr auf bestimmte Ports zu beschränken, sondern diese durch Verbindungsaufbau intern -> extern zu bestimmen.

Das ist Konsens und wird heute bei allen Anschlüssen von mir so gemacht. Die von mir genannte "static port"-Option im Outbound-NAT sorgt aber dafür, dass die verwendeten Ports nach innen und außen dieselben sind und nicht überschrieben werden.

Liege ich da falsch?

Übrigens mach die Telekom hier echt TCP5060 btw. 5061 und kein UDP mehr.

slu

@slu Mich würde noch interessieren ob du noch etwas bezüglich QoS / Traffic Shaping an den Anschlüssen gemacht hast um VoIP zu priorisieren? Nach dem Telekomdokument liest sich das so, dass die Telekom "für die Leitung" automatisch eine Priorisierung des VoIP Verkehrs vornimmt und demnach in der pfSense kein Traffic Shaping erforderlich wäre?

Ja wir haben den Traffic Shaper in der pfSense aktiviert und geben der PBX damit immer die notwendige Bandbreite. Abgehakt oder Unterbrechungen gibt es damit bei uns nicht.
Auch wenn die Telekom das in deren Netz priorisiert muss man dafür sorgen das die pfSense die richtigen (RTP) Pakete als erstes los wird...

Nochmal zusammen gefasst:

wir haben eingehend kein Portforwarding
LAN -> WAN darf die PBX natürlich
auf allen SIP Leitungen qualify=yes gesetzt
Traffic Shaper auf pfSense aktivieren

Das haben wir mit vielen SIP Anbieter erfolgreich in Betrieb.

Ausnahme Telekom Data/Voice, da ist tatsächlich ein Static Portmapping (5060) ausgehend notwendig.

slu

@tpf said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Liege ich da falsch?

Ich mache das nicht mehr, IMHO war das nur für den Data/Voice notwendig.

Übrigens mach die Telekom hier echt TCP5060 btw. 5061 und kein UDP mehr.

Genau, das ist TCP 5061 / transport tls und SRTP beim Telekom SIP Trunk.

tpf

@slu said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Ich mache das nicht mehr, IMHO war das nur für den Data/Voice notwendig.

Reden wir von der Option im Outbound-NAT? Bei mir führt das Fehlen der Option zu Monologen beim Telefonieren. Entweder höre ich den Anrufer nicht oder er mich nicht.

Ebenso führt das Fehlen der hochgesetzten UDP-Timeouts nach etwa 30 Minuten zum Verlust des Tons im Gespräch.

slu

@tpf said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Reden wir von der Option im Outbound-NAT? Bei mir führt das Fehlen der Option zu Monologen beim Telefonieren. Entweder höre ich den Anrufer nicht oder er mich nicht.

Ja genau Outbound NAT.

Ebenso führt das Fehlen der hochgesetzten UDP-Timeouts nach etwa 30 Minuten zum Verlust des Tons im Gespräch.

Das ist aber dann kein SIP Trunk sondern der Data/Voice? Da kann ich nicht mitsprechen, das Produkt war für uns einfach ungeeignet.

tpf

Deutschland LAN-IP oder so nennt sich das. Der Wald und Wiesen-Anschluss auf VOIP halt, den jeder normalsterbliche Kunde bei der Telekom, Vodafone oder sonstigen Anbietern bekommt.

slu

Ja genau so heißt der, von dem lasse ich die Finger weg.

ramup

@slu
Danke! Zumal das mit dem "static port" ja auch das Risiko von IP-Spoofing erhöht. Die pfSense macht als Standard "randomized ports" ja nicht ohne Grund. Inwieweit das bei jedem ein Risiko ist lasse ich mal dahingestellt.

Übrigens der Anschluss über den ihr euch streitet heißt "DeutschlandLAN IP Voice/Data". Ist etwas anderes als SIP-Trunk (Anlagen im Haus) oder Cloud PBX (virtuelle Anlage in der Cloud)

Also Zusammengefasst heißt das für SIP-Trunk mit Telekom:

Das Netzwerk in dem die Anlage liegt muss ausreichend Internet-Zugriff haben. Sofern der Internet-Zugriff eingeschränkt ist, muss darauf geachtet werden, dass zumindest die Ports aus dem technischen Dokument der Telekom zu SIP-Trunk möglich sind:
UDP (out): Ports 53, 123, 30000-31000, 40000-41000, 3478, 3479 UDP(in):Ports5070,5080,30000-31000,40000-41000 TCP(out):Port53,80,443,5060,5061
in/out ist immer aus Sicht der TK-Anlage gemeint Plattformseitiger RTP Portrange ist 9000-18000.
Outbound NAT erfordert keine gesonderte Konfiguration, insbesondere keine statischen Portzuweisungen. Die "normale" Automatic Rule von pfSense mit randomized ports genügt.
NAT Keep-Alive in der Anlage muss aktiv sein und darf kein zu langes Intervall haben. Ist dies nicht der Fall wären die UDP und TCP (!) Timeouts in der pfSense zu erhöhen, wenn die Firewall im "Normal Mode" betrieben wird, damit die Verbindung / NAT nicht gekappt wird über das die Anlage bei der Telekom registriert ist.
(SIP=TCP und Sprache=UPD (SRTP))
Bei Asterisk Anlagen muss hierfür die Option qualify=yes gesetzt sein.
(Anmerkung: Die Standard TCP timeouts sollten aber auf jeden Fall ausreichen, da diese höher sind als bei UPD)
Traffic Shaping in der pfSense sollte eingerichtet werden um QoS von VoIP zu gewährleisten.

JeGr

@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

Danke! Zumal das mit dem "static port" ja auch das Risiko von IP-Spoofing erhöht. Die pfSense macht als Standard "randomized ports" ja nicht ohne Grund. Inwieweit das bei jedem ein Risiko ist lasse ich mal dahingestellt.

What? Was hat das mit IP Spoofing zu tun? Da geht/ging es ursprünglich bei der PF Entwicklung mal um theoretische Use Cases bei NAT über MITM o.ä. dann Verbindungen/Ports zu hijacken, aber was hat der konstante Port mit IP Spoofing zu tun... vor allem abgehend! Es geht nur darum, dass abgehend die Anlage mit 5060 abgehend auch über die NAT rüber weiterhin 5060 als Port behält weil SIP extram zickig ist und auf den Source Port besteht. Um nix anderes geht es doch dabei. Dass andere Protokolle wie HTTP auf den Quellport pfeifen weil sie den nicht brauchen - alles OK, dann kann der auch randomisiert werden. Aber das sind heut Sachen, wo kaum mehr ne Geige spielen. BTW das gleiche mit anderen Source-Port empfindlichen Protokollen. IPSEC, NAT-T und Co. - warum gibts wohl im Default Outbound NAT den Eintrag für 500/udp ;)

Ansonsten haben wir bei unserem SIP Trunk auch ursprünglich kein Problem gehabt, nur alles nach draußen durchzulassen, erst bei der ein oder anderen erweiterten Funktion oder Fehlermeldung kam dann Stück für Stück raus, dass die PBX/Asterisk ganz schön den Trunk angebunden hat, der Dienstleister aber beim Signalling schon gern von extern SIP reden würde um diverse Zusatzdienste oder Funktionen zu signalisieren. Tech Docs angefordert und siehe da: Anbieter empfiehlt extern 5060 für SIP und 10000-20000 für RTSP aufzumachen (von spezifizierten IPs aus). Regeln angelegt, keine komischen Phänomene mehr. Mag bei Telekom eben anders sein, besser ist es man hats mal gehört und im Hinterkopf wenn man plötzlich mit Sachen kämpft wie unerklärlichem Besetztzeichen oder "User nicht erreichbar" oder auch Probleme beim Durchstellen, Handover etc. Und ja, bei uns wars auch 5060udp sowie tcp. Regel ist auch schön abgesichert, weil nur die Trunk-IPs des Dienstleisters als Source incoming freigegeben sind auf die PBX. Sauberes Setup :)

Grüße

ramup

@jegr said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:

What? Was hat das mit IP Spoofing zu tun?

Naja, pfSense spricht in der eigenen Dokumentation von möglichen Risiken mit IP Spoofing bei static ports im outbound NAT pfSense Doku

Es gibt viele Varianten SIP zu realisieren Dokumentation OpenScape
Die Telekom macht das bei SIP-Trunk eben über symmetrisches RTP.
Die Telekom gibt beim SIP Trunk gerade keine IPs der Telekom bekannt und rät auch ausdrücklich dazu an nur ausgehende Verbindungen zuzulassen und keine eingehenden:

"Aufgrund hochskalierbarer Cluster von SP-SSEs der Deutschen Telekom ist es nicht geeignet, die Quell-IPs der Deutschen Telekom einzuschränken. Es ist vorzuziehen, stattdessen Client-initiierte Verbindungen zu verwenden und jeglichen eingehenden Datenverkehr außer dieser Verbindung zu blockieren."

Daher hatte ich ja auch die Beschreibung des Themas auf das SIP-Trunk der Telekom beschränkt. Mir ist klar, dass das keine generelle Anleitung für alle SIP-Trunk Anschlüsse ist.

JeGr

Aye, aber du musst die Sätze im Zusammenhang lesen:

Many operating systems do a poor job of source port randomization, if they do it at all. This makes IP spoofing easier, and makes it possible to fingerprint hosts behind the firewall from their outbound traffic.

Weil viele Systeme (die meisten Windows früher) mies dabei sind, sowas wie zufällige Sequenznummern oder Quellports zu randomisieren, gäbe es den Ansatz eines IP Spoofings - was noch nichts per se mit Firewall+NAT zu tun hat - und macht es einfach(er) Fingerprinting zu nutzen. Früher war das durchaus ein Thema, dass man durchaus verstecken wollte, wieviel Rechner intern so rumstehen, damit der Provider da nichts mitbekommt. Wüsste allerdings nicht, dass das heute noch ein großes Thema ist zumal die Doku in 2002 begonnen hat und der Absatz m.W. relativ alt ist. Heißt nicht, dass er nicht mehr gilt, aber die Relevanz ist vielleicht nicht mehr so zeitgemäß gegeben ;)

Ansonsten gibt es natürlich sehr viel Möglichkeiten SIP zu sprechen (darum mag ich es auch nicht). Etwas genauso chaotisch und stürmisch wie IPSec... nicht schön aber leider auch nicht selten. Ich hatte es deshalb auch nur als Zusatz erwähnt für den Fall dass es Probleme geben sollte. Lieber wissen im Hinterkopf haben als rätseln ;)

ramup

@JeGr Ich habe zu wenig kriminelle Energie um einschätzen zu können wie groß das Risiko mit IP Spoofing für (die Übernahme) den outbound traffic (heutzutage noch) ist, daher habe ich das ja auch offen gelassen ;D

Ich habe ja auch eine WAN Regel für jegliche IPs auf Port 500/4500 für IPSec die zudem noch automatisch von pfSense als NAT mit einem static port verknüpft ist. Einziger Unterschied ist halt hier, dass Zieladresse die pfSense ist und man hofft, dass hier halt keine Lücken sind und Snort die schlimmsten Übeltäter ohnehin aussperrt ;D

Zumal meinem Verständnis nach ja bei der Telekom auch ein Transport für SIP und RTP über TLS stattfindet, der mit der Telefonanlage ausgehandelt wird (kein transparenter Proxy in pfSense oder dergleichen). Da ich zudem vorsorglich ein eigenes Subnetz mit einer einzigen IP (der Anlage) geschaffen habe, wäre das wie gesagt auch nicht meine größte Sorge ;D

Ich hätte mehr Sorge das WAN auch für die TA zu öffnen, auch bei bekannten IPs, da hier das Risiko für IP Spoofing sicherlich höher wäre und letztlich fraglich wäre wie sicher die Firmware der Anlage ist, die ja nur in sehr langen Zeitabständen aktualisiert wird. Inwieweit dies jedoch realistisch zu einem Angriff führen kann, vermag ich nicht einzuschätzen.