Hi,
am Ende deines Posts fehlt der Dank, dass jemand bis dahin gelesen hat. Das verdient doch auch schon Anerkennung. ;)
@Jorval:
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. ;)
@Jorval:
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_connection
Falls die Pakete aber in Ordnung sind, kann es sein, dass die VPN Verbindung unterbrochen wurde, ehe das Problem auftritt? Check mal das Log danach.
@Jorval:
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.
@Jorval:
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.0
Grüße
