pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss
-
Ja genau so heißt der, von dem lasse ich die Finger weg.
-
@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.
-
-
@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
-
@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.
-
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 ;)
-
@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.
-
Naja Spoofing setzt immer auch irgendwo Wissen voraus. Ich denke eher weniger, dass heute jemand wegen ein bisschen VoIP Anlage den Aufriß macht, sämtliche potentiellen IPs als Quelle für SIP zu spoofen um zu schauen was passiert. Zumal: welcher Nutzen? Wenn du die IP bspw. der Telekom spoofst und dann die Anlage anfunkst, könntest du höchstens erreichen, dass die aus dem Tritt kommt weils bei ihr quasi ständig klingelt, also eher sowas wie Syn-Spoofing / DOS. Und das merkt man recht flott. Zudem man dann die gespooften Pakete erstmal bis zu dir bekommen müsste. Da die ja logischerweise erstmal durch das Telekom Netz wandern bis zu dir (an deinem Anschluß) würde das IMHO schon vorher auffallen bevor die zu dir kommen, dass da jemand versucht IPs der Telekom zu simulieren. Übernehmen kannst du soweit ich richtig weiß bislang nichts damit, außer mit Spoofing die Anlage oder Telekom zu ärgern. Nutzen somit minimal. :)
Deshalb ist eine Quellbeschränkung bei offenen Ports am WAN auch eine sinnvolle Absicherung. Sonst bräuchte man das ja (wenns eh gespooft werden könnte) nicht machen ;)
-
So, wurde heute auch unfreiwillig von der Telekom zum Wechsel genötigt. Hatte schon Panik, aber die Konfiguration auf einer Unify OpenScape Business X3 verlief geradlinig und ohne größere Probleme, mit den Standardeinstellungen des Assistenten.
Auf der Sense waren keinerlei Anpassungen nötig.
-
@bahsig OK, danke für die Rückmeldung. Wir sind am Freitag dran.
Den verschlüsselten Modus hast du noch nicht versucht?
Wenn man sich als "System" an der OpenScape anmeldet, dann kann man im Experten-Modus unter Telefonie->Sprach-Gateway->ITSP in dem Telekom SIP-Trunk registered Profil bei Transportsicherheit auf TLS umstellen und Mediensicherheit auf SDES only. Man muss nur beides gleichzeitig umschalten. -
Habs gerade mal umgestellt. Läuft.
-
Ah, danke für die Information. Schade dass Unify nicht standardmäßig die Verschlüsselung aktiviert, zumindest bei den Anbietern die das zulassen.
-
Hier nochmal ein Auszug vom Statuslog.
----- Last Diagnostic information for this User ----- User registered successfully ----- Current state ----- STUN: Disabled Registration: registered ----- Connection List: ----- [0]: peerAddr=xxxx TCP proxy=xxxx type=QsigTrunk Number of User(s)=1 [1]: peerAddr=217.0.15.69:5061 TLS proxy=reg.sip-trunk.telekom.de:0 type=Provider Number of User(s)=1 [2]: peerAddr=217.0.15.67:5061 TLS proxy=reg.sip-trunk.telekom.de:0 type=Provider Number of User(s)=1 [3]: peerAddr=217.0.26.133:5061 TLS proxy=reg.sip-trunk.telekom.de:0 type=Provider Number of User(s)=1 Local TCP-port: 38245 Remote TCP-addr: 217.0.15.69 ----- Configuration Data ----- provider name: Telekom DeutschlandLAN SIP-Trunk Registered Mode user name: +49xxxx authorization user name: xxxx domain name: sip-trunk.telekom.de transport protocol: tcp transport security: Secure media security: SDES only proxy: sip-trunk.telekom.de:0 registrar: sip-trunk.telekom.de:0 expiration time: 600 outbound proxy: reg.sip-trunk.telekom.de:0 STUN: not usedWie schon gesagt. Die Unify hängt an der Sense und nutzt diese als Gateway. Es sind keine ein- und ausgehenden Regeln notwendig.
-
Sieht gut aus. Für ein niedrigeres NAT Keep-Alive kann auch der Wert von 600 auf einen niedrigeren Wert gesetzt werden.
Aber wenn keine Probleme auftreten (das heißt pfSense die Verbindung nicht kappt) dann reicht es ja. -
Ich müsste dann mal ein längeres Telefonat führen, um zu checken, ob und wann die Verbindung gekappt wird.
-
@bahsig said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:
Ich müsste dann mal ein längeres Telefonat führen, um zu checken, ob und wann die Verbindung gekappt wird.
Ich habe, sofern Unterbrechungen aufgetreten, festgestellt, dass diese bei ziemlich genau 30 Min Gesprächsdauer auftreten. Dabei bleibt das Gespräch stehen, die Sprachkanäle sind aber zumindest einseitig weg.
-
Mit NAT-Keppalive meinte ich aber eher die Dauer in der keine Gespräche stattfinden, also keine Daten übertragen werden und daher die Verbindung zu Registrierungsserver von der Telekom von der pfSense gekappt werden.
Der SIP-Trunk hält ja eine Verbindung stetig offen, über den dann die Sprachdaten laufen, wenn telefoniert wird.
Das Phänomen mit Verbindungsabbrüchen nach 30-minütigen Telefonaten höre ich zum ersten Mal. -
@tpf: Unterbrechungen habe ich auch nach 1,5h nicht festellen können.
@ramup: das mit NAT-Keepalive erschließt sich mir noch nicht. Ich denke aber, dass man damit und einer halbwegs guten Telefonanlage das Problem nicht hat, das die Verbindung gekappt wird. Das würde ja im Umkehrschluss bedeuten, dass ich morgens keine Telefonate führen kann, wenn in der Nacht keiner telefoniert und die Sense den Port dicht macht.
Ich muss aber dazu sagen, dass ich die VOIP Telefonie nicht über die Telekom DSL-Leitung mache, sondern über 1&1 Glasfaser.
-
Das "Problem" ist nicht die Telefonanlage sondern pfSense, die inaktive Verbindungen aus Sicherheitsgründen nach vordefinierten Intervallen trennt und dann eine Neuverbindung nötig ist.
Die Intervalle von pfSense ändern sich, also werden z.B. länger wenn die Firewall auf Conservative Mode gestellt wird.
Aber scheinbar reichen die 600s ja aus. UPD wird von pfSense schneller gekappt als TCP Verbindungen und ich verstehe es so, dass die Telekom den Stream über TCP realisiert. -
@ramup said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:
Das "Problem" ist nicht die Telefonanlage sondern pfSense, die inaktive Verbindungen aus Sicherheitsgründen nach vordefinierten Intervallen trennt und dann eine Neuverbindung nötig ist.
Woher nimmst du denn diese Info bitte? States verfallen wenn die Verbindung beendet wird oder nach einem Timeout Wert kein Traffic mehr aufgenommen wird. Da wird keine "inaktive Verbindung aus Sicherheitsgründen getrennt". Das ist so nicht richtig. Und da gehts auch nicht um Intervalle, sondern wie gesagt um Timeouts, die jede normale TCP Verbindung hat.
Die Intervalle von pfSense ändern sich, also werden z.B. länger wenn die Firewall auf Conservative Mode gestellt wird.
Nein, die Timeout Werte werden "konservativer" also höher. Ich habe hier aber zig verschiedene VoIP Installationen die alle mit "normal" mode laufen und noch nie in irgendwelche Timeouts rennen, denn Protokolle die auf Kontinuität angewiesen sind, halten eine Verbindung normalerweise auch sinnvoll aufrecht, da TCP/UDP Timeouts völlig normal sind.
UPD wird von pfSense schneller gekappt als TCP Verbindungen
Nur nochmal zum Verständnis. Es wird nichts gekappt, die Verbindung wird geschlossen bzw. der State gelöscht, wenn innerhalb der Timeout Values kein Traffic läuft. Völlig normales Vorgehen auf L3, kein Gerät auf L3 will ewig und für immer State Informationen für Millionen Quell-Ziel-Paare mit sich rumschleppen. UDP wird damit auch nicht früher gekappt oder sowas, sondern hat einfach schon weil es Stateless ist ein ganz anderes Timeout Verhalten, da der 3-Wege-Handshake wie bei TCP wegfällt, weswegen UDP deshalb auch gern für Echtzeit-nahe Anwendungen verwendet wird und sich nicht erst mit: "Hallo", "Hallo, na?" "Gut, selbst?" "Auch, dann los" rumschlagen muss bevor es anfangen kann, Daten zu übermitteln. Die Standard PF Timeouts sind BTW:
[2.4.4-RELEASE][root@pfs-stable.lab.test]/root: pfctl -s timeouts tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 58200 states adaptive.end 116400 states src.track 0sAllein an den ganzen TCP Arten sieht man schon, dass da viel mehr abläuft als bei UDP, ICMP oder anderen. Die Timeouts sind in System>Advanced u.a. anpassbar, wem die Standard 60/30/60 von UDP nicht genügen.
Grüße
-
@JeGr said in pfSense mit Telekom SIP-Trunk IP-Anlagenanschluss:
UDP deshalb auch gern für Echtzeit-nahe Anwendungen verwendet wird und sich nicht erst mit: "Hallo", "Hallo, na?" "Gut, selbst?" "Auch, dann los" rumschlagen.
Gehört zwar nicht zum Thema, aber dein "Erzählstil" treibt mir oft ein Schmunzeln ins Gesicht.
