VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen
-
Hallo,
in einem anderen Thread habe ich bereits geschrieben, dass unsere Telefonanlage auf einen Telekom SIP-Trunk umgestellt wurde.
Im Wesentlichen läuft das Ganze einwandfrei. Mir ist nunmehr jedoch aufgefallen, dass bei ausgehenden Gesprächen nach relativ exakt 15 Minuten (900s) der Gesprächspartner zwar mich noch hört, ich jedoch nicht mehr diesen.
Bei eingehenden Gesprächen fehlt mir gerade die Erfahrung.Ich vermute hier die TpfSense als Verursacher, da in der Telefonanlage nirgends ein entsprechendes Intervall hinterlegt ist.
Probleme seitens Telekom kann ich allerdings nicht ausschließen.Was mich verwundert ist, dass bei einem Gespräch nur eine UDP Verbindung hergestellt wird laut den States:
Bsp.
UNIFYOPENSCAPE udp 10.21.33.2:30526 -> 217.0.132.119:21754 MULTIPLE:MULTIPLE 22.725 K / 22.202 K 4.55 MiB / 4.45 MiB
Da verwundert mich, dass einseitig ein "Verbindungsabbruch" stattfindet.
Hat noch jemand ein ähnliches Problem und bestenfalls eine Lösung dafür?
Die pfSense läuft im "Normal Mode" mit folgenden Verbindungsdaten ("pfctl -st"):
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 600000 states
adaptive.end 1200000 states
src.track 0s -
@ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
Ich vermute hier die TpfSense als Verursacher, da in der Telefonanlage nirgends ein entsprechendes Intervall hinterlegt ist.
Moooment. Bei der Fehlerbeschreibung vermute ich eher was anderes.
a) Der SIP Trunk ist nicht ordentlich dazu in der Lage eingehend mit der TK Anlage zu "reden", da fehlt also eine Freigabe/Weiterleitung, damit der Traffic ordentlich auf der Anlage ankommt
b) und/oder die TK Anlage hat zwar einen Timeout (bzw. wenn per TCP kommuniziert wird schlägt ggf. der TCP Timeout zu), aber macht keinen ordentlichen Keepalive der Verbindung wenn von außen nix ankommt. In vielen Trunk/Anlagen Konfigurationen ist das aber der Fall, dass - bei Problemen bei ankommenden Verbindungen - nach einer gewissen Zeit die Anlage von sich aus die Verbindung aufbaut/wiederbelebt. Wenn der Keepalive zusätzlich fehlt, wird natürlich irgendwann ein Timeout das Ganze in die Tonne kloppen.Die pfSense kann an der Stelle erstmal nur zweitrangig/gar nix dafür, denn sonst würde die Verbindung gar nicht klappen. Aber der Filter sitzt sicher nicht auf der Verbindung und sagt aus Spaß nach 15min "nope, genug gequatscht, aus die Maus. Tschö mit Ö"
Zudem fehlt mir in deiner Auflistung definitiv was SIP-artiges. Also 5060 oder 5061. Was du als State listest ist eher der RTP Stream von der Tonverbindung. Aber die Kommunikation SIP-Trunk Anlage sehe ich da nicht, die müsste zu sehen sein.
-
@JeGr said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
dazu in der Lage eingehend mit der TK Anlage zu "reden", da fehlt also eine Freigabe/Weiterleitung, damit der Traffic ordentlich auf der Anlage ankommt
b) und/oder die TK Anlage hat zwar einen Timeout (bzw. wenn per TCP kommuniziert wird schlägt ggf. der TCP Timeout zu), aber macht keinen ordentlichen Keepalive der Verbindung wenn von außen nix ankommt. In vielen Trunk/Anlagen Konfigurationen ist das aber der Fall, dass - bei Problemen bei ankommenden Verbindungen - nach einer gewissen Zeit die Anlage von sich aus die Verbindung aufbaut/wiederbelebt. Wenn der Keepalive zusätzlich fehlt, wird natürlich irgendwann ein Timeout das Ganze in die Tonne kloppen.@JeGr Danke für deine Einschätzung. Die TCP Verbindung über 5061 habe ich weggelassen, da ich diese nicht als Fehler angesehen habe. Dies lautet z.B.
UNIFYOPENSCAPE tcp 10.21.33.2:44735 -> 217.0.26.163:5061 ESTABLISHED:ESTABLISHED 6.736 K / 6.467 K 1.14 MiB / 1.09 MiB
Vielleicht muss ich aber tatsächlich mal darauf achten ob sich hier in der Zeit von 15 Minuten Datenpakete ergeben.
Zu sagen wäre auch, dass es nicht bei allen Gesprächen passiert, sondern nur bei einigen Gesprächpartnern. Bei diesen aber immer.
-
@ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
Zu sagen wäre auch, dass es nicht bei allen Gesprächen passiert, sondern nur bei einigen Gesprächpartnern. Bei diesen aber immer.
Oooha. OK also wenn es auch nicht immer auftritt, dann riecht das immer mehr noch nach "nicht pfSense". Wir hatten bei einem Kunden uns mal fast ein Jahr lang damit herumgeschlagen, dass ich/wir fester Ansicht waren, es ist NICHT die Firewall, vom TK Hersteller, Kunden und VoIP Dienstleister aber immer nur gehört haben "ja das ist sonst aber noch nie passiert <blabla>". Schlußendlich nach ettlichen Debugs und TCPDumps(!) die wir dann an den VoIP Anbieter geschickt hatten (mit der Antwort wir sollten doch Packet Captures für Wireshark schicken
Ja, was sind wohl TCPdumps... 
) kam dann nach knapp einem Jahr raus: es wäre ein Kompatibilitätsproblem zwischen der Anlage und dem Anbieter, die wohl dann irgendwelche Keepalives und Signallings nicht korrekt senden weil der Anbieter das anders als andere implementiert hatte. Ja VoIP ist toll und die Zukunft... seufzPrinzipiell werde ich immer mißtrauisch wenn so wie im beschriebenen Fall es 80% der Zeit einfach so geht und nur vereinzelt nicht. Trotzdem ggf. mal nachhaken, ob der tcp/5061 Zugriff nicht umgekehrt eingehend auch erlaubt sein muss oder das Ganze komplett ausgehend von deiner Seite aus funktioniert. Evtl. fehlt da dann trotzdem die eingehende Komponente so dass es eben manchmal zu Timeouts kommt.
-
@JeGr Danke. Nach etwas tiefgehender Recherche denke ich, dass ich die Lösung des Problems gefunden habe.
Die Telekom hat wohl einen Session Timer von 900s in dem ein UPDATE geschickt wird, der dann wohl scheinbar an der Anlage nicht ankommt. Also mutmaßlich ein NAT Problem.
Daher bin ich nun doch auch übergegangen eine statische Portzuweisung in den Outbound Rules zu machen. Alternativ wird angeraten in der TK-Anlage den Session Timer und ggf. den UPDATE Befehl zu deaktivieren.Mal sehen ob die ausgehenden Gespräche nunmehr die 900s überstehen. Ich würde dann das Thema zu Telekom SIP-Trunk aktualisieren.
...dem Thema VoIP stehe ich auch zwiegespalten gegenüber. ISDN war herrlich unkompliziert.
Wir haben z.B. das Problem, dass grundsätzlich FAxe funktionieren, aber bei bestimmten Empfängern kommt immer ein "Besetzt" Zeichen (und nein es ist nicht besetzt ;D ). -
@ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
...dem Thema VoIP stehe ich auch zwiegespalten gegenüber. ISDN war herrlich unkompliziert.
Let's not go there or I start the rant again... ;) VoIP macht vieles möglich, aber hat ähnliche Probleme wie IPSEC, dass jeder was anderes implementiert, sich an andere Teile des Standards hält und am Ende hat man ein einziges Chaos. Es könnte so schön sein.
-
Ich kann (leider) aufgrund eines soeben geführten Telefonates sagen, dass die statische Portzuweisung keine Besserung gebracht hat.
Ich werde nunmehr den Session Timer deaktivieren und wenn das nicht hilft noch den support für "UPDATE" abschalten.
-
@ramup Was hast du denn konkret eingestellt für die Port Zuweisung? Vielleicht war die noch nicht so ganz richtig?
-
@JeGr Eine statische Portzuweisung eben für UDP Traffic der Anlage:
Ich gehe davon aus, dass der Session-Timer über UDP gesendet wird, ansonsten müsste ich das evtl. noch etwas für TCP einstellen und testen. Leider erfährt man nirgends wie der Session Timer funktioniert und vor allem über welche Ports er läuft.
Würde ich mir andere Probleme einhandeln wenn ich UDP und TCP Verkehr mit einer statischen Portzuweisung versehe?
Also alle Ports bei UDP und TCP. Ansonsten müsste ich mal schauen, dass ich die Ports verwende, die im Telekom Dokument spezifiziert sind. Wenn ich aber auch alle setzen kann, wäre das das eifachste? -
@ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
UNIFYOPENSCAPE tcp 10.21.33.2:44735 -> 217.0.26.163:5061 ESTABLISHED:ESTABLISHED 6.736 K / 6.467 K 1.14 MiB / 1.09 MiB
Ähem...
Du sagst doch, dass das Telekom SIP TCP(!) und nicht UDP ist ;) und SIP ist wahnsinnig ekelhaft Port-affin. Ich würde daher mal statt udp/* einfach die Default Regel für IPSEC (udp/500) kopieren, hier udp in tcp+udp ändern und das ganze für 5060 und 5061 erstellen. Fertig. Den Rest musst du gar nicht erst umständlich statisch zuweisen. Die Transportstreams sind normalerweise nicht Portgebunden weil sie ausgehandelt werden. :D -
Ich habe dieses Problem mit meiner FritzBox und Telekom SIP (kein Trunk) ebenfalls: ganz oft ist nach 15 Minuten Ende und ich finde keine wirkliche Erklärung für dieses Verhalten. Im Log der Firewall ist folgendes zu sehen:
Ich habe schon mit Timeouts rumgespielt und keine Verbesserung erreicht. Ganz, ganz selten gehen auch mal mehr als 15 Minuten. Der NAT-keep-alive in der Fritte steht auf 30 Sekunden.
-
@tpf könnte aber ein anderes Problem sein. Aber der Screen sieht so aus als würdest du SIP von der Telekom blocken. 7078 ist m.W. bei denen ein RTP Port. Die mögen wohl incoming doch SIP/udp reden, nicht nur outgoing TCP/5061.
Gruß
-
Servus JeGr,
nach meinem Verständnis und allen Installationen, die ich bisher so gemacht habe, muss bei einer SPI-Firewall nicht mehr gemacht werden, als ausgehend eine Verbindung zu den SIP-Servern aufzubauen. Außer natürlich static port im outgoing NAT. Sonst hörst nix.
Klar, es gibt keine eigenen Firewallregeln für eingehenden Verkehr. Da ist einfach zu. Es funzt ja auch. Ganze 15 Minuten. Hin und wieder auch länger. Aber in 99 % der Fällen ist nach 15 Minuten die Verbindung weg.
Aus irgendwelchen Gründen kappt mir die Firewall das Gespräch und mir ist nicht klar, weshalb. Was ich via pftop so sehe, sieht alles gut aus. Sitzungen werden verlängert und keine geht auf 0.
-
@tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
nach meinem Verständnis und allen Installationen, die ich bisher so gemacht habe, muss bei einer SPI-Firewall nicht mehr gemacht werden, als ausgehend eine Verbindung zu den SIP-Servern aufzubauen. Außer natürlich static port im outgoing NAT. Sonst hörst nix.
Und ich möchte auch nichts gegen dein Verständnis oder deine Erfahrung anführen, aber wir hatten das hier schon mehrfach, dass es zwar "solala" ging, aber ließ man den Service Provider auch inbound rein, gings plötzlich richtig. Nicht immer sind leider die technisch affinen Mädels und Jungs an den Stellen, die die Infos weitergeben. Und dann halten sich ggf. hartnäckig andere Fakten. Wenn ich aber von Telekom Seite solche Streams inbound sehe, würde ich die mit deinen Problemen einfach testweise für ne Woche aufmachen. Ggf. mit deren Source Restriction, dass es nur TCom Adressen sein dürfen und nicht jedermann.
@tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
Aus irgendwelchen Gründen kappt mir die Firewall das Gespräch und mir ist nicht klar, weshalb. Was ich via pftop so sehe, sieht alles gut aus. Sitzungen werden verlängert und keine geht auf 0.
Das kann auch (siehe andere Threads) wie bei einem unserer Kunden einfach Implementationssache sein. SIP ist da leider wie IPSEC. Jeder bastelt seinen eigenen S.....cheibenkleister und wir dürfens ausbaden. Daher: testet es doch einfach und schaut, was bei rauskommt. Wenns nichts ändert ist auch nichts kaputt(er als vorher) und man kann ggf. bei deren Support weiter eskalieren.
Grüße
-
Danke. Ich denke du meinst eine solche Regel? Wäre diese richig konfiguriert?
Zur Info: 10.21.33.2/24 ist die Anlage als einzige IP in dem Subnet, mit Ausnahme von pfSense als 10.21.30.1/24.
Grundsätzlich sollte meiner Auffassung nach (abweichend vom Bild) TCP für 5060 bzw. 5061 reichen, da laut technischem Dokument von SIP-Trunk folgende Ports verwendet werden:
5.8 Benutzte Ports und ÜbertragungsProtokolle
- UDP (out): Ports 53, 123, 30000-31000, 40000-41000, 3478, 3479
- UDP (in): Ports 5070, 5080, 30000-31000, 40000-41000
- TCP (out): Port 53, 80, 443, 5060, 5061
in/out ist immer aus Sicht der TK-Anlage gemeint
Plattformseitiger RTP Portrange ist 9000-18000Ich könnte auch für alle Ports eine statische Regelzuweisung machen, sowohl UDP wie TCP.
Wie konfiguriert man in der pfsense bei einer Regel mehrere Ports? Soweit ich sehe wird ein Portrange mit "XX:XX+1" angegeben, aber z.B. "Y,XX:XX+1" für mehrere Ports einschließlich einer Portrange wird nicht akzeptiert.Soweit ich sehe hat sich das Problem derzeit wahrscheinlich durch die Deaktivierung des Session Timers in der Anlage gelöst, auch ohne statische Portzuweisungen. Zumindest ist es mir bei den letzten Gesprächen nicht mehr aufgefallen, wobei es eben auch nicht immer aufgetreten ist. Ich würde allerdings eine Löung mit Session Timer aus Sicherheitsgründen bevorzugen.
-
@JeGr
Ja, ich versuche es mal. Allerdings war ich eben an einem quasi identischen Anschluss. Ebenfalls pfS, ebenfalls Fritte 7390 als TK-Anlage, ebenfalls Telekom. Alles identisch, sogar die Hardware. Bis auf: ADSL2+ vs VDSL und auf der anderen pfS gibts kein pfBlockerNG.Gespräche beliebiger Länger kein Problem. Es ist zum Auswachsen.
-
@ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
aber z.B. "Y,XX:XX+1" für mehrere Ports einschließlich einer Portrange wird nicht akzeptiert.
Einfach ein Portalias erstellen. Den müsste man an der Stelle verwenden können.
-
@JeGr said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
Einfach ein Portalias erstellen. Den müsste man an der Stelle verwenden können.
Danke, das mit dem Port Alias funktioniert.
EIne Frage habe ich noch. Grundsätzlich werden die statischen Portzuweisungen ja im Outbound NAT gemacht, also für die Verbindung z.B. der TK-Anlage zu der Telekom im WAN.
Ist eine Regelung des Inbound NAT nicht nötig oder wo ergeben sich dort die Unterschiede? Also eine Verbindung die vom WAN kommt zu der z.B. TK-Anlage.Oder ist aufgrund der Nutzung der Telekom der TCP/UDP Verbindung, die von der TK-Anlage kommt und für Gespräche etc. genutzt werden nur das outbpund NAT nötig, da dies auch für den "Rückkanal" gilt?
-
@ramup said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
Ist eine Regelung des Inbound NAT nicht nötig oder wo ergeben sich dort die Unterschiede? Also eine Verbindung die vom WAN kommt zu der z.B. TK-Anlage.
Nein warum? Dort muss die sendende Seite ja darauf achten, dass ihre Source Port Zuweisung gleich bleibt. Das ist als Empfänger ja nicht dein Problem. Du NATtest es ggf. höchstens nach hinten ins LAN rein, aber dabei bleibt der Port im Normalfall gleich. Es geht um Source Port Scrambling, was die pfSense abgehend im NAT per default macht um Zielservern/Diensten zu erschweren zu raten, ob die Verbindungen vom gleichen Gerät stammen und um MITM Angriffe mit Portsequenzen zu unterbinden. Gerade OS mit schwachem oder keinem Port Scrambling waren da früher für anfällig, dass man wusste "Oha da kommt ein Windoof, der spricht jetzt die nächsten 20 Requests von Port 5917+1, +2, +3, etc." - damit waren diverse Angriffe denkbar. Daher wird beim Outbound NAT die Zuweisung nochmals wild randomisiert, so weiß außen niemand, ob das 1, 2 oder 10 PCs sind und tut sich daher schwerer, eine vorhandene Verbindung zu kapern/erraten.
Was ansonsten für SIP/Telekom wirklich nötig ist, weiß nur die Telekom. Ich würde bei ankommenden Anfragen beim Klingeln aber sicherheitshalber das aufmachen und reinlassen was anklopft, vor allem wenns Probleme gibt ;)
-
@tpf said in VoIP Telekom SIP-Trunk - Stimme Gesprächspartner wird nach 900 Sekunden nicht mehr übertragen:
@JeGr
Ja, ich versuche es mal. Allerdings war ich eben an einem quasi identischen Anschluss. Ebenfalls pfS, ebenfalls Fritte 7390 als TK-Anlage, ebenfalls Telekom. Alles identisch, sogar die Hardware. Bis auf: ADSL2+ vs VDSL und auf der anderen pfS gibts kein pfBlockerNG.Gespräche beliebiger Länger kein Problem. Es ist zum Auswachsen.
Falls es jemanden interessiert, ich habe die Lösung für das Gesprächsproblem gefunden. Es lag am Netzteil der Fritte. Anscheinend läuft alle 15 Minuten auf der Fritte irgendein leistungshungriger Prozess, der einen Aussetzer im Verkehr erzeugt. Dieser genügt für den Gesprächsabbruch. Seit ich das Netzteil ausgetauscht habe, läuft alles einwandfrei.
Unglaublich...
