5
OPNsense Regel greift nicht
Hallo zusammen,
folgender Aufbau: Um ein Schulungsnetzwerk (Schüler-Laptops) per Captive Portal bereitzustellen, setze ich eine virtuelle OpnSense ein. An diese werden von Proxmox zwei NICs durchgereicht:
Daneben liegt am Switch noch das VLAN 14 an, das als WLAN die Mitarbeiter im Gebäude versorgt.
Gateway im Schüler-VLAN, DHCP, DNS und Captive Portal ist die OpnSense, deren Gateway in den VLANs 10 und 148 wiederum die "Haupt-Firewall" (Watchguard) ist. Als Default Gateway ist die Watchguard in VLAN 148 festgelegt. Das funktioniert soweit auch alles - das Captive Portal greift, DNS klappt etc.
Nun soll auf den Laptops noch eine Art Fernüberwachung landen (Veyon), mit deren Hilfe die Lehrkräfte sehen können, was die Schüler gerade so treiben. Die Laptops der Lehrer befinden sich im VLAN 14 und bekommen dort statische Adressen. Die Schüler-Laptops bekommen von der OpnSense statische Adressen (und werden im Captive Portal ohne Auth direkt reingelassen). Woran es nun scheitert, ist die OpnSense-Firewall. Ich habe den Port für Veyon auf 8008 festgelegt, aber die Verbindung wird durch die default deny-Regel geblockt:
Nach meinem Empfinden ist das aber durch die erste Regel hier abgedeckt, die aber laut Inspect nicht greift (Status auf 0):
Schalte ich die Firewall in den Einstellungen aus, klappt alles, aber das ist ja nicht Sinn der Sache. Zumindest würde ich darüber gern verhindern, dass die Clients im VLAN 148 auf Port 80 bzw. 443 der OpnSense kommen.
Hat jemand eine Idee, wo mein Denkfehler liegt?
folgender Aufbau: Um ein Schulungsnetzwerk (Schüler-Laptops) per Captive Portal bereitzustellen, setze ich eine virtuelle OpnSense ein. An diese werden von Proxmox zwei NICs durchgereicht:
- untagged Haus-LAN (zur Verwaltung) - VLAN 10
- untagged Schüler-VLAN- VLAN 148
Daneben liegt am Switch noch das VLAN 14 an, das als WLAN die Mitarbeiter im Gebäude versorgt.
Gateway im Schüler-VLAN, DHCP, DNS und Captive Portal ist die OpnSense, deren Gateway in den VLANs 10 und 148 wiederum die "Haupt-Firewall" (Watchguard) ist. Als Default Gateway ist die Watchguard in VLAN 148 festgelegt. Das funktioniert soweit auch alles - das Captive Portal greift, DNS klappt etc.
Nun soll auf den Laptops noch eine Art Fernüberwachung landen (Veyon), mit deren Hilfe die Lehrkräfte sehen können, was die Schüler gerade so treiben. Die Laptops der Lehrer befinden sich im VLAN 14 und bekommen dort statische Adressen. Die Schüler-Laptops bekommen von der OpnSense statische Adressen (und werden im Captive Portal ohne Auth direkt reingelassen). Woran es nun scheitert, ist die OpnSense-Firewall. Ich habe den Port für Veyon auf 8008 festgelegt, aber die Verbindung wird durch die default deny-Regel geblockt:
Nach meinem Empfinden ist das aber durch die erste Regel hier abgedeckt, die aber laut Inspect nicht greift (Status auf 0):
Schalte ich die Firewall in den Einstellungen aus, klappt alles, aber das ist ja nicht Sinn der Sache. Zumindest würde ich darüber gern verhindern, dass die Clients im VLAN 148 auf Port 80 bzw. 443 der OpnSense kommen.
Hat jemand eine Idee, wo mein Denkfehler liegt?
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: 43747277921
Url: https://administrator.de/contentid/43747277921
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
5 Kommentare
Neuester Kommentar
Hallo,
da dürftest du ein asymmetrisches Routing Problem haben, was bei den VLANs mit unterschiedlichen Gateways leicht passieren kann.
Geblockt wird hier lediglich ein SA-Paket, also eine Antwort. Da hat die OPNSense offenbar nicht das zugehörige SYN-Paket gesehen.
Grüße
da dürftest du ein asymmetrisches Routing Problem haben, was bei den VLANs mit unterschiedlichen Gateways leicht passieren kann.
Geblockt wird hier lediglich ein SA-Paket, also eine Antwort. Da hat die OPNSense offenbar nicht das zugehörige SYN-Paket gesehen.
Grüße
Schaue doch mal in die automatisch generierten Regeln, vielleicht ist da was durch das Captive Portal geregelt, das Dir da Probleme bereitet.
@viragomann:
Das schaut gut aus. Ich habe das GW in VLAN 148 in der OpnSense gelöscht und die Watchguard aus dem VLAN rausgenommen. Jetzt scheinen alle Pakete auf der OpnSense durchzugehen. Auf der WG noch nicht, wie es scheint - das muss ich morgen mal ergründen. Trotzdem schonmal vielen Dank!
Das schaut gut aus. Ich habe das GW in VLAN 148 in der OpnSense gelöscht und die Watchguard aus dem VLAN rausgenommen. Jetzt scheinen alle Pakete auf der OpnSense durchzugehen. Auf der WG noch nicht, wie es scheint - das muss ich morgen mal ergründen. Trotzdem schonmal vielen Dank!
Du hast sehr wahrscheinlich einen fatalen Fehler im Routing Design gemacht. Niemals dürfen Netze die du mit der OPNsense sicherst parallel an eine andere Firewall angeschlossen sein. Das führt zu einem "Backdoor" Router und auch zu asymetrischem Routing wie oben schon richtig gesagt wurde. Aus Sicherheits- und auch Routing Gründen ein fataler Fehler!
Es ist leider nicht ganz klar WIE dein Netzwerk Design aussieht aber nach deiner Beschreibung sollte es vermutlich so aussehen:
Dies zeigt ein Bilderbuch Design wie es auszusehen hat mit einem sauberen und eindeutigem Routing welches sicherstellt das deine Firewall Regeln auch sauber greifen.
Also noch einmal in aller Ruhe das hiesige Routing Tutorial durchlesen und verstehen.
Alles zur Virtualisierung der Firewall auf Proxmox, wie immer, hier und auch hier.
Es ist leider nicht ganz klar WIE dein Netzwerk Design aussieht aber nach deiner Beschreibung sollte es vermutlich so aussehen:
Also noch einmal in aller Ruhe das hiesige Routing Tutorial durchlesen und verstehen.
Alles zur Virtualisierung der Firewall auf Proxmox, wie immer, hier und auch hier.
1
Hallo aqui,
ja, genau, nach der Entfernung des zusätzlichen Gateways sieht das Routing aus wie auf dem Schaubild. Dass die Fernüberwachung noch nicht wollte, lag übrigens an einer falschen Portnummer in deren Konfig, nicht an der Watchguard.
Danke für den Hinweis zu Proxmox, das führe ich mir mal noch zu Gemüte.
ja, genau, nach der Entfernung des zusätzlichen Gateways sieht das Routing aus wie auf dem Schaubild. Dass die Fernüberwachung noch nicht wollte, lag übrigens an einer falschen Portnummer in deren Konfig, nicht an der Watchguard.
Danke für den Hinweis zu Proxmox, das führe ich mir mal noch zu Gemüte.
