Default Deny Route blockt LAN-WlAn-Bridge

[Raketenforscher]

Hallo zusammen,

ich bin neu hier. Und spiele mit der Absicht, von IPfire auf OPNsense umzusteigen. Unter anderem, weil man in OPNsense Netzwerkbrücken per GUI konfigurieren kann.

Meine Absicht ist, die LAN- und WLAN-Schnittstelle als gemeinsame Brücke ansprechen zu können. Meine Config sieht so aus:

Interfaces
-----------
LAN
- enabled
- keine IPv4 Adresse

WLAN
- enabled
- Access Point Mode
- keine IPv4 Adresse

INTERN
- Bridge: LAN+WLAN
- IP-Adresse 192.168.1.1/24

Assignments
- INTERN: bridge0 (LAN+WLAN)
- LAN: re0
- WAN: re1
- WLAN: run0_wlan1


DHCPv4
---------
INTERN
- enable
- Subnet 192.168.1.0/24
- Range 192.168.1.200 bis 192.168.1.250

LAN
- hatte ich während der Einrichtung nachträglich deaktiviert, taucht aber im Menü mittlerweile gar nicht mehr auf. Hö???

Static Mappings
- Notebook, verkabelt:
-- IP 192.168.1.10
-- DNS 192.168.1.2+192.168.1.2 (Pi-Hole, lokaler DNS-Server mit fester IP)
-- Gateway 192.168.1.1

- Tablet, WLAN
-- IP 192.168.1.20
-- Rest wie Notebook


FIREWALL RULES
-------------------
INTERN
1) TCPv4, Source INTERN net, SourcePort *, Dest *, DestPort 80+443, GW *
2) UDPv4, Source INTERN net, SourcePort *, Dest *, DestPort 53, GW *

LAN
nichts, nur die Anti-Lockout Rule

WLAN
nichts

Nun das Problem:

Mit dem Notebook, per LAN-Kabel angeschlossen, komme ich problemlos ins Internet.
Mit dem WLAN-Tablet jedoch nicht. Es erhält die richtige IP-Adresse, auch GW und DNS werden richtig zugewiesen. Auf die FW-GUI kann ich mit dem Tablet über die Adresse 192.168.1.1 (siehe oben, statische Adresse der INTERN-Brücke) zugreifen.

Bei anderen Zielen meldet mir das LOG-File jedoch:
Interface WLAN - Source 192.168.1.20 - Dest 192.168.1.2:53 - Default Deny Route

Die Theorie ist klar: Das Tablet 192.168.1.20 versucht auf den per DHCP zugewiesenen DNS-Server 192.168.1.2 zuzugreifen - und verwendet dafür das Interface WLAN, welches keine Regeln definiert hat, so dass die default deny rule greift.

Aber warum wird hier das WLAN Interface angesprochen, und nicht die Netzwerkbrücke INTERN? Denn genau dazu habe ich ja die Brücke erstellt, damit sich alle Clients im gleichen Subnet befinden und ich hierfür Regeln erstelle, die gleichermaßen für LAN und WLAN gelten?

[JasMan]

Ich selbst habe keinen WLAN Adapter und Bridge an meiner OPNsense im Einsatz, daher nur ein paar Ideen wie Du den Fehler vielleicht finden kannst.

• Welches Interface hast Du denn unter "System: Settings: Administration -> Listen Interfaces" für den WebGUI Access angegeben, wenn Du sowohl aus dem LAN als auch WLAN dran kommst? Wenn dort die Bridge drin steht, ordnet die Sense den Traffic zumindestens hier korrekt zu.
  
• Welcher Adapter wird unter den DHCPv4 Leases bei den beiden Clients angezeigt? LAN bzw. WLAN oder bei beiden die Bridge?
  
• Aktvier doch mal das Logging in der Allow Rule um zu schauen, ob bei erlaubten Paketen über das LAN Interface die Bridge oder das LAN Interface angezeigt wird. Wenn dort das LAN Interface angezeigt wird, ist es korrekt das bei den geblockten Paketen über WLAN das WLAN Interface und nicht die Bridge angezeigt wird.
  
• Richte eine temp. Any-Any Rule auf der Bridge ein um auszuschließen, dass die Regeln aus irgendeinem Grund nicht matchen.
  
• Funktioniert HTTP(s) über das Tablet wenn Du die IPs direkt ansprichst?
  
• Und dann eine Frage die sich mir gerade stellt: wieso zieht hier überhaupt die Firewall Rule? Pi-Hole und Tablet sind doch im selben Subnetz?
  

ERGÄNZUNG: Schau mal unter System: Settings: Tunables. Dort gibt es zwei Optionen die sich so anhören, als könnten sie mit Deinem Problem zu tun haben:

net.link.bridge.pfil_member=1
Set to 0 to disable filtering on the incoming and outgoing member interfaces.

net.link.bridge.pfil_bridge=0
Set to 1 to enable filtering on the bridge interface

[Raketenforscher]

Erst einmal danke für die Antwort.

Welches Interface hast Du denn unter "System: Settings: Administration -> Listen Interfaces" für den WebGUI Access angegeben, wenn Du sowohl aus dem LAN als auch WLAN dran kommst? Wenn dort die Bridge drin steht, ordnet die Sense den Traffic zumindestens hier korrekt zu.

Steht auf "Alle", und das GUI rät mir auch, dies nicht zu ändern.

Welcher Adapter wird unter den DHCPv4 Leases bei den beiden Clients angezeigt? LAN bzw. WLAN oder bei beiden die Bridge?

Ja, jetzt wird's interessant...

WLAN-Clients ohne Reservierung werden als LAN-Lease angezeigt. Klicke ich (immer noch unter DHCP->Leases) auf das Plus-Zeichen neben dem Client und vergebe eine IP außerhalb meiner DHCP Range, bekomme ich eine Fehlermeldung, dass die IP nicht außerhalb der DHCP-Rang liegen darf... Gehe ich hingegen zu DHCP->INTERN und vergebe dort eine IP-Reservierung, kann ich auch eine IP außerhalb der Range angeben. Die reservierten(!) Clients werden dann in den Leases der INTERN Bridge zugeordnet.

Aktvier doch mal das Logging in der Allow Rule um zu schauen, ob bei erlaubten Paketen über das LAN Interface die Bridge oder das LAN Interface angezeigt wird. Wenn dort das LAN Interface angezeigt wird, ist es korrekt das bei den geblockten Paketen über WLAN das WLAN Interface und nicht die Bridge angezeigt wird.

Dank des von dir nachträglich erwähnten Flags in den Tunables wird hier zumindest die Brücke INTERN angezeigt. Auch, wenn ich die allow rule deaktiviere, aber dann greift die deny all rule immer noch - aber jetzt immerhin mit richtigem Interface.

Richte eine temp. Any-Any Rule auf der Bridge ein um auszuschließen, dass die Regeln aus irgendeinem Grund nicht matchen.

Ja, damit klappt's. Aber das ist ja nach meinem Verständnis nicht so wirklich Sinn der Sache, oder?

Der Datenverkehr wird mit USER_RULE und anschließend mit "Let out anything from firewall host itself" protokolliert.

Funktioniert HTTP(s) über das Tablet wenn Du die IPs direkt ansprichst?

Keine Ahnung, ich weiß keine öffentliche IP.

Und dann eine Frage die sich mir gerade stellt: wieso zieht hier überhaupt die Firewall Rule? Pi-Hole und Tablet sind doch im selben Subnetz?

Ja, eben, das ist ja mein Problem. Dafür hab ich ja die Bridge, damit zwischen allen WLAN und LAN Cliennts im gleichen Subnetz keine Regeln greifen. So ist zumindest meine Absicht...

[JasMan]

...

Richte eine temp. Any-Any Rule auf der Bridge ein um auszuschließen, dass die Regeln aus irgendeinem Grund nicht matchen.

Ja, damit klappt's. Aber das ist ja nach meinem Verständnis nicht so wirklich Sinn der Sache, oder?

...

Nein, natürlich nicht. Sowas dient nur als schneller und schmutziger Test um einzugrenzen wo der Fehler liegt. Ich gehe mal davon aus das Du keine Hochsicherheitsumgebung hast. Da kann man sowas mal machen

Wenn also die Any-Any Regel auf dem INTERN Interface für LAN und WLAN Clients funktioniert hat wissen wir nun, dass mindestens die DNS Allow Regel aus irgendeinem Grund nicht für WLAN Clients matcht. Ziel-Adresse und -Dienst sind für LAN und WLAN identisch, somit liegt es vermutlich an der Zuordnung des eingehenden Interfaces oder einer falschen Subnetz Größe, was auch den Routingversuch zwischen LAN und WLAN erklären würde.

• Schau Dir die DNS Regel noch mal an, ob da als Source das richtige Netz drin steht (INTERN net), und ob die Subnetzgrößen im DHCP Server und dem Interface INTERN übereinstimmen.
  
• Setz mal in der DNS Regel als Source ANY, und schau dann ob die WLAN Clients DNS machen können (ping google.de)
• Evtl. hätte man die beiden Optionen bei Tunables vorher setzen müssen, bevor man die Bridge anlegt. In diesem Fall hilft nur Bridge und DHCP löschen, und neu anlegen.
  

[Raketenforscher]

Zwischenzeitlich bin ich dann noch auf weitere Probleme in Zusammenhang mit Google Chromecast gestoßen. Ich wäre nicht verwundert, wenn das alles dieselbe Ursache hat, aber ehrlich gesagt, ist mir die Fehlersuche dann doch zu aufwändig.

Ich bleib dann bei IPFire. Was jetzt keine pauschale Ablehnung gegenüber OPNSense sein soll. Ist sicher ein tolles Produkt, aber die "Kosten-Nutzen-Rechnung" geht für mich nicht auf. Never change a running system.

Danke für die Hilfe.

[monstermania]

Ich bleib dann bei IPFire.

Schade!
Es lohnt sich, sich mit OPNsense zu beschäftigen. Bin selbst von ipfire zu *sense gewechselt und habe es (fast ) nie bereut.
Ja, die Lernkurve ist etwas steiler, aber dafür ist die Flexibilität/Stabilität/Qualität m.E. deutlich besser als bei ipfire.
Probleme kann man lösen, was dann auch generell zum besseren Verständnis beiträgt!

Gruß
Dirk

PS: Bei mir läuft die OPNsense seit rund 2 Jahren mit WLAN/LAN-Bridge. Funktioniert 1a. Auch mit Miracast/Chromecast. 

[JasMan]

Finde ich auch schade aber ich finde es gut, dass Du dein Ergebnis hier postest und den Thread nicht unbeantwortet lässt.

Generell finde ich es immer besser sich mit den Problemen zu beschäftigen und ggf. mit der Hilfe von anderen zu lösen. Denn so bekommt man das Wissen und wird besser.
Wenn man einen Punkt erreicht hat wo man nicht weiter kommt und nix funktioniert wie man es will, muss man sich natürlich überlegen was mehr Sinn macht. 

Auf jeden Fall alles Gute mit der IPFire.