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 setzenGleichzeitig 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.
-
@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ß
-
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.
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.
-
…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.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.)
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.
@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:FPAWas bedeutet das?
-
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.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?
-
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
???
-
@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 0Gruß
pfadmin -
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.
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?
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?