9
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: 11.04.2025 um 03:04 Uhr
9 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 sinnvollerweise 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 sinnvollerweise 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?!
Salut,
danke für deine Antwort, ich will es ja gar nicht zu kompliziert machen und der darüber abzuwickelnde Traffic soll A sauber getrennt und gefiltert sein und B wird der auch gar nicht so immens ausfallen.
Sind nachher zwei RDP-Cons und eine Weboberfläche.
Ich habe mich dazu durchgerungen den WAN-Port anders zu verkabeln, der lief noch über die Securepoint, das sollte sowieso weg und direkt an den Internetrouter.
Entsprechend habe ich mir nun das Netz zur Securepoint als Transfernetz genommen und Routen gebaut.
Sieht auch erstmal ganz gut aus, ich komme aktuell mit dem Client durch die Securepoint und durch die OPNsense, aber andersrum klappt noch nicht, das ist ein Problem für den Zukunfts-ToWa.
Erstmal verstehen was grundsätzlich abgeht und irgendwie will die OPNsense noch nicht in meinem Kopf.
Diese Verbindung wird geblockt:
Streiche ich nun die Quellenangabe und ersetze diese durch "jegliche":
Läuft die RDP Verbindung in diese Richtung.
Warum?
Im Protokoll steht doch ganz klar die Quelle drin und diese möchte ich freigeben, keine andere.
Grüße
ToWa
Deine „Neuverkabelung“ ist leider etwas verwirrend weil nicht ganz klar ist wo jetzt das „Koppelnetz“ ist. Wenn die OPNsense nun direkt am Internet Router ist wie ist das zu verstehen? Eine Router Kaskade mit diesem Router oder hängt die OPNsense mit ihrem LAN Port am LAN des Routers? Eine kleine Skizze würde das Design deutlich leichter verständlich machen um zielgerichtet helfen zu können.
Was dein Regelwerk für den Port 3389 RDP anbetrifft ist das davon abhängig welche Encapsulation du verwendest. RDP kann bekanntlich auf UDP oder TCP Basis transportiert werden. Wenn du in der Regel nur TCP erlaubst, nutzt aber UDP ists natürlich dann vorbei mit RDP. 😉
Was dein Regelwerk für den Port 3389 RDP anbetrifft ist das davon abhängig welche Encapsulation du verwendest. RDP kann bekanntlich auf UDP oder TCP Basis transportiert werden. Wenn du in der Regel nur TCP erlaubst, nutzt aber UDP ists natürlich dann vorbei mit RDP. 😉
Zitat von @aqui:
Deine „Neuverkabelung“ ist leider etwas verwirrend weil nicht ganz klar ist wo jetzt das „Koppelnetz“ ist.
Deine „Neuverkabelung“ ist leider etwas verwirrend weil nicht ganz klar ist wo jetzt das „Koppelnetz“ ist.
Doch das ist glasklar, zumindest wenn man davor sitzt.
Hier das gewünschte Schaubild, damit sollte es plausibel sein:
Was dein Regelwerk für den Port 3389 RDP anbetrifft ist das davon abhängig welche Encapsulation du verwendest. RDP kann bekanntlich auf UDP oder TCP Basis transportiert werden. Wenn du in der Regel nur TCP erlaubst, nutzt aber UDP ists natürlich dann vorbei mit RDP. 😉
Wie du oben im Regelwerk siehst ist bei TCP/UDP ein * für any.Zudem erklärt das für mich nicht, warum ich im Regelwerk bei Quelle des OPT1 nicht die Quelle hinterlegen kann, sondern mit einem * für any arbeiten muss, obwohl das Protokoll ganz klar die Quelle rauswirft?
P.S.: Wie gesagt aktuell läuft RDP von links nach rechts am Schaubild, aber noch nicht von rechts nach links...
Da hakt noch was wo ich noch schauen muss, mein Hauptproblem ist also erstmal den Aufbau des Regelsets bei der OPNsense zu verstehen, denn da ist die Securepoint für mich (vermutlich weil eher gewohnt) deutlich klarer.
Grüße
ToWa
Ok, das macht das Bild zumindestens klarer wen auch die Beschreibung der statische Routen wirr ist. Mal von dann wieder zu..hilfreich ist das nicht aber man kann sich denken das es vermutlich richtig ist. Üblicherweise gibt man immer das Ziel an und das dazu korrespondierende Gateway…aber nundenn..
Das Quellnetz bei OPT1 kann man sehr wohl hinterlegen. Zu mindestens hier an einem identischen Testaufbau.
Dort kann man wie generell regelüblich als Sourceadresse (Quelle) die 10.10.11.150 /32 (Hostadresse) also den Client, denn mit dieser Absender IP taucht der ja am OPT1 auf. Protokoll, wie du schon sagst, auf „any“ um UDP und TCP abzudecken, Zieladresse 10.10.111.60 mit dem Zielport 3389 (RDP).
Diese inbound Regel an OPT1 ist soweit ja korrekt und sollte auch entsprechend greifen.
Da das Regelwerk stateful ist wird auch der Return Traffic ( mit gesetztem ACK Bit (bei TCP)) vom .111.60er Server/PC zurück zum .11.150er Client sauber durchlaufen. Dies betrifft aber nur TCP. Bei UDP gibt es lediglich ein Zeitfenster für das eingehender Returntraffic kommen muss, den UDP hat bekanntlich kein ACK Bit.
Sollte der .111.60er Client selber auch eine RDP Session initiieren, kommt es auf das Regelwerk am LAN Port an als auch natürlich auf das am Koppelport der Securepoint. Ist übrigens bei der o.a. Richtung auch so. Das Regelwerk am 10.10.10.10er Port der Securepoint ist natürlich auch relevant da du ja für diese beiden Netze immer 2 Firewalls im Pfad als Kaskade hast.
Die o.a. Beschreibung geht davon aus das es kein NAT im Koppelnetz gibt!!
Das Quellnetz bei OPT1 kann man sehr wohl hinterlegen. Zu mindestens hier an einem identischen Testaufbau.
Dort kann man wie generell regelüblich als Sourceadresse (Quelle) die 10.10.11.150 /32 (Hostadresse) also den Client, denn mit dieser Absender IP taucht der ja am OPT1 auf. Protokoll, wie du schon sagst, auf „any“ um UDP und TCP abzudecken, Zieladresse 10.10.111.60 mit dem Zielport 3389 (RDP).
Diese inbound Regel an OPT1 ist soweit ja korrekt und sollte auch entsprechend greifen.
Da das Regelwerk stateful ist wird auch der Return Traffic ( mit gesetztem ACK Bit (bei TCP)) vom .111.60er Server/PC zurück zum .11.150er Client sauber durchlaufen. Dies betrifft aber nur TCP. Bei UDP gibt es lediglich ein Zeitfenster für das eingehender Returntraffic kommen muss, den UDP hat bekanntlich kein ACK Bit.
Sollte der .111.60er Client selber auch eine RDP Session initiieren, kommt es auf das Regelwerk am LAN Port an als auch natürlich auf das am Koppelport der Securepoint. Ist übrigens bei der o.a. Richtung auch so. Das Regelwerk am 10.10.10.10er Port der Securepoint ist natürlich auch relevant da du ja für diese beiden Netze immer 2 Firewalls im Pfad als Kaskade hast.
Die o.a. Beschreibung geht davon aus das es kein NAT im Koppelnetz gibt!!
Danke für die Ausführung.
Im Aliase hatte sich ein Zahlendreher bei der IP eingeschlichen.
Hatte ich gestern mehrfach geprüft, war wohl zu wenig Kaffee.
Im Standard sollte NAT aber doch nur auf den WAN-Ports liegen?
RDP in die andere Richtung muss ich dann mal ein wenig probieren, in den Protokollen der OPNsense sieht alles super aus, die Securepoint ist was Protokolle oder Mitschnitte angeht in meinen Augen leider ein Graus.
So haben die Systeme alle ihre Eigenheiten und ich für meinen Teil bin bislang mit keinem 100%ig warm geworden.
Edit: So, gemäß Protokoll an der OPNsense geht die Gegenrichtung korrekt raus:
An der Securepoint kommt die Anfrage korrekt an und wird zugelassen:
Da der Verbindungsaufbau aber nicht stattfindet, kommt die Antwort aber nicht zurück?
Edit: Die Windows-Firewall hat es am Client (.11.150) geblockt.
Da könnte man nun wieder ganz viele Fragen zu stellen, denn von einem Client im gleichen Netzwerk funktionierte RDP wunderbar an den Client.
Für den Client außerhalb des eigenen IP-Netzes nicht. Aber das liegt wohl an einer GPO die ich mir mal noch ansehen muss.
RDP also für das Domänennetz noch mal manuell freigegeben und tada läuft.
Grüße
ToWa
Zitat von @aqui:
Üblicherweise gibt man immer das Ziel an und das dazu korrespondierende Gateway…aber nundenn..
Anders geht es bei der OPNsense auch nicht, aber die Securepoint hat ein Quell-Feld, da bin ich doch verleitet dies zu nutzen:Üblicherweise gibt man immer das Ziel an und das dazu korrespondierende Gateway…aber nundenn..
Das Quellnetz bei OPT1 kann man sehr wohl hinterlegen. Zu mindestens hier an einem identischen Testaufbau.
Diese inbound Regel an OPT1 ist soweit ja korrekt und sollte auch entsprechend greifen.
Danke, Fehler gefunden, lag wie konnte es auch anders sein, natürlich am Anwender (mir).Diese inbound Regel an OPT1 ist soweit ja korrekt und sollte auch entsprechend greifen.
Im Aliase hatte sich ein Zahlendreher bei der IP eingeschlichen.
Hatte ich gestern mehrfach geprüft, war wohl zu wenig Kaffee.
Die o.a. Beschreibung geht davon aus das es kein NAT im Koppelnetz gibt!!
Ich hoffe dass es kein NAT gibt, das verwirrt mich nämlich nur noch mehr.Im Standard sollte NAT aber doch nur auf den WAN-Ports liegen?
RDP in die andere Richtung muss ich dann mal ein wenig probieren, in den Protokollen der OPNsense sieht alles super aus, die Securepoint ist was Protokolle oder Mitschnitte angeht in meinen Augen leider ein Graus.
So haben die Systeme alle ihre Eigenheiten und ich für meinen Teil bin bislang mit keinem 100%ig warm geworden.
Edit: So, gemäß Protokoll an der OPNsense geht die Gegenrichtung korrekt raus:
Da der Verbindungsaufbau aber nicht stattfindet, kommt die Antwort aber nicht zurück?
Edit: Die Windows-Firewall hat es am Client (.11.150) geblockt.
Da könnte man nun wieder ganz viele Fragen zu stellen, denn von einem Client im gleichen Netzwerk funktionierte RDP wunderbar an den Client.
Für den Client außerhalb des eigenen IP-Netzes nicht. Aber das liegt wohl an einer GPO die ich mir mal noch ansehen muss.
Grüße
ToWa
und tada läuft.
Kleine Ursache grosse… Kann im Eifer des Gefechts immer passieren.Die Winblows Firewall blockiert im Default bekanntlich alles was aus fremden IP Netzen und nicht aus dem eigenen lokalen Netz kommt. Administratorwissen… 😉
Klasse das es nun rennt wie es soll! 👏
Case closed!
