Verstädnisfrage Wireguard Regeln

[wirehire]

 Hey,

ich bräuchte eine Erklärung oder eine Bestätigung ob meine Annahme der Regeln korrekt ist.

Aufbau s2s zwei sense wireguard.

Jetzt möchte ich , das aber nur von der einen Seite aus zb icmp und rdp erreichbar ist, die andere seite aber kein zugriff auf das remote Netz hat.

Ich hatte jetzt keine Regeln auf Seite 1 angelegt = wäre für alles wird geblockt. (floating kann es aber überschreiben?)

und nur auf de rzweiten Seite dann die Regel gemacht, da kam aber blocks und ich musste rdp zb im wireguard interface erlauben.

Wäre der richtige Aufbau, auf beiden Seiten ein Block generell zu legen und dann wiederum darüber nur das entsprechende zu erlauben?

Grüße!

[Lucas P]

Die Regeln greifen schon auf dem ersten Interface, wo die Pakete ankommen.

Beispiel:
LAN1: 192.168.1.0/4
Remote: 192.168.5.0/24

Nun soll LAN per ICMP an Remote dürfen.
Dazu muss zuerst der Datenverkehr auf LAN1 erlaubt sein, entweder hast du da dort schon eine Regel die z.B: ICMP an alles erlaubt oder legst explizit eine mit dem Ziel Remote an.

Dann brauchst du auf der Remote Firewall noch eine Regel, die als Quelle LAN1 ICMP in Remote erlaubt. Diese Regel wird auf dem Wireguard Interface angelegt, da dort die Pakete zuerst eintreffen.

[wirehire]

Danke für dein Beispiel, mus sich kurz verinnerlichen.

Das heißt, wenn ich vermeiden möchte, das von der remoteseite2 nicht jemand in das netz kommt, darf es keine regel auf dem wg interface haben korrekt? bzw eine block rule.

Seite 1 . lan regel icmp zu ziel zb 10.10.10.10 erlaubt,

dann würde die regel greifen, durch den vpn bis rübe rzur seite zwei.

Und jetzt block nötig oder wnen nicht erlaubt, dann kommt es nicht durch?

[meyergru]

Na klar. Du musst bei site-2-site das Wireguard-Interface praktisch genau so behandeln wie ein WAN. Wenn der Tunnel steht, bestimmst Du, was drüber hereinkommt.

Ich mache das immer explizit, indem ich in den WG-Interface-Regeln am Ende ein block auf Ziel any mache und ggf. davor spezifische Regeln. Du musst aber bedenken, dass Floating Rules eventuell früher ziehen als Interface-Regeln. Deswegen muss man dort genau darauf achten, für welche Quell-Interfaces diese Regeln gelten. Ich habe dafür zwei Typen: 1. "alle" - das sind dann beispielsweise DNS und NTP auf der Firewall und 2. Gruppe "lokal", das sind meine eigenen VLANs, die die WG-Interfaces nicht einschließen. Darin wäre dann z.B. Zugriff auf einen Log- oder Mailserver.

[Lucas P]

Seite 1 . lan regel icmp zu ziel zb 10.10.10.10 erlaubt,

dann würde die regel greifen, durch den vpn bis rübe rzur seite zwei.

Und jetzt block nötig oder wnen nicht erlaubt, dann kommt es nicht durch?

Ganz genau.

Ich mache die Regeln selbst immer auf dem VPN Interface, auch wenn ich die Kontrolle für beide Firewalls habe.
So kann man auf einen Blick sehen, was per VPN rein kommt und was nicht.

Floating Regeln nutze ich garnicht, bevorzuge es die Regel da zu lassen, wo sie hingehört

[wirehire]

Vielen lieben Dank an euch!

Genau durch die Floating regel ist es mir aufgefallen. Ich habe jetzt die Floating regeln jeweils angepasst.
Dazu auf dem WG interface ein Block, sodass, auch wenn auf der einen seite eine falsche flaoting regel vorhanden wäre, es nicht auf der remote Seite, das wg interface passieren würde!

Danke noch mal an euch, dass ihr mir den Knoten im Kopf gelöst habt!

[meyergru]

Dazu auf dem WG interface ein Block, sodass, auch wenn auf der einen seite eine falsche flaoting regel vorhanden wäre, es nicht auf der remote Seite, das wg interface passieren würde!

Kritisch wäre, wenn auf "Deiner" Seite eine Floating-Regel etwas erlaubt, weil die vor den Interface-Regeln greifen. Wie gesagt, um das zu verhindern, nutze ich immer eine Interface-Gruppe für die "Nicht-WG" Interfaces (=VLANs) und nutze die in den Floating Regeln.

Ansonsten immer am lokalen Ende des WG-Tunnels filtern, der "andere" kann ja erlauben, was er will.

[wirehire]

Kannst du das mit der flaoting regel noch mal erklären? wenn du jetzt zb floating regel src 10.10.10.10 erlaubt web ports. dann würde das ja auch zb durch den tunnel gehen, weil sie zuerst greift. oder sehe ich das falsch?

und ja , absolut richtig immer auf den wg interfaces / gruppen, ein block , damit egal was ein anderer freiguibt , es nicht ohne extra regel anzulegen , geblockt wird.

[meyergru]

Es gibt eine "Abarbeitungsreihenfolge" der Regeln, siehe: https://docs.opnsense.org/manual/firewall.html#processing-order

Die greift noch vor der Reihenfolge innerhalb der dort dargestellten Regeltypen. Somit würde eine "Allow" quick-Regel in den Floating Regeln immer vor jeder eventuellen "Block"-Regel im Interface ziehen, mithin kannst Du in den Interface-Regeln nichts mehr verbieten, was in den Floating-Regeln erlaubt wird. Die Floating-Regel feuert und dann ist der Rest egal. Deswegen beschränke ich Floating-Regeln meist auf eine Interface-Gruppe "LOCAL".

[wirehire]

Die Reihenfolge verstehe ich, nur nicht was du mit Gruppe Local meinst, bei floating.

[meyergru]

Ich lege unter Firewall: Groups eine Interface Gruppe an, die alle lokalen VLAN-Interfaces enthält und nenne sie LOCAL. Die verwende ich dann als Interface in "Firewall: Rules: Floating". Wenn ich später weitere VLANs anlege, muss ich die nur der Gruppe hinzufügen und nicht jeder einzelnen Regel.