VoIP per Lan-2-Lan VPN, Verbindungsabbrüche uvm.
-
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!
