Verständnisfrage zu den Rules und Interfaces



  • Hallo,

    es ist doch richtig, dass die Rules der Priorität nach zunächst von Interface-Gruppen, dann von Bridges und zuletzt von den Interfaces selbst abgearbeitet werden?

    Mein Setup:
    1x LAN
    1x WLAN
    1x Bridge (LAN+WLAN, inkl. DHCP)
    1x VPN Server
    1x Gruppe (Bridge+VPN)

    Problem:
    Wenn ich bei WLAN keine Pass Rule für Bridge_net => Bridge_net anlege, kann ich nicht auf die LAN Geräte zugreifen, warum das? Meinem Verständnis nach sollte doch die o.g. Regel alleine bei der Gruppe schon ausreichend sein, um nicht noch für jedes einzelne Interface eine solche anzulegen oder habe ich einen Denkfehler drin?

    Danke schon mal im vorab!



  • Hallo,

    habe keine Erfahrung mit einer solchen Konstellation, ist also nur eine Vermutung:
    System > Advanced > System Tunables
    "net.link.bridge.pfil_bridge" auf 1 setzen

    Gleichzeitig könnte "net.link.bridge.pfil_member" auf 0 gesetzt werden, wenn gewünscht.

    Die erste Einstellung bewirkt, dass die Regeln auf der Bridge angewandt werden. Nachdem die Bridge Mitglied der Gruppe ist, könnte es  damit so funktionieren, wie du es dir vorstellst.



  • Danke, ich werde es auf jeden Fall ausprobieren. Kannst du vllt. auch erklären welche Regeln der Priorität nach (Gruppen > Bridges > Interfaces) und welche bevorzugt auf den jeweiligen Interfaces abgearbeitet werden - evtl. die Regeln, die das interne Netz betreffen?

    Ich frage deshalb, weil ich eigentlich davon ausgegangen war, dass die Priorität (Gruppen > Bridges > Interfaces) wirklich greift und deswegen einige Ideen nicht umgesetzt habe. Wenn aber in Wirklichkeit die Regeln auf den jeweiligen Interfaces, welche bspw. das interne Netz betreffen, eine noch höhere Priorität besitzen, dann könnte ich das evtl. sogar anderweitig ausnutzen.


  • Moderator

    @un1que: Nein, im Normalfall hast du recht, dass die Gruppierungen höhere Priorität haben, allerdings weiß ich das akut gerade von einer Bridge nicht (vermeide ich überall) und kann hier nur von anderen Gruppen sprechen. Normalerweise ist es

    Floating > Gruppen > Einzelinterfaces

    wobei aber die Vergabe der Regeln an den einzelnen Interfaces meist sauberer/eindeutiger ist, als bei den Gruppen bzw. man dort auf mehrere Streufaktoren Rücksicht nehmen muss. Bestes Beispiel ist der OpenVPN Reiter (Gruppe) vs. OVPN Interfaces per Zuweisung einzeln verfügbar machen und konfigurieren. Hier kann bspw. der Traffic wesentlich sinnvoller gefiltert werden als auf den OpenVPN Gruppen-Tab, gerade wenn gleiche/ähnliche Quellen/Ziele im Spiel sind.

    Gruß



  • @un1que:

    Kannst du vllt. auch erklären welche Regeln der Priorität nach (Gruppen > Bridges > Interfaces) abgearbeitet werden

    Kann ich leider nicht. Gemäß der Doc (https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order) ist es eben so, wie Jens beschrieben hat. Eine Bridge kommt da nicht vor. Regeln auf der Bridge werden überhaupt nur berücksichtigt, wenn "net.link.bridge.pfil_bridge" auf 1 steht, vernünftigerweise setzt man in diesem Fall "net.link.bridge.pfil_member" auf 0, dann stellt sich die Frage gar nicht. Dann hat vermutlich eine Bridge die gleiche Priorität wie ein Interface und beides kann dann ohnehin nicht zutreffen.

    @un1que:

    Wenn aber in Wirklichkeit die Regeln auf den jeweiligen Interfaces, welche bspw. das interne Netz betreffen, eine noch höhere Priorität besitzen, dann könnte ich das evtl. sogar anderweitig ausnutzen.

    Ich weiß nicht, was du hier mit "interne Netze betreffend" ausdrücken willst. Welches Netz eine Regel betrifft, hat keine Auswirkung auf die Priorität der Anwendung der Regel.
    Dass die Regeln auf den jeweiligen Tabs immer von oben nach unten auf Zutreffen überprüft werden und dass beim ersten Zutreffen diese Regel angewandt und die Überprüfung beendet wird, weitere Regeln also keine Anwendung finden, ist dir doch klar, oder?
    Die Prio ist also
    @JeGr:

    Floating > Gruppen > Einzelinterfaces

    und jeweils von oben nach unten.

    Ich weiß nicht, was dein Ziel ist, aber vielleicht ist es eine Überlegung wert, auf die genannten Tunables zu verzichten und stattdessen die Interfaces der Bridge, die dieselben Regeln erhalten sollen auch in eine Gruppe aufzunehmen und die Regeln da zu setzen.



  • @viragomann:

    …Eine Bridge kommt da nicht vor...

    Vermutlich, weil eine Bridge wie ein Interface angesehen wird. Es ersetzt diese ja, wenn in den tunables entsprechend konfiguriert.



  • @JeGr:
    Ja, verstehe ich, allerdings kann ich leider nicht ohne diese Bridge, weil ich LAN und WLAN zusammenfassen muss. Bei WLAN hängt halt ein Unifi AP dran, welcher außerdem per VLAN ein Gastnetz aufspannt, sonst hätte ich ihn vermutlich einfach an meinen (unmanaged) Switch gehängt.
    *edit: Außerdem sollen bei diesem Setup alle LAN und WLAN Geräte im gleichen 24er Subnetz liegen.

    Bei OpenVPN muss ich dir allerdings Recht geben, das mache ich dann auch genau so mit den jeweiligen Interfaces und das eigentliche OpenVPN Interface ist leer.

    @viragomann:
    Hmm, ok… komisch. Ich habe bisher immer die Bridge als "Haupt-"Interface genutzt und bisher immer nur dort alle Regeln angelegt, welche auch brav angewendet wurden. Bei WLAN und LAN war halt noch jeweils eine allow-any Regel drin.

    @viragomann:

    Ich weiß nicht, was du hier mit "interne Netze betreffend" ausdrücken willst.

    Hatte einen Denkfehler drin, vergiss diese Frage. (Ja, wie die Regeln an sich funktionieren, ist mir bewusst.)

    @viragomann:

    Ich weiß nicht, was dein Ziel ist, aber vielleicht ist es eine Überlegung wert, auf die genannten Tunables zu verzichten und stattdessen die Interfaces der Bridge, die dieselben Regeln erhalten sollen auch in eine Gruppe aufzunehmen und die Regeln da zu setzen.

    Also, mein Hauptanliegen ist folgendes: bestimmte Internetseiten sollen über gewisse Gateways laufen. Dieselben Regeln sollen auch für Geräte gelten, welche per OpenVPN Server mit der Sense verbunden sind. Bisher habe ich die Bridge und den OpenVPN Server zu einer Gruppe zusammengefasst, was sich vermutlich als nicht korrekt herausgestellt hat.

    1. Die beste Vorgehensweise wäre wohl nun LAN, WLAN (statt Bridge) und OpenVPN Server zu einer Gruppe zusammenzufassen, richtig?
    In dem Fall würde dann absolut alles über die Gruppe laufen und ich müsste nur diese verwalten, soweit auch richtig?

    2. Mein Heimnetz besteht aus LAN und WLAN (bei beiden steht die Interface-IP jeweils auf "none") und nur die Bridge hat eine IP + macht den DHCP Server. Kann ich dann bei der Gruppe eine Pass Rule Bridge_net => Bridge_net anlegen (quasi die Anti-Lockout Rule, welche dann auf dem LAN Interface ja nicht mehr greifen dürfte), ich würde meinen schon oder?

    So wäre die Bridge komplett aus dem Spiel raus und ich hätte nur die eine Gruppe, welche also die oberste Priorität über alle Interfaces (außer Floating, natürlich) hat und wo ich alles verwalten kann.



  • Ich würde es auch so sehen, aber wie ganz oben erwähnt, habe ich Null Erfahrung damit. Ich hatte noch nie eine Bridge auf der pfSense im Produktiv-Einsatz.

    Wenn das ohnehin nur ein Heimnetz ist, teste es einfach. Zur Not kannst du ja eh über die Konsole wieder zurückrudern, wenn du Zugang zur Konsole hast, natürlich.

    @un1que:

    @viragomann:
    Hmm, ok… komisch. Ich habe bisher immer die Bridge als "Haupt-"Interface genutzt und bisher immer nur dort alle Regeln angelegt, welche auch brav angewendet wurden. Bei WLAN und LAN war halt noch jeweils eine allow-any Regel drin.

    Dafür gilt Gleiches. Keine Erfahrung, ich kenne das nur aus der Theorie.

    Grüße



  • Dann werde ich es mal testen, muss zuvor aber ein wenig aufräumen ::)

    Was meinst du mit "über die Konsole wieder zurückrudern", bzw. wie genau stelle ich es dann an, falls das mal schief läuft und ich nicht mehr auf die Sense komme?



  • Wenn du auf die Konsole kommst, da kannst du mit Menüpunkt 15 frühere Konfigurationen wiederherstellen. Es werden mehrere angeboten.



  • Danke! Dann werde ich es wohl bis Ende der Woche ausprobiert haben und gebe hier noch eine kurze Rückmeldung ab.



  • Also ich wollte es heute noch hinter mir haben und habe mich einfach mal dran gesetzt. Zunächst mal - wie zu erwarten war - ist mal was schief gelaufen und ich wurde ausgesperrt. Konfig wiederherstellen hat nicht funktioniert und ich musste erstmal mit der Firewall ein wenig kämpfen.

    Der Grund war wohl: ich habe, wie angedacht, die Gruppe - bestehend aus LAN, WLAN und OpenVPN - erstellt und das reichte schon. Aufgrund der Tatsache, dass die Bridge nirgendwo aufgeführt war bzw. keine Regeln enthielt, konnte ich nirgendwo hin.
    Später habe ich dort die Regel "Bridge_net => Bridge_net" erstellt und konnte mich zunächst mal im LAN/WLAN bewegen, aber Internet funktionierte nicht. Erst als ich die Bridge zur Gruppe hinzugefügt habe, ging auf einmal das Internet und dann konnte ich auch schon alle "Bridge_net => Bridge_net" auf den Interfaces LAN, WLAN, Bridge deaktivieren, es reichte wohl diese auf dem Gruppen Interface zu haben.

    Nun denn, kann mir jemand das Verhalten erklären?

    Mittlerweile habe ich nur noch auf jedem der LAN, WLAN und Bridge Interface eine deny-any Rule eingerichtet und es scheint soweit zu laufen mit der Gruppe, bestehend aus all diesen Interfaces + VPN Server. Werde wohl morgen noch versuchen Bridge bzw. LAN/WLAN aus der Gruppe zu nehmen und schaue dann, wann mir der Zugriff verweigert wird.

    Nur tauchen bei mir jetzt in regelmäßigen Abständen folgende Log Ereignisse auf:
    Default deny rule IPv4 lo0 127.0.0.1:XXX => 127.0.0.1:6379 TCP:FPA
    Default deny rule IPv4 Bridge [IP_des_Bridge_Interfaces]:443 => [IP_meines_MacBooks_(von welchem ich auf die Sense zugreife)]:XXX TCP:FPA

    Was bedeutet das?



  • @un1que:

    TCP:FPA
    Was bedeutet das?

    a) Du suchst nicht gern selbst
    b) It's out-of-state traffic, either from expired states or from asymmetric routing.

    @un1que:

    Mittlerweile habe ich nur noch auf jedem der LAN, WLAN und Bridge Interface eine deny-any Rule eingerichtet

    What?
    Was hast Du denn bei  System / Advanced / System Tunables unter

    |   net.link.bridge.pfil_member  | Set to 0 to disable filtering on the incoming and outgoing member interfaces  | default (1) |
    |   net.link.bridge.pfil_bridge  | Set to 1 to enable filtering on the bridge interface | default (0) |

    eingestellt?



  • @un1que:

    Der Grund war wohl: ich habe, wie angedacht, die Gruppe - bestehend aus LAN, WLAN und OpenVPN - erstellt und das reichte schon. Aufgrund der Tatsache, dass die Bridge nirgendwo aufgeführt war bzw. keine Regeln enthielt, konnte ich nirgendwo hin.

    Also wenn net.link.bridge.pfil_member auf 1 steht (default), wie besprochen, hätte ich das nicht erwartet.

    Und warum diese Umstellung nun zu einem asymmetrischen Routing führt, kann ich mir auch nicht erklären, schon gar nicht
    @un1que:

    Default deny rule IPv4 lo0 127.0.0.1:XXX => 127.0.0.1:6379 TCP:FPA

    ???



  • @un1que:

    @viragomann:
    Hmm, ok… komisch. Ich habe bisher immer die Bridge als "Haupt-"Interface genutzt und bisher immer nur dort alle Regeln angelegt, welche auch brav angewendet wurden. Bei WLAN und LAN war halt noch jeweils eine allow-any Regel drin.

    Dafür gilt Gleiches. Keine Erfahrung, ich kenne das nur aus der Theorie.

    Grüße

    Hi,
    aufgeschreckt habe ich bei mir gleich nachgesehen und ich kann das bestätigen. Ich habe ein "Management" VLAN auf allen Interfaces angelegt und diese per Bridge  zusammengeschalten. Nur die Bridge hat eine IP und Regeln.

    net.link.bridge.pfil_member  1
    net.link.bridge.pfil_bridge  0

    Gruß
    pfadmin



  • @viragomann:

    @un1que:

    Der Grund war wohl: ich habe, wie angedacht, die Gruppe - bestehend aus LAN, WLAN und OpenVPN - erstellt und das reichte schon. Aufgrund der Tatsache, dass die Bridge nirgendwo aufgeführt war bzw. keine Regeln enthielt, konnte ich nirgendwo hin.

    Also wenn net.link.bridge.pfil_member auf 1 steht (default), wie besprochen, hätte ich das nicht erwartet.

    Das Problem ist halt, dass es wirklich so ist. Die beiden tunables haben nach wie vor die default Werte: member 1, bridge 0.

    @viragomann:

    Und warum diese Umstellung nun zu einem asymmetrischen Routing führt, kann ich mir auch nicht erklären, schon gar nicht
    @un1que:

    Default deny rule IPv4 lo0 127.0.0.1:XXX => 127.0.0.1:6379 TCP:FPA

    ???

    Kann ich irgendwie herausfinden, wie es zustande kommt?

    @jahonix:

    @un1que:

    TCP:FPA
    Was bedeutet das?

    a) Du suchst nicht gern selbst
    b) It's out-of-state traffic, either from expired states or from asymmetric routing.

    zu a) Nein, ich versuche immer erst selbst eine Lösung zu finden und erst dann nachzufragen, aber an der Stelle war ich schon recht müde (u.a. weil ich viel Zeit damit verbrachte die Aussperrung seitens der Sense zu umgehen) und habe die Frage einfach in mein Posting mit den komischen Erkenntnissen reingenommen.
    zu b) Danke, schaue ich mir an.

    Die Frage zu tunables habe ich weiter oben beantwortet.



  • Btw. ich habe gerade nochmal in die Logs geschaut und glaube, dass die 2 Block-Meldungen seit 12 Uhr nicht mehr kommen (davor im Minutentakt), nachdem ich einiges noch hier und da nachgebessert habe (evtl. habe ich gestern auch einfach was nicht ganz korrekt eingerichtet). Wenn meinerseits nichts mehr dazu kommt, dann hat es sich erledigt.

    Dann bliebe nur noch die andere Frage mit der Bridge offen.



  • Hast du deine Kiste einfach mal rebooted? Das soll ja manchmal Wunder bewirken (gerade wenn es um Interfaces und VLANs geht).



  • Sorry für die sehr sehr späte Antwort. Ich hatte privat viel zu tun und habe nur nebenbei ganz feine Sachen ausgebessert, da blieb einfach keine Zeit mehr übrig, um mich intensiv noch einmal reinzuhängen.

    Also, wie ich bereits sagte, diese ganzen Probleme mit dem asymmetrischem Routing etc. treten nicht mehr auf. Es lag wohl an der Falschkonfiguration der OpenVPN Verbindungen, welche ich ebenfalls etwas umgestellt habe, als ich zeitgleich die komplette Neueinrichtung der Interfaces vornahm.

    Nun, die Frage bleibt also weiterhin im Raum stehen, wieso die Bridge unbedingt zur Gruppe hinzugefügt werden muss (und es nicht ausreicht einfach LAN, WLAN hinzuzufügen), wenn doch unter Tunables member=1 und bridge=0 eingestellt sind? Ich habe gerade noch einmal die Bridge aus der Gruppe (wo all Regeln definiert sind) entfernt und wurde überall ausgesperrt (da bei Bridge nur eine einzige Block-Regel eingerichtet ist) - keines meiner LAN und WLAN Geräte konnte irgendeine Verbindung herstellen.
    Habe dann auch mal versucht nur die Bridge drin zu lassen und LAN/WLAN aus der Gruppe ausgeschlossen. Alle Verbindungen funktionierten scheinbar ohne Probleme, außer dass ich wohl aus dem WLAN keinen Zugriff auf LAN-Geräte hatte.

    @jahonix: auch ein Neustart brachte nix. Übrigens das Raus- und Reinnehmen der Bridge in die Gruppe hat auch ohne Neustart erfolgreich (naja, wie man's nimmt :-) funktioniert. Sofort nach dem abspeichern, hatte ich keinen Zugang zu nichts und nach dem Hinzufügen der Bridge zur Gruppe - wieder überall hin.
    Dank dem OpenVPN Tunnel, der auch zur Gruppe gehört, ging diesmal das Zurücksetzen zum funktionierenden Zustand recht schnell und ich musste nicht ca. 1h gegen mit der Firewall kämpfen :)

    Wird also wohl ein Bug sein? Die Frage ist nur, ob es ein Bug seit der 2.4 Version ist oder diese Problematik bereits seit 2.3 unentdeckt bleibt?



  • Hat keiner mehr etwas zum Thema beizutragen? :-\

    Ich habe es mir noch einmal kurz angeschaut und folgendes unter der Bridge-Info gefunden:

    NOTE: Only one interface on a bridge should have an IP address! Do not add multiple IP addresses in the same subnet on different bridge member interfaces. Other interfaces on the bridge should remain with an IP type of None.

    Vllt. kommt mein Problem daher, dass ich sowohl LAN als auch WLAN auf none stehen habe und eben der BRIDGE eine IP + entsprechendes Subnet zugewiesen habe?



  • @un1que:

    …wieso die Bridge unbedingt zur Gruppe hinzugefügt werden muss (und es nicht ausreicht einfach LAN, WLAN hinzuzufügen), wenn doch unter Tunables member=1 und bridge=0 eingestellt sind?

    Es ist schon spät … aber je länger ich drüber nachdenke, desto komischer finde ich Dein Setup.

    Du willst doch zur besseren Übersicht die Regeln in nur einer Gruppe verwalten, richtig?
    Warum stehen dann die Tuneables auf "filter member" und nicht "filter bridge"? Damit hättest Du schon mal nur ein Ruleset für das lokale Gedöns.
    Ob man dann die Bridge mit dem VPN Interface in einer Gruppe zusammen regeln kann habe ich nie probiert; auch, weil ich das so nie machen würde.

    Bringe doch erst einmal die Bridge alleine zum Laufen. Und zwar, indem Du auf der Bridge und nicht den einzelnen Interfaces regelst.
    Erst wenn das geht bastele eine Gruppe und probiere weiter.



  • Nene, ich habe ja jetzt bereits eine Gruppe erstellt und verwalte dort all meine Regeln für LAN, WLAN und OpenVPN Server - alles so, wie ich es mir vorgestellt habe. Also Hauptziel ist erreicht, jetzt fehlt nur das Feintuning.
    Die Sache ist halt, ich verstehe nicht warum ich überall die Bridge mit reinnehmen muss, damit alles so funktioniert wie es soll und es nicht einfach ausreicht LAN + WLAN zu nehmen. Denn wenn ich jetzt die Bridge bei der Gruppe weglassen würde, wäre ich ausgesperrt und da hilft auch die Anti-Lockout Rule des LAN Interfaces kein Stück. Genauso (wenn ich mich recht erinnere) muss ich bei der Gruppe bspw. eine Regel "pass Bridge_net Bridge_net" erstellen, damit die Kommunikation zwischen den LAN und WLAN Gerätschaften stattfinden kann; evtl. auch um nicht ausgesperrt zu werden (bin mir aber nicht mehr sicher).

    @jahonix:

    Du willst doch zur besseren Übersicht die Regeln in nur einer Gruppe verwalten, richtig?
    Warum stehen dann die Tuneables auf "filter member" und nicht "filter bridge"? Damit hättest Du schon mal nur ein Ruleset für das lokale Gedöns.

    Nicht nur zur besseren Übersicht, sondern auch einfacheren Verwaltung über mehrere Interfaces hinweg.
    Das ist es ja - die Tunables stehen auf default, aber es funktioniert trotzdem, nur eben nicht so, wie es theoretisch sollte (trotz "filter member" wird die Bridge bevorzugt behandelt) und das finde ich eben sehr komisch :-\ Die einzige Erklärung, die ich jetzt habe: bei mir hat die Bridge eine IP mit Subnetz erhalten und nicht eines der dort zugeordneten Interfaces. Kann es das sein?

    @jahonix:

    Ob man dann die Bridge mit dem VPN Interface in einer Gruppe zusammen regeln kann habe ich nie probiert; auch, weil ich das so nie machen würde.

    Ja, das geht, warum sollte es nicht? Ich nutze quasi ein DauerVPN auf allen meinen (mobilen) Geräten und bin so auch von unterwegs mit dem heimischen Netzwerk verbunden - zum einen zwecks Datenaustausch mit dem NAS, zum anderen als eine Sicherheitsmaßnahme für ungeschützte WLAN Netzwerke. Dabei habe ich viel mit dem policy based routing zu tun. Darum will ich nicht 2x die gleichen Regeln bei der Bridge und beim OpenVPN Server festlegen bzw. bei jeder neuen Regel / Änderung daran denken das gleiche beim OpenVPN Interface zu wiederholen. Darum halt die Lösung mit der Gruppe.

    Früher, wo ich nur die Bridge für die Verwaltung der Regeln genutzt habe, lief bei mir auch alles über die Bridge und nicht auf den einzelnen Interfaces, trotz "filter member"-Tunables (also wirklich komisch das Ganze).



  • @un1que:

    Nicht nur zur besseren Übersicht, sondern auch einfacheren Verwaltung über mehrere Interfaces hinweg.

    ??
    Ich finde etwas einfacher verwaltbar, wenn es übersichtlich ist…

    @un1que:

    Das ist es ja - die Tunables stehen auf default, aber es funktioniert trotzdem, nur eben nicht so, wie es theoretisch sollte (trotz "filter member" wird die Bridge bevorzugt behandelt) und das finde ich eben sehr komisch :-\ Die einzige Erklärung, die ich jetzt habe: bei mir hat die Bridge eine IP mit Subnetz erhalten und nicht eines der dort zugeordneten Interfaces. Kann es das sein?

    Ich glaube nicht, denn so sollte die Bridge konfiguriert werden.
    Nur verstehe ich immer noch nicht, warum du nicht auf der Bridge filterst sondern auf den member interfaces. Halte ich für unlogisch, unübersichtlich und somit schlechter zu verwalten. In dienem Szenario brauchst du auch keine unterschiedlichen Filter auf den Interfaces.

    Und dann ist auch dein Problem kein Problem mehr sondern höchstens eine Bemerkung…



  • @jahonix:

    Ich glaube nicht, denn so sollte die Bridge konfiguriert werden.
    Nur verstehe ich immer noch nicht, warum du nicht auf der Bridge filterst sondern auf den member interfaces. Halte ich für unlogisch, unübersichtlich und somit schlechter zu verwalten. In dienem Szenario brauchst du auch keine unterschiedlichen Filter auf den Interfaces.

    Und dann ist auch dein Problem kein Problem mehr sondern höchstens eine Bemerkung…

    Wie kommst du denn darauf, dass ich auf den Member Interfaces filtere? Ich habe doch direkt im ersten Satz gesagt, dass ich bereits alles, so wie gewünscht, eingerichtet habe und es über die Gruppe geregelt wird.

    Ich frage mal anders, wenn es ja jetzt so komisch läuft, wäre es dann "richtiger" unter tunables auf "filter bridge" zu setzen und einfach überall die Bridge, statt den LAN + WLAN Interfaces, zu definieren?



  • @un1que:

    Wie kommst du denn darauf, dass ich auf den Member Interfaces filtere?

    vielleicht deshalb:
    @un1que:

    … Gruppe erstellt und verwalte dort all meine Regeln für LAN, WLAN und OpenVPN Server ...
    ... warum ich überall die Bridge mit reinnehmen muss, damit alles so funktioniert wie es soll und es nicht einfach ausreicht LAN + WLAN zu nehmen.

    denn das klingt jetzt genau anders herum.

    @un1que:

    wäre es dann "richtiger" unter tunables auf "filter bridge" zu setzen und einfach überall die Bridge, statt den LAN + WLAN Interfaces, zu definieren?

    ja.
    Alles andere sind eher Ausnahmefälle von Sonderfällen.

    Aber wie passt denn die letzte Aussage jetzt wieder zu "wie kommst Du darauf, dass …" von oben?



  • Ok, ich sehe schon… ich habe mich wohl etwas unkorrekt ausgedrückt und deswegen kam es zu einem Missverständnis, sodass wir nun etwas aneinander vorbei reden. Ich versuche es noch einmal zu erklären, Schritt für Schritt:

    1. unter Tunables steht das "filter member" auf 1 und "filter bridge" auf 0
    2. ich erstelle eine Gruppe und dort müsste ich ja Interfaces definieren, welche zu dieser Gruppe zusammengefasst werden
    3. laut Punkt 1 müsste ich für die Gruppe ja LAN, WLAN und oVPN_Server Interfaces definieren => aber es geht nicht, ich werde ausgesperrt (da auf den LAN und WLAN Interfaces keine Regeln vorhanden sind und die LAN Anti-Lockout-Rule - warum auch immer - nicht greift; wobei ich es auch mit pass-any versucht hatte)
    4. erst, als ich die Bridge (ich habe bisher immer dort alle meine Regeln erstellt und verwaltet) in die Gruppe aufnahm, lief alles nach Plan - ich konnte wieder auf die Sense zugreifen und es wurden alle unter dem Bridge Interface angelegte Regeln angewandt
    5. danach habe ich alle Regeln aus dem Bridge Interface in die Gruppe übertragen und soweit funktionierte nach wie vor alles wunderbar
    6. nahm ich nun die Bridge aus der Gruppe raus (LAN und WLAN blieben drin), wurde ich wieder ausgesperrt; trotz Punkt 1

    Genau das war bisher mein Problem, welches ich absolut nicht nachvollziehen kann. Denn nach meinem Verständnis sorgt das "filter member" 1 eben dafür, dass die Regeln der einzelnen Interfaces (und nicht der Bridge) bzw. die Interfaces selbst bevorzugt behandelt werden sollen?! Dass ich es mit "filter member" 0 + "filter bridge" 1 und Löschen der LAN und WLAN Interfaces aus der Gruppe in die richtige Wege leiten kann, habe ich mittlerweile verstanden und werde es bei Gelegenheit umsetzen.