PfSense Site-2-Site kein ssh durch den Tunnel und ein paar andere Kleinigkeiten.
-
Hallo Sense Forum,
Ich habe mit meiner 2 pfSense ein paar Probleme bzw. merkwürdiges verhalten und hoffe hier findet sich jemand der mir bei der Klärung helfen kann.
Vorweg, ich habe privat noch eine Sense im Einsatz und unsere Sense am Hauptstandort machen beide keine Probleme.
Ich habe ein schnelles Diagramm angefügt, hoffe ich hab nichts übersehen alle werte richtig und nix vergessen.Wir haben 2 Nebenstandorte die beide mit Telekom IPSEC VPN angebunden 'waren'. Den ersten habe ich auf OVPN mit der 2 Sense umgestellt.
Die Sense (192.168.0.1) am Hauptstandort ist ein eigener Server, Die 2te Sense (192.168.1.1) am Nebenstandort ist auf einem Xen als VM installiert. Der Server hat 2 Interfaces. das erste ist LAN das 2 ist nur auf der Sense VM Aktiv und ist WAN. Alle Standorte haben feste öffentliche IPs.
Der OVPN Tunnel war schnell gebaut und läuft stabil.Die komplette IT ist vor kurzem vom Hauptstandort an den 2 Nebenstandort umgezogen das noch über ein Telekom ipsec auf Internet CoCo's aufgebaut ist.
So kommen wir mal zu den Problemen ;)
A. 2. Sense erstellt keine AutoNAT Rules
B. 2. Sense scheint hin und wieder Rules zu missachten
C. push der default Route durch den Tunnel hat nur einmal kurz funktioniert.
D. Alles scheint am Branch1 zu funktionieren nur kein ssh auf den Debian Server, Ruleset stimmt aber.A Kein Auto NAT
Am Hauptstandort läuft ein Proxy der 98% unseres Netzverkehrs abdeckt. Da die Welt nicht einfach ist hat der Internetgott Applikationen ersinnt die durch Proxy's nicht funktionieren wollen. Glück für mich das die auf Statischen Netzen liegen. also hab ich einfach eine Route an der 2.Sense im Branch1 ins direkt ins Internet gesetzt. und die Clients die das dürfen sollen in einen Alias gepackt und eine Regel erstellt die den Clients diese Netze erlauben sollen. Klappte aber nicht. Ich bin nicht gleich darauf gekommen einen Blick ins Firewall -> NAT zu werfen aber da war keine Regel automatisch erstellt worden. Sollte die Sense das nicht eigentlich tun? Oder gibt es eine Einstellung die vorher dafür aktiviert werden muss? Ich habe jedenfalls auf Hybrid umgestellt und das NAT dann von Hand eingerichtet, Ich bin mir aber sicher das die Große im Hauptbetrieb das allein gemacht hat die steht auch auf Automatisch und hat Einträge generiert.B Mal gilt die Regel mal nicht.
Hat mit der gleichen Sache zu tun. Die oben erwähnte Regel funktionierte Tadellos. Am nächsten Tag ein aufgeregter User das Programm geht nicht?! Regel Überprüft, alles richtig meiner Meinung nach.Das Log zeigt mir aber Blocks an wenn der User das Programm startet. Die Pakete landen in der default ipv4 deny rule? Regel einmal anfassen, speichern Apply und Sie funktioniert wieder. Auf nachfrage im IRC antwortete jemand das dies passieren könnte wenn ein FIN Packet für eine Bereits terminierte Verbindung ankommt (z.b. wegen packetloss) Ich verstehe aber nicht warum das gleich die ganze Regel außer kraft setzen sollte? Ich hoffe darauf weiß jemand eine Antwort oder kann mir helfen das Problem weiter zu debuggen.C Eigentlich wollte ich den kompletten Verkehr durch den Tunnel an den Hauptstandort haben wie es auch bei der abgelösten TKom Verbindung der Fall war. Das im OVPN Server auf der HauptbetriebsSense eingetragene push "route 0.0.0.0/0" hat er auch min. 1 mal gezogen, das habe ich beim Diagnostic -> Routes gesehen, aber dann war ich so mit Problem B beschäftigt und hatte einiges geändert das ich das erst einmal nicht weiter verfolgt habe. Jetzt steht das Default Gw aber nur noch ins inet. Das ist für mich generell auch ok da wir vllt. einmal Proxy vor Ort nachrüsten möchten, aber auch hier verstehe ich nicht ganz warum er die Anweisung dropt. Vielleicht hat jemand einen kleinen schubs ins richtige log für mich ?
D Kein ssh durch den Tunnel.
So das beste zum Schluss ;) Ich hoffe am Ende stellt sich heraus das ich einfach nur etwas ganz dummes im Regelwerk verbockt habe.
An Branch1 geht auf Seite der Benutzer soweit alles, Die User machen RDP Verbindungen ins RZ das RZ schickt Druckaufträge in Branch1 die Kollegen kommen via Browser und Proxy ins Internet und selbst Seiten die nochmal hinter einem NAT am Hauptstandort liegen funktionieren ohne Probleme.
Ich kann allerdings von Standort Branch2 wo nun die IT sitzt keine ssh Verbindung mehr zum Debian Server an Standort Branch1 aufbauen. Manchmal kommt nach langer wartezeit wenigstens die Passwort abfrage. ping und tracepath laufen den korrekten weg. Ich kann weder den xenserver 192.168.1.2 noch den debian 192.168.1.3 connecten. ssh zur Sense 192.168.1.1 funktioniert hingegen perfekt (zu meinem Glück)
Vom Hauptbetrieb das selbe Spiel die Sense in Branch1 ist erreichbar die beiden anderen (Xen,Deb) leider nicht.
Das OVPN hat ja ein Telekom VPN abgelöst. Anfangs ging die Verbindung vom Hauptbetrieb zu den beiden Servern hinter der 2. Sense noch, von meinem Standort Branch2 nicht weil an dem Telekomrouter 192.168.0.2 noch eine statische Route gesetzt war und die Pakete schon vorher in Richtung Branch1 abgebogen sind. Also hab ich mich mit ssh Tunneln Graben beholfen und nach 12 Tagen hatte die TKom es geschafft die Route zu löschen, eigentlich dachte ich es wird besser aber seid dem kam auch der Hauptstandort nicht mehr auf die beiden Maschinen. Ich bin da jetzt so langsam ratlos. Auf der 2.Sense sehe ich auf der Konsole auch die Pakete im tcpdump wenn ich versuche eine Verbindung vom Hauptbetrieb oder dem 2 Betrieb aufzubauen, aber das wars.
Muss ic für das OVPN die MTU anpassen ? aber wieso funktionieren dann bei allen andern im Branch 1 alle Anwendungen Problemlos ? Warum gehen die Druckjobs die definitiv nicht durchs RDP getunnelt sind einwandfrei vom Hauptbetrieb in den Nebenbetrieb?
Ich hoffe jemand weiss rat ich fühl mich gerade etwas ratlos.Entschuldigt den langen ausführlichen text ich hoffe ich habe alles verständlich niedergeschrieben und bedanke mich für jeden der sich dem Problem stellt und mir helfen mag.
Martin
-
Hi,
am Ende deines Posts fehlt der Dank, dass jemand bis dahin gelesen hat. Das verdient doch auch schon Anerkennung. ;)
A Kein Auto NAT
also hab ich einfach eine Route an der 2.Sense im Branch1 ins direkt ins Internet gesetzt. und die Clients die das dürfen sollen in einen Alias gepackt und eine Regel erstellt die den Clients diese Netze erlauben sollen. Klappte aber nicht. Ich bin nicht gleich darauf gekommen einen Blick ins Firewall -> NAT zu werfen aber da war keine Regel automatisch erstellt worden. Sollte die Sense das nicht eigentlich tun? Oder gibt es eine Einstellung die vorher dafür aktiviert werden muss? Ich habe jedenfalls auf Hybrid umgestellt und das NAT dann von Hand eingerichtet, Ich bin mir aber sicher das die Große im Hauptbetrieb das allein gemacht hat die steht auch auf Automatisch und hat Einträge generiert.Automatisch erstellt werden nur Regeln fürs WAN, nicht für andere Interfaces. Da ist das auch nur selten gewollt, und Wünsche von den Augen des Admin abzulesen, gibt es erst im übernächsten großen Release. ;)
B Mal gilt die Regel mal nicht.
Hat mit der gleichen Sache zu tun. Die oben erwähnte Regel funktionierte Tadellos. Am nächsten Tag ein aufgeregter User das Programm geht nicht?! Regel Überprüft, alles richtig meiner Meinung nach.Das Log zeigt mir aber Blocks an wenn der User das Programm startet. Die Pakete landen in der default ipv4 deny rule? Regel einmal anfassen, speichern Apply und Sie funktioniert wieder. Auf nachfrage im IRC antwortete jemand das dies passieren könnte wenn ein FIN Packet für eine Bereits terminierte Verbindung ankommt (z.b. wegen packetloss) Ich verstehe aber nicht warum das gleich die ganze Regel außer kraft setzen sollte?Was für Flags habe die gelockten Pakete im Log?
pfSense loggt nur die ersten Pakete einer Verbindung, also bei ordnungsgemäßer TCP Verbindung nur die SYN Pakete. Andere TCP Pakete stehen nur im Log, wenn die Verbindung bereits geschlossen wurde oder nie aufgebaut wurde.
Könnte damit in Zusammenhang stehen:
https://doc.pfsense.org/index.php/Why_do_my_logs_show_%22blocked%22_for_traffic_from_a_legitimate_connectionFalls die Pakete aber in Ordnung sind, kann es sein, dass die VPN Verbindung unterbrochen wurde, ehe das Problem auftritt? Check mal das Log danach.
C Eigentlich wollte ich den kompletten Verkehr durch den Tunnel an den Hauptstandort haben wie es auch bei der abgelösten TKom Verbindung der Fall war. Das im OVPN Server auf der HauptbetriebsSense eingetragene push "route 0.0.0.0/0" hat er auch min. 1 mal gezogen, das habe ich beim Diagnostic -> Routes gesehen, aber dann war ich so mit Problem B beschäftigt und hatte einiges geändert das ich das erst einmal nicht weiter verfolgt habe. Jetzt steht das Default Gw aber nur noch ins inet. Das ist für mich generell auch ok da wir vllt. einmal Proxy vor Ort nachrüsten möchten, aber auch hier verstehe ich nicht ganz warum er die Anweisung dropt. Vielleicht hat jemand einen kleinen schubs ins richtige log für mich ?
Warum das nicht geht, kann ich dir auch nicht sagen, aber Gegenfrage:
Warum arbeitest du bei einer dauerhaften Verbindung überhaupt mit push route??
Die Netze, die über die VPN geroutet werden sollen, kannst du ja in der Client Konfiguration, nehme an das ist Branch 1, eintragen (Remote Networks), bzw. ebenso am Server. Das hat faktisch den gleichen Effekt, als ob du es in die Routingtabelle einträgst und funktioniert immer (wenn die Verbindung steht).
Andere Routen sind für diese Netze ohnehin nicht vorgesehen, denke ich.D Kein ssh durch den Tunnel.
An Branch1 geht auf Seite der Benutzer soweit alles, Die User machen RDP Verbindungen ins RZ das RZ schickt Druckaufträge in Branch1 die Kollegen kommen via Browser und Proxy ins Internet und selbst Seiten die nochmal hinter einem NAT am Hauptstandort liegen funktionieren ohne Probleme.
Ich kann allerdings von Standort Branch2 wo nun die IT sitzt keine ssh Verbindung mehr zum Debian Server an Standort Branch1 aufbauen. Manchmal kommt nach langer wartezeit wenigstens die Passwort abfrage. ping und tracepath laufen den korrekten weg. Ich kann weder den xenserver 192.168.1.2 noch den debian 192.168.1.3 connecten. ssh zur Sense 192.168.1.1 funktioniert hingegen perfekt (zu meinem Glück)
Vom Hauptbetrieb das selbe Spiel die Sense in Branch1 ist erreichbar die beiden anderen (Xen,Deb) leider nicht.
Das OVPN hat ja ein Telekom VPN abgelöst.Die pfSense erreichst du per ssh über den VPN Tunnel? Wenn ja, stimmt die Threadüberschrift nicht und die Ursache ist möglicherweise auch nicht beim Tunnel zu suchen.
Gleichzeitig mit der Umstellung von der früheren Lösung habt ihr die neue pfSense auch virtualisiert. Vielleicht ein XEN Problem? Schau dir mal diesen Thread an und prüfe die Empfehlungen:
https://forum.pfsense.org/index.php?topic=88467.0Grüße