loens2
Goto Top

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

Content-Key: 8725532251

Url: https://administrator.de/contentid/8725532251

Printed on: February 23, 2024 at 06:02 o'clock

Member: lcer00
lcer00 Sep 02, 2023 at 11:55:56 (UTC)
Goto Top
Hallo,

hast Du denn HTTPS auf dieser Verbindung erlaubt? Poste doch mal die Firewallregeln.

Grüße

lcer
Member: em-pie
em-pie Sep 02, 2023 at 12:14:32 (UTC)
Goto Top
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?
Member: LordGurke
LordGurke Sep 02, 2023 at 12:26:12 (UTC)
Goto Top
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.
Member: aqui
aqui Sep 02, 2023 updated at 15:37:12 (UTC)
Goto Top
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! face-sad
Member: LOENS2
LOENS2 Sep 02, 2023 at 16:33:46 (UTC)
Goto Top
Zitat von @lcer00:

Hallo,

hast Du denn HTTPS auf dieser Verbindung erlaubt? Poste doch mal die Firewallregeln.

Grüße

lcer


screenshot 2023-09-02 172541
Wie man hier sieht ist der Alias "HTTP_S" bei "Reverseproxy" eingetragen. Dieser enthält Port 80 und 443.

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?

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.

Pings und traceroutes gehen durch in beide Richtungen. Die Verbindung besteht auch auf jeden Fall, da alles bis auf HTTPS funktioniert.

LG Leo
Member: LOENS2
LOENS2 Sep 02, 2023 at 16:38:31 (UTC)
Goto Top
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! face-sad

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.
Member: aqui
aqui Sep 02, 2023 updated at 17:19:32 (UTC)
Goto Top
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!
Member: LOENS2
LOENS2 Sep 02, 2023 at 17:29:22 (UTC)
Goto Top
Zitat von @aqui:

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.
Member: lcer00
lcer00 Sep 02, 2023 at 18:46:45 (UTC)
Goto Top
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
Member: em-pie
em-pie Sep 02, 2023 at 19:28:53 (UTC)
Goto Top
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 …)
Member: LOENS2
LOENS2 Sep 02, 2023, updated at Sep 03, 2023 at 10:03:28 (UTC)
Goto Top
Zitat 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

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 …)

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
Member: Pjordorf
Pjordorf Sep 02, 2023 at 23:38:10 (UTC)
Goto Top
Hallo,

Zitat von @LOENS2:
da ich in dem Zeitraum, in dem der Fehler auftrat
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
Member: LOENS2
LOENS2 Sep 03, 2023 at 10:02:46 (UTC)
Goto Top
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
Member: lcer00
lcer00 Sep 03, 2023 at 10:54:01 (UTC)
Goto Top
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?

Grüße

lcer
Member: LOENS2
LOENS2 Sep 03, 2023 at 10:59:25 (UTC)
Goto Top
Zitat von @lcer00:

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.
Member: lcer00
lcer00 Sep 03, 2023 at 11:49:33 (UTC)
Goto Top
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
Member: LOENS2
LOENS2 Sep 03, 2023 at 15:20:42 (UTC)
Goto Top
@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
Member: lcer00
lcer00 Sep 03, 2023 at 15:42:43 (UTC)
Goto Top
Und Du bist sicher, dass Suricata aus ist? Andere Plugins?

Gibt es sonst vielleicht noch Firewallregeln für InterfaceGruppen?

Grüße

lcer
Member: LOENS2
LOENS2 Sep 03, 2023 updated at 16:17:22 (UTC)
Goto Top
Zitat von @lcer00:

Und Du bist sicher, dass Suricata aus ist? Andere Plugins?

Gibt es sonst vielleicht noch Firewallregeln für InterfaceGruppen?

Grüße

lcer

screenshot 2023-09-03 180140

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
Member: lcer00
lcer00 Sep 03, 2023 at 16:48:50 (UTC)
Goto Top
Die Gruppen-Rules oder Floating-Rules der Firewall?
Member: aqui
aqui Sep 03, 2023 updated at 17:19:14 (UTC)
Goto Top
Das Einfachste wäre ja testweise einmal eine "Scheunentorregel" zu setzen die alles erlaubt. Wenns damit klappt ist der Fehler im Regelwerk...einfache Logik! 😉
Member: lcer00
lcer00 Sep 03, 2023 at 17:48:51 (UTC)
Goto Top
Dabei aber bitte die Verarbeitungsteihenfolge beachten. Siehe https://docs.opnsense.org/manual/firewall.html - Processing Order

Grüße

lcer
Member: lcer00
lcer00 Sep 04, 2023 at 05:38:42 (UTC)
Goto Top
Hallo,

falls wirklich alle Einstellungen und Regeln der OPNSense stimmen, hat sich vielleicht die IP des Zielsystems geändert…

Grüße

lcer
Member: LOENS2
LOENS2 Sep 05, 2023 at 15:41:44 (UTC)
Goto Top
Zitat von @lcer00:

Die Gruppen-Rules oder Floating-Rules der Firewall?

Ich 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 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

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

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
Member: lcer00
lcer00 Sep 05, 2023 at 17:29:40 (UTC)
Goto Top
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
Member: LOENS2
LOENS2 Sep 05, 2023 at 17:34:04 (UTC)
Goto Top
Zitat 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

Ich verwende TLS 1.3, also sollte auch daher kein Problem entstehen.

LG Leo
Member: lcer00
lcer00 Sep 05, 2023 at 17:50:40 (UTC)
Goto Top
Hallo,
Zitat von @LOENS2:

Ich verwende TLS 1.3, also sollte auch daher kein Problem entstehen.
na dann stell das doch mal auf TLS 1.2 und schau, was dann passiert.

Grüße

lcer
Member: LOENS2
LOENS2 Sep 06, 2023 at 14:19:19 (UTC)
Goto Top
Zitat von @lcer00:

Hallo,
Zitat von @LOENS2:

Ich verwende TLS 1.3, also sollte auch daher kein Problem entstehen.
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
Member: LOENS2
LOENS2 Sep 09, 2023 at 12:54:37 (UTC)
Goto Top
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
Member: LOENS2
Solution LOENS2 Sep 16, 2023 at 11:23:32 (UTC)
Goto Top
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
Member: aqui
aqui Sep 16, 2023 updated at 11:49:43 (UTC)
Goto Top
Wie OPNsense korrekt mit Wireguard als Responder (Server) aufzusetzen ist beschreibt das hiesige Wireguard Tutorial im Detail.