VoIP per Lan-2-Lan VPN, Verbindungsabbrüche uvm.



  • Hallo Forum,

    ich habe zum zweiten Mal in den letzten Jahren ein kniffeliges Problem durch den Einsatz einer pf bekommen. Das durchforsten der üblichen VoIP-Tipps und Beiträge hier hat leider nichts zu Tage gefördert. Ich arbeite schon 5 Jahre mit pf, muss mich hier aber Laienhaft ausdrücken, was ich als Fehler vermute:

    Die pf scheint anders als z.B. eine Fritze die Datenpakete zu "manipulieren" beim Umsetzen zwischen LAN und VPN. Ich habe zwei völlig unterschiedliche Geräte und Einsatzzwecke gehabt, die daraufhin immer Ihre internen Blocklisten aktivierten und den Verkehr verweigert haben.

    Aktuelles Szenario:

    Außenstelle [Fritzbox] <-> VPN <-> Hauptstelle [pf]

    wobei

    Außenstelle [Auerswald WS 400 DECT] <-> VPN <-> Hauptstelle [Auerswald Compact 4000 Anlage]

    ist.

    Als Firewallregel bei ipsec ist eingestellt, dass die Aussenstelle [ganzes Netz] jeden Port und jedes Ziel per UDP/TCP erreichen darf. Umgekehrt auch.

    Scrubbing ist zum Test deaktiviert.

    Konservative States sind aktiviert.

    UDP Timeouts aktuell auf 3000 erhöht.

    Aktueller Stand:

    • ein Basistelefon der Aussenstelle funktioniert einwandfrei
    • alles was am DECT hängt, kann aktuell intern und von extern erreicht werden (angeblich zuverlässig)
    • sobald ein DECT versucht nach außen anzurufen, wird im WS400 eine 30 Sekunden Sperre gegen die TK-Anlage verhängt
    • laut Support, weil der WS400 DECT Repeater ein sog. "zweites Invite" womöglich nicht über die pfSense bekommt

    Was und wo, könnte diesen WS400 dazu bewegen - jetzt nach Einbau der pfSense in der Hauptstelle - seine eigene TK-Anlage auszusperren?

    Übrigens: der Support riet mir außerdem, den SIP Listening Port am WS 400 mal von 5060 auf 5080 zu wechseln (dient dem Austausch zwischen der DECT-Basis und den Mobilteilen, nicht Richtung TK-Anlage). Daraufhin gingen ganze 3 Gespräche, bevor das alte Fehlerbild wieder auftauchte. Keine Ahnung warum, vielleicht lag es schlicht am nötigen Neustart des WS400.

    Ich bin dankbar für jeden Tipp.

    Vor Jahren hatte ich ein ähnliches Problem, allerdings kein VoIP. Da musste eine SICCT Session aufgebaut werden (Chipkartenleser). Das Hauptgerät/Verwaltungsgerät stand auf Seiten der Fritze, der Kartenleser auf Seiten der pf. Beim Pairing, welches das Hauptgerät initiiert, hat dieses scheinbar auch eine Manipulation im Datenstrom gefunden und das Pairing im letzten Schritt vereitelt, egal was man auch für Regeln und Ausnahmen gesetzt hatte. Nach Rücktausch auf eine Fritze, geht das bis heute noch einwandfrei.



  • Ich bin (vermutlich) auf der richtigen Spur. Nach try-and-error läuft es momentan stabil, durch die Umstellung im SIP-Bereich von UDP auf TCP.

    Ergänzend muss gesagt werden, dass der Fehler sich zwischenzeitlich auch auf das Strippentelefon ausgeweitet hatte.

    Stellt sich die Frage, warum ausgerechnet die SIP-UDP Variante nicht richtig läuft, wenn man eine pf mit einer Fritze koppelt. Im Homeoffice kann ich mit einer alten pf 2.3 und einer neuen 2.4er ein ipsec bauen, über den die Auerswälder per UDP sauber arbeiten.


  • LAYER 8 Moderator

    Da bin ich im Einzelfall überfragt, würde mich aber sehr wundern, wenn es direkt an der pfSense liegen würde. Wir haben mit eigener FreePBX und SIP Trunk sowie angebundenen Telefonen mit einer zweistufigen pfSense bei uns im Office kein Problem mit UDP und SIP. Allerdings ist das gerade bei SIP erfahrungsgemäß immer sehr stark abhängig von Herstellern und Software daher wirklich schwierig zu debuggen.

    BTW: wir waren auch mal auf conservative und längeren UDP timings, haben aber wieder auf normal umgeschaltet nachdem wir alle Ports etc. eingefangen und freigegeben hatten. Danach lief alles problemlos. Längere UDP Timings sehe ich sehr oft nur dann genutzt, wenn vorher schon Signalisierung o.ä. von der anderen Seite nicht klappt und die Anlage oder das Telefon dann selbst seinen Hearbeat oder Keepalive nutzen muss damit die Verbindung klappt. Daher würde ich da ggf. auf die Suche gehen und mal mit vollem Logging der Firewallregeln schauen, ob da vllt. von irgendeiner Richtung noch Pakete geblockt werden damit die Geräte dann andersrum die Verbindung aufbauen/halten müssen. Das wäre ggf. noch ein Ansatz.

    Grüße
    \jens



  • Danke schon mal für die Rückmeldung!

    Die pf als "Schuldige" hatte ich daher im Blick, weil der Tunnel vorher durch 2 Fritzen realisiert wurde. Weiterer Unterschied ist, dass im jetzigen Aufbau ein NAT dazu kommt auf Seiten der pf (die ehemalige Fritze wählt noch an, ist vom Betreiber).

    Entweder verschwinden mir UDP-Pakete irgendwo, oder bei der Verarbeitung durch die pf sahen die Auerswald Geräte ihre Verbindung gestört/manipuliert sodass Sie getrennt haben.

    Ich kann ansonsten auch nicht von schlechten Erfahrungen sprechen im Einsatz der pf. Zuhause macht eine alte Alix 2D13 mit V2.3 einwandfrei ihren Dienst. Im ipsec mit der Firma klappte auch das VoIP mit den selben Endgeräten einwandfrei, trotz Power-LAN dazwischen.

    Wie komme ich zum "vollen Logging" ? Laut Protokolle gab es keinerlei Block-Einträge wenn ich allein schon nach einer der beteiligten IP's suche, egal ob Sender oder Empfänger. Und in den States sah man zumindest die RTP's und den SIP (5060) als verbunden. Zusätzlich noch Kleinkram wie 53 DNS und 443 HTTPS meine ich.


  • Rebel Alliance

    Hallo.

    @sebden said in VoIP per Lan-2-Lan VPN, Verbindungsabbrüche uvm.:

    Wie komme ich zum "vollen Logging" ? Laut Protokolle gab es keinerlei Block-Einträge wenn ich allein schon nach einer der beteiligten IP's suche, egal ob Sender oder Empfänger. Und in den States sah man zumindest die RTP's und den SIP (5060) als verbunden. Zusätzlich noch Kleinkram wie 53 DNS und 443 HTTPS meine ich.

    Du kannst unter Diagnostics->Logs->Settings "Log packets matched from the default pass rules put in the ruleset" anklicken, ist normalerweise deaktiviert.
    Dann in deinen Rules das Logging aktivieren.
    Screenshot_2020-08-31 pfSense home - Firewall Rules Edit.png

    Das war es eigentlich.


Log in to reply