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.
-
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.
-
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.
Das war es eigentlich.
-
Danke nochmal für alle Tipps soweit. Ich muss den Thread nochmal reaktivieren.
Diese Aufstellung lief, solange in den VoIP-Telefonen der Aussenstelle TCP statt UDP aktiviert war für die Anlagenverbindung.
Nun wollten wir die FritzBox der Außenstelle austauschen gegen eine pf. So wären an beiden Enden pfSensen. Nun geht das Problem noch gravierender von vorn los. Ich kann das Telefon zwar kurzzeitig anmelden (den Account), jedoch keinerlei Telefonat führen.
Als offene States sieht man auch lediglich den SIP 5060 Port zwischen Telefon und Anlage stehen. Wahlweise per UDP oder eben TCP. Keine Audio-Ports, wobei sporadisch mal ein Port im 49xxx Bereich als aufgebaut angezeigt wird.
Um es einfach zu machen gibt es je Firewall genau 2 Regeln hierfür. IPv4 - alle Protokolle (nicht nur TCP etc.) an LAN-Netz der Gegenstelle, jeweils in der Sektion LAN und eine ANY Regel bei ipsec. ANY Flags ist ebenso aktiviert in beiden Regeln aktiv.
Folgendes konnte ich beobachten: die Klienten der Nebenstelle haben Zugriff auf alle möglichen Dienste und Freigaben der Hauptstelle (RDP, SMB usw). Nur die Telefonie zickt.
Die Hauptstelle hat trotz gleicher Regeln nur Zugriff auf Dateifreigaben der Außenstelle. Versuche ich eine Konfigurationswebseite des Telefons oder der Firewall zu öffnen, rödelt sich der Browser tot. Das wären dann einmal eine HTTP und einmal eine HTTPS Verbindung, die scheitern.
Tausche ich das Endgerät der Außenstelle zurück auf die FritzBox und lasse sie den Tunnel bauen, geht alles wieder. Keinerlei Änderung an der pf in der Hauptstelle war dann nötig. Heißt aus unerfindlichen Grund, filtert die pfSense der Außenstelle - oder liege ich mit dieser Annahme falsch?
Ich bin für jeden Tipp dankbar.
-
Edit: Wenn die Anlage SIPS und SRTP erzwingt, funktioniert die Telefonie. Auch hier ohne weitere Änderung des Regelsatzes.
-
- Edit: Ich habe die Firewall der Außenstelle jetzt nochmal komplett neu installiert mit 2.4.5 p1, keinerlei Pakete nachinstalliert sowie keine Regeln geändert und den ipsec-Tunnel wieder eingerichtet. Die Problematik bleibt bestehen.
Ich würde ja sagen, dass die pfSense der Hauptstelle dann die Ursache sein muss, aber wie bereits oben beschrieben, arbeitet Sie mit einer FB7590 in der Außenstelle ja problemlos im Tunnel.
Auch habe ich an den Tunnel-Parametern experimentiert. Da wären zum einen der Wechsel von IKE2 zu IKE1 und auch schwächere Verschlüsselung (also quasi so schlecht wie die FB7590).
Ein ähnlicher Aufbau von meinem Homeoffice funktioniert. Unterschied -> Zuhause habe ich eine alte ALIX auf die nur pfSense 2.3.5 läuft. Gab es zwischen 2.3.5 und 2.4.5 irgendwann gravierende Änderungen betreffend ipsec oder NAT, sodass eine Gegenstelle wie wild Pakete schluckt während die andere Seite alles rein lässt?
-
@sebden
Evtl. mal ein OpenVPN Tunnel aufbauen, wäre das eine Option? -
@slu Ich teste das mal. Bisher habe ich mich völlig auf ipsec eingeschossen, da es übergreifend funktioniert mit FritzBoxen etc. pp.
Da fällt mir die Einrichtung und Entstörung auch leichter.
Habe in meiner Verzweiflung zwischenzeitlich sogar ipfire (Tunnel geht nicht aufzubauen) und OPNsense (Tunnel steht, aber gleiches Problem) getestet -.-
-
Der Open-VPN Tunnel steht, ich kann mit den NAT Regeln von Routing Internet Traffic Through A Site-To-Site OpenVPN Tunnel beide Seiten pingen, jedoch nur Unidirektional von der Außenstelle Webseiten im Netz der Hauptstelle öffnen, nicht umgekehrt. Zum Schluss das gleiche Fehlerbild wie im ipsec Tunnel.
Falls wichtig: aktuell stehen beide pfSensen unter NAT auf Hybrid, mit dem Standart-Eintrag für ipsec Phase 2 Port 4500. Auch Modus "Automatisch" brachte keine Verbesserung.
-
@sebden
das NAT ist eigentlich völlig egaln an dieser Stelle.
Vielleicht habe ich auch das Setup noch nicht verstanden.
Du möchtest von der Außenstelle über die Hauptstelle ins Internet und auf Server in der Hauptstell zugreifen? -
@slu Danke nochmals für den Tipp mit oVPN. Zuletzt läuft es jetzt, wobei ich noch nicht sagen kann, ob es auch per ipsec laufen könnte.
Die NAT-Regeln brauchte ich nach jetzigem Verständnis dafür, dass ich die IPs im gegenüberliegenden Netz direkt auflösen konnte, ansonsten lief das irgendwie nur per NAT über die oVPN-Adresse der Firewall am anderen Ende.
Letzlich lief die Kommunikation zur Außenstelle aber erst, als ich eine Erlaubt-Regel entfernt hatte aus der pf in der Hauptstelle. Die muss am Routing unbeabsichtigt was manipuliert haben. Sie stand weit oben und hatte lediglich besagt, das alles Richtung Außenstelle erlaubt sei. Oder ich habe unbeabsichtigt woanders in kurzer Zeit noch was geklickt...
Darauf wäre ich aber so auch kaum gekommen, denn mit einer Fritzbox am anderen Tunnelende lief alles, vor allem inkl. der o.g. Regel noch. Sehr merkwürdig das Ganze. Aber als oVPN lasse ich den Tunnel erstmal bestehen.
-
@sebden said in VoIP per Lan-2-Lan VPN, Verbindungsabbrüche uvm.:
Die NAT-Regeln brauchte ich nach jetzigem Verständnis dafür, dass ich die IPs im gegenüberliegenden Netz direkt auflösen konnte, ansonsten lief das irgendwie nur per NAT über die oVPN-Adresse der Firewall am anderen Ende.
Mir ist nicht klar was Du damit meinst, normal sagt man dem OpenVPN welche Netze sich dahinter befinden und dann geht das Routing automatisch durch die pfSense - OpenVPN.
Du kannst dann vom NetzA OpenVPN NetzB direkt auf die IP Adresse "zugreifen".
-
Ich würde hier mal klar Schiff machen.
Sauberes Netzkonzept, pro Standort welches auch ein paar Netze enthält für VLANs.
Dann sauber das VPN (egal auf welcher Bais der Tunnel basieet) mit Routing aufbauen.Dann brauchst du kein NAT was bei SIP mit oder ohne ALG immer in einem Haufen sch... endet.
Ne Sense kann im SIP rum wählen, ne Fritz ist dafür stumpf zu doof.
Daher hat es vermutlich die ganze Zeit mit den Gurken funktioniert.Aber im Moment machst du Betrieb durch Zufall!
