3
OPNsense Firewallregel und Routing
Hallo zusammen,
die Woche startet leider, wie die alte aufgehört hat und Firewalls produzieren bei mir gern Kopfschmerzen.
So lange alles über eine Firewall läuft bekomme ich das eigentlich auf die Reihe, aber vermutlich hakt es an meinem OPNsense-Verständnis.
Der Testaufbau:
In meinem nicht mehr all zu jugendlichen Leichtsinn dachte ich nun ich lege unter dem
OPT1 - Interface der OPNsense
einfach eine Regel an, welche es dem Client 10.10.11.150 erlaubt an 10.10.111.4 zu kommunizieren.
Also:
OPT1 - PASS - in - Source 10.10.11.150 - Dest 10.10.111.4
Allerdings komme ich nicht durch.
Das Protokoll schmeißt mir einen Haufen Broadcasts auf der Schnittstelle raus, aber nicht mal ne Anfrage von der Quell-IP.
Wo ist der gedankliche Knoten in meinem Kopf?
Grüße
ToWa
die Woche startet leider, wie die alte aufgehört hat und Firewalls produzieren bei mir gern Kopfschmerzen.
So lange alles über eine Firewall läuft bekomme ich das eigentlich auf die Reihe, aber vermutlich hakt es an meinem OPNsense-Verständnis.
Der Testaufbau:
In meinem nicht mehr all zu jugendlichen Leichtsinn dachte ich nun ich lege unter dem
OPT1 - Interface der OPNsense
einfach eine Regel an, welche es dem Client 10.10.11.150 erlaubt an 10.10.111.4 zu kommunizieren.
Also:
OPT1 - PASS - in - Source 10.10.11.150 - Dest 10.10.111.4
Allerdings komme ich nicht durch.
Das Protokoll schmeißt mir einen Haufen Broadcasts auf der Schnittstelle raus, aber nicht mal ne Anfrage von der Quell-IP.
Wo ist der gedankliche Knoten in meinem Kopf?
Grüße
ToWa
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671708
Url: https://administrator.de/forum/opnsense-firewallregel-und-routing-671708.html
Ausgedruckt am: 03.03.2025 um 18:03 Uhr
3 Kommentare
Neuester Kommentar
1) Gibts denn auch eine Route zurück? Für die Antworten...
2) Die Sense hat 10.10.10.9 und befindet sich somit mitten im Addressbereich vom linken LAN 10.10.11.150/22. Da wird das Routing schwierig.
2) Die Sense hat 10.10.10.9 und befindet sich somit mitten im Addressbereich vom linken LAN 10.10.11.150/22. Da wird das Routing schwierig.
Ich hatte testweise auf der Securepoint mal eine gegenteilige Route drin, also von 10.10.111.0/24 zu 10.10.8.0/22 mit der 10.10.10.10 als Gateway-IP.
Geholfen hatte das aber nix.
Soll die Antworten einfach dahin schicken, wo die Anfrage herkommt, kann ja nicht so schwer sein.
Hmm also besser mit einem Transfernetz arbeiten?
So dass ich mir eine Route auf der OPNsense von 10.10.111.0/24 zu 10.10.8.0/22 mit Gateway 10.10.10.10 bauen kann?
Wäre auch denkbar.
Grüße
ToWa
Geholfen hatte das aber nix.
Soll die Antworten einfach dahin schicken, wo die Anfrage herkommt, kann ja nicht so schwer sein.
2) Die Sense hat 10.10.10.9 und befindet sich somit mitten im Addressbereich vom linken LAN 10.10.11.150/22. Da wird das Routing schwierig.
Hmm also besser mit einem Transfernetz arbeiten?
So dass ich mir eine Route auf der OPNsense von 10.10.111.0/24 zu 10.10.8.0/22 mit Gateway 10.10.10.10 bauen kann?
Wäre auch denkbar.
Grüße
ToWa
Das „Route eingerichtet“ auf der Securepoint ist leider etwas widersprüchlich. IPtechnisch korrekt müsste diese lauten
Zielnetz: 10.10.111.0, Maske: 255.255.255.0, Gateway: 10.10.10.9
Die OPT1 Regel ist soweit korrekt aber leider fehlt die Angabe eines Protokolls. Wenn du „IP“ dort gesetzt hast würde das erstmal bedeuten das alles was IP spricht zwischen diesen Clients durchgeht.
Allerdings lauert da Gefahr, denn du hast leider auch nicht angegeben ob es an OPT1 ggf. noch weitere Regeln gibt?!
Bekanntlich gilt dann immer First match wins! Es zählt also die Reihenfolge so das eine ggf. davor liegende Regel diese egalisieren kann. Das gilt es also zu prüfen.
Noch etwas ist wichtig: Es ist essentiell das die Securepoint ICMP Redirects senden darf an den .22er Client sofern dieser die Securepoint als Default Gateway gesetzt hat.
Diese Redirects sagen dem Client dann: //„Hey, das Gateway ins 10.10.111er Netz liegt auf der .10.9. nutze das, dann kommst du direkt dahin.
Das hat den Vorteil das der Client direkt über die OPNsense geht anstatt immer die Securepoint als „Durchlauferhitzer“ für diesen Traffic zu nutzen. Performancetechnisch nachteilig da der Traffic doppelt gesendet wird.
Schlimmer noch, die Securepoint kann dann je nach Regelwerk und Verhalten diesen Traffic dann erstmal durch ihr eigenes Regelwerk schicken bevor sie es zur OPNsense forwardet. Fehlt das dort scheitert die Verbindung schon da.
OPNsense und pfSense haben dafür einen „Bypass“ Schalter im Setup die solchen lokalen Traffic vom Regelwerk ausnimmt, vermutlich die Securepoint auch. Siehe dazu auch HIER.
Redirects sind auf FWs oft reglementiert. Hier ist es also wichtig das die Securepoint immer Redirects senden kann wenn mehrere Gateways auf einem Segment liegen sollte das im Setup berücksichtigt werden.
Nur das du diese 2 Punkte auch auf dem Radar hast?!
Zielnetz: 10.10.111.0, Maske: 255.255.255.0, Gateway: 10.10.10.9
Die OPT1 Regel ist soweit korrekt aber leider fehlt die Angabe eines Protokolls. Wenn du „IP“ dort gesetzt hast würde das erstmal bedeuten das alles was IP spricht zwischen diesen Clients durchgeht.
Allerdings lauert da Gefahr, denn du hast leider auch nicht angegeben ob es an OPT1 ggf. noch weitere Regeln gibt?!
Bekanntlich gilt dann immer First match wins! Es zählt also die Reihenfolge so das eine ggf. davor liegende Regel diese egalisieren kann. Das gilt es also zu prüfen.
Noch etwas ist wichtig: Es ist essentiell das die Securepoint ICMP Redirects senden darf an den .22er Client sofern dieser die Securepoint als Default Gateway gesetzt hat.
Diese Redirects sagen dem Client dann: //„Hey, das Gateway ins 10.10.111er Netz liegt auf der .10.9. nutze das, dann kommst du direkt dahin.
Das hat den Vorteil das der Client direkt über die OPNsense geht anstatt immer die Securepoint als „Durchlauferhitzer“ für diesen Traffic zu nutzen. Performancetechnisch nachteilig da der Traffic doppelt gesendet wird.
Schlimmer noch, die Securepoint kann dann je nach Regelwerk und Verhalten diesen Traffic dann erstmal durch ihr eigenes Regelwerk schicken bevor sie es zur OPNsense forwardet. Fehlt das dort scheitert die Verbindung schon da.
OPNsense und pfSense haben dafür einen „Bypass“ Schalter im Setup die solchen lokalen Traffic vom Regelwerk ausnimmt, vermutlich die Securepoint auch. Siehe dazu auch HIER.
Redirects sind auf FWs oft reglementiert. Hier ist es also wichtig das die Securepoint immer Redirects senden kann wenn mehrere Gateways auf einem Segment liegen sollte das im Setup berücksichtigt werden.
Nur das du diese 2 Punkte auch auf dem Radar hast?!
