31
OPNsense blockiert HTTPS Traffic zwischen 2 Netzwerken
Hallo zusammen.
Ich habe seit ca. 2 Wochen ein sehr spezielles Problem. Meine OPNsense Firewall lässt keinen HTTPS Traffic zwischen dem Wireguard VPN Netzwerk und meinem Server VLAN mehr durch. Das Problem besteht unabhängig vom Port und der Quell oder Zieladresse. HTTPS Anfragen in andere VLANS oder Netzwerke gehen problemlos durch. Ich habe nach 2 Wochen Fehlersuche nun keinerlei Ideen mehr wodurch dieses Problem zustande kommen könnte. Ich hatte in der Vergangenheit mit Suricata unter OPNsense Probleme. Suricata war aber nur auf einer anderen Schnittstelle aktiv und auch nur im Alert Modus. Ich bin wirklich am verzweifeln, weil ich zu so einem speziellen Problem bisher gar nichts gefunden habe.
Vielen Dank in Voraus.
LG Leo
Ich habe seit ca. 2 Wochen ein sehr spezielles Problem. Meine OPNsense Firewall lässt keinen HTTPS Traffic zwischen dem Wireguard VPN Netzwerk und meinem Server VLAN mehr durch. Das Problem besteht unabhängig vom Port und der Quell oder Zieladresse. HTTPS Anfragen in andere VLANS oder Netzwerke gehen problemlos durch. Ich habe nach 2 Wochen Fehlersuche nun keinerlei Ideen mehr wodurch dieses Problem zustande kommen könnte. Ich hatte in der Vergangenheit mit Suricata unter OPNsense Probleme. Suricata war aber nur auf einer anderen Schnittstelle aktiv und auch nur im Alert Modus. Ich bin wirklich am verzweifeln, weil ich zu so einem speziellen Problem bisher gar nichts gefunden habe.
Vielen Dank in Voraus.
LG Leo
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: 8725532251
Url: https://administrator.de/forum/opnsense-blockiert-https-traffic-zwischen-2-netzwerken-8725532251.html
Ausgedruckt am: 22.12.2024 um 23:12 Uhr
31 Kommentare
Neuester Kommentar
Hallo,
hast Du denn HTTPS auf dieser Verbindung erlaubt? Poste doch mal die Firewallregeln.
Grüße
lcer
hast Du denn HTTPS auf dieser Verbindung erlaubt? Poste doch mal die Firewallregeln.
Grüße
lcer
1
Moin,
Und sicher, dass es die Sense ist?
Oder wird am Zielsystem das IP-Netz des Wireguard-Netzes blockiert?
Was sagt das Log der Sense?
Und sicher, dass es die Sense ist?
Oder wird am Zielsystem das IP-Netz des Wireguard-Netzes blockiert?
Was sagt das Log der Sense?
1
Mach von beiden Seiten mal Traceroutes zur jeweiligen Gegenstelle und gucke, ob die durchgehen.
Du musst dafür dann natürlich ICMP in der opnSense und den jeweiligen lokalen Firewalls erlauben.
Du musst dafür dann natürlich ICMP in der opnSense und den jeweiligen lokalen Firewalls erlauben.
1
Beachte auch das Tunnelregelwerk! Dieses wird nicht auf das Group Interface konfiguriert sondern auf das dediziert eingerichtete Tunnelinterface!! Guckst du hier:
Merkzettel: VPN Installation mit Wireguard
Ohne dein genaues Regelwerk zu kennen ist das aber alles Kristallkugelei!
Merkzettel: VPN Installation mit Wireguard
Ohne dein genaues Regelwerk zu kennen ist das aber alles Kristallkugelei!
1
Zitat von @lcer00:
Hallo,
hast Du denn HTTPS auf dieser Verbindung erlaubt? Poste doch mal die Firewallregeln.
Grüße
lcer
Hallo,
hast Du denn HTTPS auf dieser Verbindung erlaubt? Poste doch mal die Firewallregeln.
Grüße
lcer
Zitat von @em-pie:
Moin,
Und sicher, dass es die Sense ist?
Oder wird am Zielsystem das IP-Netz des Wireguard-Netzes blockiert?
Was sagt das Log der Sense?
Moin,
Und sicher, dass es die Sense ist?
Oder wird am Zielsystem das IP-Netz des Wireguard-Netzes blockiert?
Was sagt das Log der Sense?
Dass das auf den Zielsystemen plötzlich die Tunnel-IP gesperrt ist kann ich ausschließen, da nur HTTPS Traffic geblockt wird. Alle anderen Services gehen wie normal. Das Log der Sense zeigt, dass die Anfrage durch die FW durchgelassen wurde, aber auf dem entsprechenden Server kommt keine Anfrage an.
Zitat von @LordGurke:
Mach von beiden Seiten mal Traceroutes zur jeweiligen Gegenstelle und gucke, ob die durchgehen.
Du musst dafür dann natürlich ICMP in der opnSense und den jeweiligen lokalen Firewalls erlauben.
Mach von beiden Seiten mal Traceroutes zur jeweiligen Gegenstelle und gucke, ob die durchgehen.
Du musst dafür dann natürlich ICMP in der opnSense und den jeweiligen lokalen Firewalls erlauben.
Pings und traceroutes gehen durch in beide Richtungen. Die Verbindung besteht auch auf jeden Fall, da alles bis auf HTTPS funktioniert.
LG Leo
Zitat von @aqui:
Beachte auch das Tunnelregelwerk! Dieses wird nicht auf das Group Interface konfiguriert sondern auf das dediziert eingerichtete Tunnelinterface!! Guckst du hier:
Merkzettel: VPN Installation mit Wireguard
Ohne dein genaues Regelwerk zu kennen ist das aber alles Kristallkugelei!
Beachte auch das Tunnelregelwerk! Dieses wird nicht auf das Group Interface konfiguriert sondern auf das dediziert eingerichtete Tunnelinterface!! Guckst du hier:
Merkzettel: VPN Installation mit Wireguard
Ohne dein genaues Regelwerk zu kennen ist das aber alles Kristallkugelei!
Dieses Regelwerk ist in meinem Fall nicht 1 zu 1 Anwendbar, da die OPNsense hier WG Client ist und nicht der Server. Die FW Regeln sowie das Gateway sind auch auf das Tunnelinterface konfiguriert. Ich glaube nicht, dass es am VPN liegt. Das Setup lief schließlich fast ein ganzes Jahr schon ohne ein einziges Problem.
Wie man hier sieht ist der Alias "HTTP_S" bei "Reverseproxy" eingetragen. Dieser enthält Port 80 und 443.
Wo denn? 🤔So oder so ist der Eintrag unsinnig denn HTTPS ist ja nun mal TCP 443 only zumindestens wenn man vom Standardport redet.
In einer normalen Standardkonfig kommt dieser Alias auch nicht vor bzw. ist überflüssig. Stört aber (vermutlich) auch nicht, denn ein Alias ist ja erstmal nur ein Namens Platzhalter.
Anders sieht es natürlich aus wenn der irgendwo im Regelwerk zum Einsatz kommt.
Wie bereits gesagt: Ohne das genaue Regelwerk zu kennen ist alles Kristallkugelei!
1Zitat von @aqui:
So oder so ist der Eintrag unsinnig denn HTTPS ist ja nun mal TCP 443 only zumindestens wenn man vom Standardport redet.
In einer normalen Standardkonfig kommt dieser Alias auch nicht vor bzw. ist überflüssig. Stört aber (vermutlich) auch nicht, denn ein Alias ist ja erstmal nur ein Namens Platzhalter.
Anders sieht es natürlich aus wenn der irgendwo im Regelwerk zum Einsatz kommt.
Wie bereits gesagt: Ohne das genaue Regelwerk zu kennen ist alles Kristallkugelei!
Wie man hier sieht ist der Alias "HTTP_S" bei "Reverseproxy" eingetragen. Dieser enthält Port 80 und 443.
Wo denn? 🤔So oder so ist der Eintrag unsinnig denn HTTPS ist ja nun mal TCP 443 only zumindestens wenn man vom Standardport redet.
In einer normalen Standardkonfig kommt dieser Alias auch nicht vor bzw. ist überflüssig. Stört aber (vermutlich) auch nicht, denn ein Alias ist ja erstmal nur ein Namens Platzhalter.
Anders sieht es natürlich aus wenn der irgendwo im Regelwerk zum Einsatz kommt.
Wie bereits gesagt: Ohne das genaue Regelwerk zu kennen ist alles Kristallkugelei!
Das Bild wurde bei meinem Post nicht angefügt, jetzt sollte es da sein. Es ist keine Standardkonfig, da dies aus Sicherheitsgründen erforderlich ist, aber alle konfigurierten Regeln funktionieren auch. Das Problem liegt meiner Nachforschung nach nicht an den Ports da HTTPS Anfragen auf egal welchem Port geblockt werden. Siehe Nextcloud auf Port 9001.
Hallo,
also ich würde dann an jedem beteiligten Gerät den Datenverkehr mitschreiben und sehen, wo etwas fehlt.
Alternativ erstellen separate Firewallregeln auf der opnsense, die den HTTPS Traffic erlauben und protokollieren.
Grüße
lcer
also ich würde dann an jedem beteiligten Gerät den Datenverkehr mitschreiben und sehen, wo etwas fehlt.
Alternativ erstellen separate Firewallregeln auf der opnsense, die den HTTPS Traffic erlauben und protokollieren.
Grüße
lcer
2
Wie lautet eigentlich die genaue Fehlermeldung?
Also was zeigt der Browser an?
Je nach Fehlermeldung wird der Traffic (Das Datenpaket) ja gar nicht auf den Layery <=4 geblockt, sondern es ist ein Fegler höherer Protokollebenen (z.B. Zertifikatsfehler …)
Also was zeigt der Browser an?
Je nach Fehlermeldung wird der Traffic (Das Datenpaket) ja gar nicht auf den Layery <=4 geblockt, sondern es ist ein Fegler höherer Protokollebenen (z.B. Zertifikatsfehler …)
1Zitat von @lcer00:
Hallo,
also ich würde dann an jedem beteiligten Gerät den Datenverkehr mitschreiben und sehen, wo etwas fehlt.
Alternativ erstellen separate Firewallregeln auf der opnsense, die den HTTPS Traffic erlauben und protokollieren.
Grüße
lcer
Hallo,
also ich würde dann an jedem beteiligten Gerät den Datenverkehr mitschreiben und sehen, wo etwas fehlt.
Alternativ erstellen separate Firewallregeln auf der opnsense, die den HTTPS Traffic erlauben und protokollieren.
Grüße
lcer
Den Paketmitschnitt werde ich morgen ausprobieren.
Zitat von @em-pie:
Wie lautet eigentlich die genaue Fehlermeldung?
Also was zeigt der Browser an?
Je nach Fehlermeldung wird der Traffic (Das Datenpaket) ja gar nicht auf den Layer <=4 geblockt, sondern es ist ein Fehler höherer Protokollebenen (z.B. Zertifikatsfehler …)
Wie lautet eigentlich die genaue Fehlermeldung?
Also was zeigt der Browser an?
Je nach Fehlermeldung wird der Traffic (Das Datenpaket) ja gar nicht auf den Layer <=4 geblockt, sondern es ist ein Fehler höherer Protokollebenen (z.B. Zertifikatsfehler …)
Die konkrete Fehlermeldung ist: "Website ist nicht erreichbar" Timed Out. Einen Fehler auf höherer Protokollebene halte ich für durchaus möglich. Ich frage mich nur, wodurch dieser Fehler zustande kommen kann, da ich in dem Zeitraum, in dem der Fehler auftrat weder Änderungen an der OPNsense noch dem Zielsystem vorgenommen hatte, d.h. auch keine Updates. Es hat von einem auf den anderen Tag nicht mehr funktioniert.
LG Leo
Hallo,
Vergangenheitsform - also hast du keine Fehler mehr...
Gruß,
Peter
Vergangenheitsform - also hast du keine Fehler mehr...
weder Änderungen an der OPNsense noch dem Zielsystem vorgenommen hatte,
Da kamen dann die Internetschlümpfe (Eingebrochen bei dir) und haben teile vom https Protokoll beim rausgehen mitgehen lassen.d.h. auch keine Updates.
Und das hälst du für Klug?Es hat von einem auf den anderen Tag nicht mehr funktioniert.
Und da du noch nichts protokolliert oder mitgeschnitten hast ...Gruß,
Peter
1
Hallo.
Neue Erkenntnisse aus der Paketaufnahme:
Der eingehende Traffic wird problemlos durchgelassen. Hingegen werden beim ausgehenden Traffic die TLS ACK Pakete verworfen, wodurch es zu einigen Retransmission kommt bis der Server die Verbindung zurücksetzt.
Das würde ja auch bedeuten, dass das Filtering nicht auf Firewall Ebene stattfindet, sondern wie von @em-pie vermutet auf einem höheren Layer. Wie kann es dazu kommen??
LG Leo
Neue Erkenntnisse aus der Paketaufnahme:
Der eingehende Traffic wird problemlos durchgelassen. Hingegen werden beim ausgehenden Traffic die TLS ACK Pakete verworfen, wodurch es zu einigen Retransmission kommt bis der Server die Verbindung zurücksetzt.
Das würde ja auch bedeuten, dass das Filtering nicht auf Firewall Ebene stattfindet, sondern wie von @em-pie vermutet auf einem höheren Layer. Wie kann es dazu kommen??
LG Leo
Zitat von @LOENS2:
Hingegen werden beim ausgehenden Traffic die TLS ACK Pakete verworfen, wodurch es zu einigen Retransmission kommt bis der Server die Verbindung zurücksetzt.
Wer verwirft was? Oder meinst Du, dass beim ausgehenden Traffic keine TLS ACK Pakete zu sehen sind?Hingegen werden beim ausgehenden Traffic die TLS ACK Pakete verworfen, wodurch es zu einigen Retransmission kommt bis der Server die Verbindung zurücksetzt.
Grüße
lcer
2Zitat von @lcer00:
Wer verwirft was? Oder meinst Du, dass beim ausgehenden Traffic keine TLS ACK Pakete zu sehen sind?
Grüße
lcer
Wer verwirft was? Oder meinst Du, dass beim ausgehenden Traffic keine TLS ACK Pakete zu sehen sind?
Grüße
lcer
Die Sense verwirft die Pakete. Im Server VLAN Traffic sind sie vorhanden, beim ausgehenden VPN Traffic nicht mehr. Daraus schlussfolgere ich, dass diese in der Sense verworfen werden.
Hallo,
also wenn die OPNsense die Pakete verwirft, sollte es dazu einen Log-Eintrag geben.
Überprüfe mal, ob alle Deny-Firewall Regeln das Logging aktiviert haben.
Ansonsten müsste etwas bei Surricata zu finden sein.
Oder hast du so etwas Konfiguriert? https://docs.opnsense.org/manual/how-tos/proxytransparent.html#
Grüße
lcer
also wenn die OPNsense die Pakete verwirft, sollte es dazu einen Log-Eintrag geben.
Überprüfe mal, ob alle Deny-Firewall Regeln das Logging aktiviert haben.
Ansonsten müsste etwas bei Surricata zu finden sein.
Oder hast du so etwas Konfiguriert? https://docs.opnsense.org/manual/how-tos/proxytransparent.html#
Grüße
lcer
2
@icer00:
Logging ist aktiviert für die Deny Regeln, aber es steht nichts im Log. Einen Transparent Proxy verwende ich auch nicht. Ich habe nur leider keine Ahnung von Suricata und wie man das Zurücksetzt. Es ist derzeit bei mir gar nicht aktiviert, aber ich hatte in der Vergangenheit damit schon Probleme.
Alternativ könnte ich auch mal ein clean install der Sense probieren, wenn das helfen sollte.
LG Leo
Logging ist aktiviert für die Deny Regeln, aber es steht nichts im Log. Einen Transparent Proxy verwende ich auch nicht. Ich habe nur leider keine Ahnung von Suricata und wie man das Zurücksetzt. Es ist derzeit bei mir gar nicht aktiviert, aber ich hatte in der Vergangenheit damit schon Probleme.
Alternativ könnte ich auch mal ein clean install der Sense probieren, wenn das helfen sollte.
LG Leo
Und Du bist sicher, dass Suricata aus ist? Andere Plugins?
Gibt es sonst vielleicht noch Firewallregeln für InterfaceGruppen?
Grüße
lcer
Gibt es sonst vielleicht noch Firewallregeln für InterfaceGruppen?
Grüße
lcer
1Zitat von @lcer00:
Und Du bist sicher, dass Suricata aus ist? Andere Plugins?
Gibt es sonst vielleicht noch Firewallregeln für InterfaceGruppen?
Grüße
lcer
Und Du bist sicher, dass Suricata aus ist? Andere Plugins?
Gibt es sonst vielleicht noch Firewallregeln für InterfaceGruppen?
Grüße
lcer
Ist das aus genug? Suricata wird auch nicht in den Services angezeigt. Ich habe nur die Interface Gruppe "Wireguard". Diese hat keine Regeln angelegt. Andere Plugins für Filterung habe ich nicht installiert.
LG Leo
Die Gruppen-Rules oder Floating-Rules der Firewall?
1
Das Einfachste wäre ja testweise einmal eine "Scheunentorregel" zu setzen die alles erlaubt. Wenns damit klappt ist der Fehler im Regelwerk...einfache Logik! 😉
1
Dabei aber bitte die Verarbeitungsteihenfolge beachten. Siehe https://docs.opnsense.org/manual/firewall.html - Processing Order
Grüße
lcer
Grüße
lcer
2
Hallo,
falls wirklich alle Einstellungen und Regeln der OPNSense stimmen, hat sich vielleicht die IP des Zielsystems geändert…
Grüße
lcer
falls wirklich alle Einstellungen und Regeln der OPNSense stimmen, hat sich vielleicht die IP des Zielsystems geändert…
Grüße
lcer
1Ich habe weder floating rules noch Gruppen Regeln verwendet. Bei beiden sind keinerlei Einträge vorhanden
Zitat von @aqui:
Das Einfachste wäre ja testweise einmal eine "Scheunentorregel" zu setzen die alles erlaubt. Wenns damit klappt ist der Fehler im Regelwerk...einfache Logik! 😉
Das Einfachste wäre ja testweise einmal eine "Scheunentorregel" zu setzen die alles erlaubt. Wenns damit klappt ist der Fehler im Regelwerk...einfache Logik! 😉
Das habe ich Versucht, hat aber absolut nichts gebracht. Egal auf welchem Zielsystem.
Zitat von @lcer00:
Dabei aber bitte die Verarbeitungsreihenfolge beachten. Siehe https://docs.opnsense.org/manual/firewall.html - Processing Order
Grüße
lcer
Dabei aber bitte die Verarbeitungsreihenfolge beachten. Siehe https://docs.opnsense.org/manual/firewall.html - Processing Order
Grüße
lcer
Die Reihenfolge habe ich so beachtet, es gibt ohnehin keine Deny Regeln bei mir, die so etwas blockieren könnten. Habe nur Port 22 für alle Geräte geblockt.
Zitat von @lcer00:
Hallo,
falls wirklich alle Einstellungen und Regeln der OPNSense stimmen, hat sich vielleicht die IP des Zielsystems geändert…
Grüße
lcer
Hallo,
falls wirklich alle Einstellungen und Regeln der OPNSense stimmen, hat sich vielleicht die IP des Zielsystems geändert…
Grüße
lcer
Das kann leider auch nicht sein, da es hier um 7 Hosts handelt und diese alle eine statische IP vergeben haben und aus allen anderen Netzen erreichbar sind.
Vielen Dank für die Vorschläge bisher.
LG Leo
Hallo,
na wenn alles stimmt… vielleicht liegt das Problem ja ganz woanders: https://www.heise.de/news/Microsoft-deaktiviert-TLS-1-0-und-1-1-in-kuenf ...
Grüße
lcer
na wenn alles stimmt… vielleicht liegt das Problem ja ganz woanders: https://www.heise.de/news/Microsoft-deaktiviert-TLS-1-0-und-1-1-in-kuenf ...
Grüße
lcer
2Zitat von @lcer00:
Hallo,
na wenn alles stimmt… vielleicht liegt das Problem ja ganz woanders: https://www.heise.de/news/Microsoft-deaktiviert-TLS-1-0-und-1-1-in-kuenf ...
Grüße
lcer
Hallo,
na wenn alles stimmt… vielleicht liegt das Problem ja ganz woanders: https://www.heise.de/news/Microsoft-deaktiviert-TLS-1-0-und-1-1-in-kuenf ...
Grüße
lcer
Ich verwende TLS 1.3, also sollte auch daher kein Problem entstehen.
LG Leo
Hallo,
na dann stell das doch mal auf TLS 1.2 und schau, was dann passiert.
Grüße
lcer
na dann stell das doch mal auf TLS 1.2 und schau, was dann passiert.
Grüße
lcer
2Zitat von @lcer00:
Hallo,
na dann stell das doch mal auf TLS 1.2 und schau, was dann passiert.
Grüße
lcer
Hallo,
na dann stell das doch mal auf TLS 1.2 und schau, was dann passiert.
Grüße
lcer
Das hat leider auch nichts gebracht. Hätte mich auch gewundert, wenn die Sense nur TLS 1.3 auf einem Interface blockieren würde.
LG Leo
Hallo Zusammen.
Nach einigem debugging habe ich herausgefunden, dass möglicherweise der Wechsel von wireguard-go zur Kernelimplementierung das Problem ausgelöst hat. Bei einem Stromausfall wurde der Router durch NUT neu gestartet und hat dann Wireguard geupdated. Das klingt zwar unlogisch, ist aber die einzige Erklärung die ich habe, warum das Problem "plötzlich" da war.
Derzeit ist es nicht mal mehr möglich sich mit dem Wireguard Tunnel zu verbinden. Kann ich wieder auf wireguard-go zurück wechseln?
LG Leo
Nach einigem debugging habe ich herausgefunden, dass möglicherweise der Wechsel von wireguard-go zur Kernelimplementierung das Problem ausgelöst hat. Bei einem Stromausfall wurde der Router durch NUT neu gestartet und hat dann Wireguard geupdated. Das klingt zwar unlogisch, ist aber die einzige Erklärung die ich habe, warum das Problem "plötzlich" da war.
Derzeit ist es nicht mal mehr möglich sich mit dem Wireguard Tunnel zu verbinden. Kann ich wieder auf wireguard-go zurück wechseln?
LG Leo
Hallo Zusammen.
Vielen Dank an alle, die mir bei der Lösung dieses Problems geholfen haben.
Nun zu meiner Lösung:
Ich habe OPNsense neu aufgesetzt und die alte Konfiguration wieder geladen.
Aufgrund des Wechsels zum Wireguard Kernelmodul konnte keine Verbindung mehr hergestellt werden.
Dieses Problem habe ich ducrh das Festlegen eines "Persistent Keepalive" gelöst.
Jetzt funktioniert wieder alles wie vorher.
LG Leo
Vielen Dank an alle, die mir bei der Lösung dieses Problems geholfen haben.
Nun zu meiner Lösung:
Ich habe OPNsense neu aufgesetzt und die alte Konfiguration wieder geladen.
Aufgrund des Wechsels zum Wireguard Kernelmodul konnte keine Verbindung mehr hergestellt werden.
Dieses Problem habe ich ducrh das Festlegen eines "Persistent Keepalive" gelöst.
Jetzt funktioniert wieder alles wie vorher.
LG Leo
Wie OPNsense korrekt mit Wireguard als Responder (Server) aufzusetzen ist beschreibt das hiesige Wireguard Tutorial im Detail.
