Port/NIC für WLAN auch bei Migration auf andere Ports nicht erreichbar

[bread]

Hi,

aus einem anderen Topic hat sich ein neues Problem herausgestellt.
Also setze ich das Thema quasi heraus, damit kein Chaos entsteht.

Ich habe einen (von 6 vorhandenen) NIC für WLAN eingerichtet (172.16.43.1) und habe ein AP dran hängen.
Das Interface hat DHCP aktiviert.
Es gibt eine Regel von LAN net zu WLAN net.
Die ART Tabelle zeigt das Gerät von GliNet (Brume2).

Problem:
es funktioniert kein Ping auf das WLAN-Interface und somit auch nicht auf den angezeigten AP.
ICMP-Regel ist erstellt und funktioniert.
Die Web GUI ist ebenfalls nicht erreichbar.

1. Schritt:
Also habe ich den AP an einen anderen Port angeschlossen, dort DHCP aktiviert, FW Regel erstellt und zack, es geht alles.

2. Schritt:
Dann habe ich den WLAN-Port quasi migriert. Den Funktionierenden Port in WLAN umbenannt, den alten WLAN in etwas anderes. IPs entsprechend getauscht. DHCP angepasst. States resetet. Und zack, es geht wieder auch an diesem Port nicht.

An FW-Regeln liegt es glaub nicht, da es 1. ja unter einer anderen IP an einem anderen Port funktioniert hat und zweitens habe ich mal alles erlaubt und es ging dennoch nicht.

Also scheint es irgendwie mit diesen Einstellungen für WLAN-Port zusammen zu hängen. Seltsam ist nur, dass die Einstellungen eigentlich völlig gleich zu anderen Ports sind. Es sei denn ich übersehe irgendwas Mysteriöses.

Enable Interface
Prevent removal
Static IPv4
no IPv6
172.16.43.1/24
Gateway disabled

So ist es auch bei allen anderen Ports, nur mit entsprechend anderen IPs

FW Rules bei LAN:
LAN net --> WLAN net

FW Rules bei Floating:
TCP/UDP Private_NetworkDevices (alle, die ins Internet sollen) --> ! Private_Networks - Allow Internet for all internet Devices
ICMP Private_Networks --> any - Allow ICMP

Sonst gibt es bisher keine von mir erstellten Regeln.

Aber erstmal sollte ich langsam ins Bett! 

Danke schon mal!
bread

[W0nderW0lf]

Moin moin,

ich bin kein Internet Firewall crack, aber ich arbeite schon eine weile mit meiner FW.
Dort habe ich ein kleines Sondersetup, weil ich keinen richtigen AP habe. Nur so ein kleines TP-Link AP Ding für unterwegs.

Was ich mich frage... Warum setzt du Floating Rules anstelle von FW Regeln für das WLAN Interface?

Die Floating Rules machen für mich dann sinn, wenn diese Regeln alle Interfaces betreffen, wie z.B. Blacklists.

Deaktiviere doch bitte mal deine Floating Regeln und erstelle in FW WLAN folgende Regeln:

PASS    IPv4+6 TCP    *    *    *    443 (HTTPS)    *    *       Allow HTTPS    
PASS   IPv4+6 TCP    *    *    *    80 (HTTP)    *    *       Allow HTTP    
DROP   IPv4+6 *    *    *    *    *    *    *       

Dann versuch bitte mal eine Seite zu erreichen, ohne die Firewall zu pingen.

edit:

Warum?
FW Rules bei LAN:
LAN net --> WLAN net

LAN darf sowieso alles und überall hin. (Vorausgesetzt die Default allow LAN to any rule ist noch drin)

edit2:

Hast du auch in deinem DNS Dienst (Unbound?) alle Interfaces drin, oder musst du das dort auch händisch hinzufügen?

[bread]

Was ich mich frage... Warum setzt du Floating Rules anstelle von FW Regeln für das WLAN Interface?

Naja, die zwei Floating Rules betreffen die Subnetz übergreifende Devices, die ins Internet dürfen und ICMP von Private_Networks in any. Das ist doch bei Floating sinnvoll. Da gibt es keine Regel nur für WLAN-Interface (siehe oben).

LAN darf sowieso alles und überall hin. (Vorausgesetzt die Default allow LAN to any rule ist noch drin)

Die habe ich am Anfang rausgelöscht.

Und ich meine, dass es eben nicht an den FW-Regeln liegt. Es funktioniert ja alles, wie ich beschrieben habe, wenn ich den AP ans andere Interface hänge und entsprechende FW Rule erstelle. Wenn ich dann aber dorthin die IP und den Namen von dem nicht funktionierenden WLAN-Interface migriere, dann gehts auch da plötzlich nicht mehr. Es hat also irgendwas mit den Porteinstellungen zu tun.

Hast du auch in deinem DNS Dienst (Unbound?) alle Interfaces drin, oder musst du das dort auch händisch hinzufügen?

Ja, sind alle drin.

Edit:
Und bitte nicht verwechseln, es geht nicht um den WLAN auf der Firewall, sondern um ein Interface, ein NIC von der Firewall, welches den Namen WLAN trägt, um das WLAN-Subnet zu trennen.

[bread]

Ich meine jetzt noch eine Besonderheit festgestellt zu haben.

LAN-Port hat 172.16.42.1, dort funktioniert ja alles. Ich kann auch den Port selber aus dem Client am LAN heraus anpingen.
ZWEI andere Ports (nicht nur einer, wie ich dachte) können nicht mal angepingt werden und sind beide Ports im 172er-Bereich: 172.16.63.1 und 172.16.250.1

Irgendwie gibt es ein Problem mit dem 172er-Bereich außer dem LAN, über den ich ja auch die Firewall selbst eben unter der IP 172.16.42.1 erreiche.

Und ich habe auch eine Bestätigung dafür. Wechsel ich den Port mit dem 172er-Bereich auf 192er, schon kann ich ihn anpingen. Also es ist definitiv ein Problem mit dem 172er-Bereich (außer LAN).

[Patrick M. Hausen]

Und die Netzmasken/Prefixlängen sind überall /24 und nicht etwa /16?

[bread]

Und die Netzmasken/Prefixlängen sind überall /24 und nicht etwa /16?

jipp! Sind alle /24

Die Interfaces für Private_Networks habe ich mittlerweile als ports eingebunden also opt1, opt2 etc.