20
IPsec site-to-site Internetzugang
Hallo,
aktuell besteht bei mir eine IPsec IKEv2 site-to-site Verbindung zwischen einer pfSense und einer Sophos Firewall.
Nun soll der gesamte Internetverkehr von der pfSense mittels IPsec über die Sophos Firewall geroutet werden.
Soweit klappt auch alles. Das einzige Problem, dass ich aktuell noch habe: sobald die IPsec Verbindung verloren geht, wird der Internetverkehr der pfSense wieder über das normale Internetgateway geroutet. Ich hätte es aber gerne so, dass es ausschließlich über den VPN Tunnel geroutet wird.
Ich bin davon ausgegangen, dass ich eine Firewall Regel mit Deny IPv4+IPv6 mit Ziel WAN NET setze, und dadrunter dann entsprechend HTTPS und HTTP erlaube, dies scheint aber nicht zu funktionieren. Default Gateway wegzunehmen funktioniert ebenfalls nicht.
Hat sonst noch jemand eine Idee?
Danke
aktuell besteht bei mir eine IPsec IKEv2 site-to-site Verbindung zwischen einer pfSense und einer Sophos Firewall.
Nun soll der gesamte Internetverkehr von der pfSense mittels IPsec über die Sophos Firewall geroutet werden.
Soweit klappt auch alles. Das einzige Problem, dass ich aktuell noch habe: sobald die IPsec Verbindung verloren geht, wird der Internetverkehr der pfSense wieder über das normale Internetgateway geroutet. Ich hätte es aber gerne so, dass es ausschließlich über den VPN Tunnel geroutet wird.
Ich bin davon ausgegangen, dass ich eine Firewall Regel mit Deny IPv4+IPv6 mit Ziel WAN NET setze, und dadrunter dann entsprechend HTTPS und HTTP erlaube, dies scheint aber nicht zu funktionieren. Default Gateway wegzunehmen funktioniert ebenfalls nicht.
Hat sonst noch jemand eine Idee?
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 82801718775
Url: https://administrator.de/contentid/82801718775
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
20 Kommentare
Neuester Kommentar
Default Gateway wegzunehmen
Wie soll dann Dein IPsec auch noch funktionieren? Keine gute Idee.Firewall Regel mit Deny IPv4+IPv6 mit Ziel WAN NET ... scheint aber nicht zu funktionieren
Schau mal bitte ins Handbuch. Wird dort gleich 2x klar gestellt:
Viele Grüße, commodity
Zitat von @commodity:
Du musst hier IMO den "Internet-"Traffic über das WAN-Interface verbieten und nur in den Tunnel erlauben.
Du musst hier IMO den "Internet-"Traffic über das WAN-Interface verbieten und nur in den Tunnel erlauben.
Ja, genau das war ja meine Frage. Ich wüsste nur nicht wie ich das regelbasiert einrichten kann.
Zitat von @jktz84:
Ja, genau das war ja meine Frage. Ich wüsste nur nicht wie ich das regelbasiert einrichten kann.
Zitat von @commodity:
Du musst hier IMO den "Internet-"Traffic über das WAN-Interface verbieten und nur in den Tunnel erlauben.
Du musst hier IMO den "Internet-"Traffic über das WAN-Interface verbieten und nur in den Tunnel erlauben.
Ja, genau das war ja meine Frage. Ich wüsste nur nicht wie ich das regelbasiert einrichten kann.
Moin,
Bau dir ein Alias für die RFC1918er Adressen. Alles andere sind public Adressen.
Gruß
Spirit
Ich wüsste nur nicht wie ich das regelbasiert einrichten kann.
auch nicht, nachdem Du den obigen Fehler korrigiert hast? Wo hakt es denn dann noch?Viele Grüße, commodity
dass ich eine Firewall Regel mit Deny IPv4+IPv6 mit Ziel WAN NET setze
Die dann ziemlich unsinnig wäre da sie niemals greift, denn welches Internet Ziel sollte denn gerade einzig in dem kleinen Koppelnetz liegen was dir dein Provider am WAN Port der FW liefert?! Kollege @commodity hat es oben ja schon richtig zitiert.Das "Internet" liegt in Millionen anderer Netze aber nicht im kleinen WAN Netz...
Dein Verständins von IP Netzen bzw. Regelwerken ist hier wohl etwas durcheinandergekommen...
Eine einfache aber nicht ganz wasserdichte Lösung ist den DNS Server auf die remote Seite zu legen. Wenn der Tunnel wech ist könne die lokalen Clients keine Namen mehr auflösen und "das Internet" geht dann nicht. Nicht ganz wasserdicht deshalb weil's über nackte IPs noch geht, was einfache Anwender aber nicht wissen.
Eine einfache aber nicht ganz wasserdichte Lösung ist den DNS Server auf die remote Seite zu legen. Wenn der Tunnel wech ist könne die lokalen Clients keine Namen mehr auflösen und "das Internet" geht dann nicht. Nicht ganz wasserdicht deshalb weil's über nackte IPs noch geht, was einfache Anwender aber nicht wissen.
Ich brauche leider weiterhin einen erreichbaren DNS Server, um spezifische Routen über ein weiteres VPN zu schicken.
Zitat von @Spirit-of-Eli:
Bau dir ein Alias für die RFC1918er Adressen. Alles andere sind public Adressen.
Bau dir ein Alias für die RFC1918er Adressen. Alles andere sind public Adressen.
Weiß gerade nicht wie ich damit weiterkomme. In der Firewall von Interface X kommend muss ich den Zugriff auf alle Adressen erlauben, ansonsten erfolgt keine Weiterleitung über den VPN Kanal. Wenn nun aber der VPN Kanal deaktiviert ist, wird es stattdessen über das normale Gateway geleitet.
Als Hintergrund:
Ich würde mir gerne die Kosten für eine weitere Sophos inkl, Subscription sparen, gleichzeitig aber nicht auf DPI und Webcontent Filterung verzichten. Das ganze macht natürlich nur eingeschränkt Sinn, wenn bei einem Ausfall der VPN Verbindung alles direkt über die pfSense ins Internet geleitet wrid...
In der Firewall von Interface X kommend muss ich den Zugriff auf alle Adressen erlauben,
Aber Du musst doch vielleicht nicht alle Protokolle erlauben. Lass doch http und https nur durch den Tunnel zu.Oder schaffe ein Extra-Interface für die Clients, die Internetverkehr haben und filtere nach dem Source-Interface.
Viele Grüße, commodity
Zitat von @commodity:
Aber Du musst doch vielleicht nicht alle Protokolle erlauben. Lass doch http und https nur durch den Tunnel zu.
Oder schaffe ein Extra-Interface für die Clients, die Internetverkehr haben und filtere nach dem Source-Interface.
Aber Du musst doch vielleicht nicht alle Protokolle erlauben. Lass doch http und https nur durch den Tunnel zu.
Oder schaffe ein Extra-Interface für die Clients, die Internetverkehr haben und filtere nach dem Source-Interface.
Aber was auch immer ich in der Firewallregel durch den Tunnel erlaube, wird automatisch durchs normale WAN Interface geroutet, sobald der Tunnel down ist. Ich kann nicht explizit die Daten über den Tunnel routen, wie man es bei z.B Sophos kann.
Hm, weil Du bei IPsec kein routingfähiges Interface hast?
Evtl. kannst Du dem mit virtual interfaces abhelfen.
https://docs.opnsense.org/manual/vpnet.html#route-based-vti (die Netgate-Doku ist gerade down). Hab ich aber keine Erfahrungen mit.
Mit einem Wireguard-Tunnel hast Du ja Interfaces, da sollte das ohne Verrenkungen klappen. Ist das vielleicht eine Option?
Viele Grüße, commodity
Evtl. kannst Du dem mit virtual interfaces abhelfen.
https://docs.opnsense.org/manual/vpnet.html#route-based-vti (die Netgate-Doku ist gerade down). Hab ich aber keine Erfahrungen mit.
Mit einem Wireguard-Tunnel hast Du ja Interfaces, da sollte das ohne Verrenkungen klappen. Ist das vielleicht eine Option?
Viele Grüße, commodity
Hab ich aber keine Erfahrungen mit.
Cisco, Mikrotik, pfSense site-to-site VPN with dynamic routing 😉Damit klappt es weil man dann Policy based Routing machen kann. Muss aber die Gegenseite auch supporten!
Ich habe es jetzt mal mit dem VTI Ansatz versucht. Der VPN Tunnel wird aufgebaut und ich erhalte Pakete von der Sophos in Richtung pfSense. Von der pfSense aber werden keinerlei Pakete in den Tunnel geroutet.
Bei der pfSense ist das VTI Gateway eingerichtet und die statische Route für das Zielnetzwerk eingerichtet - aber trotzdem komplette Funkstille. Die zuvor eingerichteten Phase 2 Verbindungen sind deaktiviert.
Irgendeine Idee?
Bei der pfSense ist das VTI Gateway eingerichtet und die statische Route für das Zielnetzwerk eingerichtet - aber trotzdem komplette Funkstille. Die zuvor eingerichteten Phase 2 Verbindungen sind deaktiviert.
Irgendeine Idee?
Wie sehen denn die Regeln für die PBR Konfig aus? Bei VTI machst du damit den Pointer in den Tunnel.
Reicht die statische Route nicht aus? PBR ist nicht hinterlegt
Im IPsec Tab sind die entsprechenden Firewallregeln aktiviert.
Im IPsec Tab sind die entsprechenden Firewallregeln aktiviert.
Okay, die statische Route sollte es auch tun.
Aber von der Sense kannst du die Sophos pingen?
Wird denn etwas geblickt? Das würde auf fehlende Regeln schließen lassen.
Aber von der Sense kannst du die Sophos pingen?
Wird denn etwas geblickt? Das würde auf fehlende Regeln schließen lassen.
Nein, auch von der pfSense aus kann ich die Sophos nicht pingen. Er zeigt zwar das Gateway als online an, aber auch mit Packet Capture kann ich auf dem VTI Interface nichts erkennen.
Auf dem LAN Interface kommt sofort das Echo reply.
Traceroute zeigt auch nichts nützliches an.
Auf dem LAN Interface kommt sofort das Echo reply.
Traceroute zeigt auch nichts nützliches an.
VTI mode setzt zwingend einen fest definierten remote Host vor, 0.0.0.0/0 und Responder Mode führt dazu, dass anscheinend die Phase 1 Verbindung problemlos aufgebaut wird, aber nichts über den VPN Kanal geroutet wird.
Warum das nicht in den Manuals steht ist mir ein absolutes Rätsel, und zeigt eigentlich wieder wie unausgereift das Ganze ist.
Zwar habe ich jetzt wieder Zugriff auf das remote LAN Subnetz, beim Internetzugriff aber scheint er wahlweise den VPN Kanal oder das standard Gateway WAN zu verwenden, obwohl ich in der Firewall Regel klar auf das Gateway verwiesen habe.
Macht wieder keinen Sinn
Warum das nicht in den Manuals steht ist mir ein absolutes Rätsel, und zeigt eigentlich wieder wie unausgereift das Ganze ist.
Zwar habe ich jetzt wieder Zugriff auf das remote LAN Subnetz, beim Internetzugriff aber scheint er wahlweise den VPN Kanal oder das standard Gateway WAN zu verwenden, obwohl ich in der Firewall Regel klar auf das Gateway verwiesen habe.
Macht wieder keinen Sinn
Bei einer PfSense steht das klar und deutlich im Conf-Guide drin. Deswegen funktioniert das einfache umschalten auch nicht so simpel.
Ich frag mich gerade ob die Sophos das über haupt in dem Sinne kann.
Ich habe bei mir hier gerade ein ähnliches Konstrukt laufen. Auch per VTI, allerdings zwischen zwei PfSense.
Wenn ich dort explizit Zugriff nur per PBR auf den Tunnel erlaube, funktioniert das ganze so wie gewünscht.
Vermutlich scheitert es bei dir an der statischen Route. Die würde mich ohne hin stören da du ja eine weitere default Route in die Sense eintragen musst.
Schmeiß die mal raus und bei dir eine PBR mit dem entsprechenden Gateway und von mir aus erstmal als Ziel any zu testen.
Ich frag mich gerade ob die Sophos das über haupt in dem Sinne kann.
Ich habe bei mir hier gerade ein ähnliches Konstrukt laufen. Auch per VTI, allerdings zwischen zwei PfSense.
Wenn ich dort explizit Zugriff nur per PBR auf den Tunnel erlaube, funktioniert das ganze so wie gewünscht.
Vermutlich scheitert es bei dir an der statischen Route. Die würde mich ohne hin stören da du ja eine weitere default Route in die Sense eintragen musst.
Schmeiß die mal raus und bei dir eine PBR mit dem entsprechenden Gateway und von mir aus erstmal als Ziel any zu testen.
Letzte Frage bis ich durch bin... (danke schon einmal so weit für die Hilfe).
Aktuell funktioniert der VPN Tunnel nur vorübergehend, nach einer gewissen Zeit lassen sich keine neuen TCP Verbindungen aus Richtung pfSense aufbauen. Bestehende TCP Verbindungen, solange die nicht neu aufgebaut werden, laufen aber weiterhin.
Verbindungen von pfSense Richtung Sophos laufen weiterhin problemlos.
Auf der Sophos Firewall erhalte ich dann in der Log entsprechend Hinweise, dass die Verbindungen geblockt werden mit Verweis auf 'invalid traffic'.
Ping läuft durchgehend einwandfrei.
Packet Capture auf dem VTI Interface der pfSense spuckt bei einer enstprechenden Anfrage folgendes aus:
Handelt es sich hierbei um eine zu Hohe MTU auf Seiten der pfSense?
Aktuell funktioniert der VPN Tunnel nur vorübergehend, nach einer gewissen Zeit lassen sich keine neuen TCP Verbindungen aus Richtung pfSense aufbauen. Bestehende TCP Verbindungen, solange die nicht neu aufgebaut werden, laufen aber weiterhin.
Verbindungen von pfSense Richtung Sophos laufen weiterhin problemlos.
Auf der Sophos Firewall erhalte ich dann in der Log entsprechend Hinweise, dass die Verbindungen geblockt werden mit Verweis auf 'invalid traffic'.
Ping läuft durchgehend einwandfrei.
Packet Capture auf dem VTI Interface der pfSense spuckt bei einer enstprechenden Anfrage folgendes aus:
192.168.0.10.63684 > 192.168.11.1.4444: Flags [SEW], cksum 0x9e24 (correct), seq 3559736705, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
13:24:46.271145 AF IPv4 (2), length 56: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
192.168.11.1.4444 > 192.168.0.10.63684: Flags [S.], cksum 0x9984 (correct), seq 2677677017, ack 3559736706, win 27200, options [mss 1360,nop,nop,sackOK,nop,wscale 7], length 0Handelt es sich hierbei um eine zu Hohe MTU auf Seiten der pfSense?
VTI mode setzt zwingend einen fest definierten remote Host vor
Deshalb auch der entsprechende o.a. Hinweis ob deine Sophos auch im VTI Mode ist?? 🤔Das MUSS auf beiden Seiten der Fall sein und beide Seiten zwingend einen VTI Tunnel Mode verwenden!
Eine klassische P1/P2 VPN Verbindung kann niemals nur einseitig auf ein VTI Setup arbeiten oder vice versa. Siehe o.a. Tutorialbeispiel mit Cisco in einem gemischten VTI Design!
