6
Acces Point durch aktivieren des Captive Portals vom LAN aus nicht mehr erreichbar.
Hallo,
mein Netzwerk sieht mittlerweile wie folgt aus:
Beide Subnetze haben Zugang zum Internet. Das LAN-Subnet darf alles, und soll auch Zugriff auf das Gasthaus-Subnet haben. Das Gasthaus-Subnet soll jedoch keinen Zugriff auf das LAN haben.
Soweit funktioniert alles. Aber sobald ich CP aktiviere habe ich vom LAN-Subnet keinen Zugriff mehr auf den Acces Point 172.18.9.2 . Ohne CP funktioniert der Zugriff auf den AP aus dem LAN-Subnet einwandfrei.
Firewall-Regeln:
Für das WAN-Interface habe ich keine Regel erstellt.
Muss ich das CP noch irgendwie zusätzlich in den Firewall-Regeln berücksichtigen damit der Zugriff auf den AP funktioniert?
Zwei zusätzliche Fragen zum Acces Point (TP-Link wr1043nd mit dd-wrt Firmware):
Wie kann ich das Web-Interface des AP für WLAN sperren?
Wie muss ich den AP konfigurieren damit die Benutzer des CP sich gegenseitig nicht sehen, oder ist das ohnehin der Fall?
Grüße,
Reitzi
mein Netzwerk sieht mittlerweile wie folgt aus:
Beide Subnetze haben Zugang zum Internet. Das LAN-Subnet darf alles, und soll auch Zugriff auf das Gasthaus-Subnet haben. Das Gasthaus-Subnet soll jedoch keinen Zugriff auf das LAN haben.
Soweit funktioniert alles. Aber sobald ich CP aktiviere habe ich vom LAN-Subnet keinen Zugriff mehr auf den Acces Point 172.18.9.2 . Ohne CP funktioniert der Zugriff auf den AP aus dem LAN-Subnet einwandfrei.
Firewall-Regeln:
Für das WAN-Interface habe ich keine Regel erstellt.
Muss ich das CP noch irgendwie zusätzlich in den Firewall-Regeln berücksichtigen damit der Zugriff auf den AP funktioniert?
Zwei zusätzliche Fragen zum Acces Point (TP-Link wr1043nd mit dd-wrt Firmware):
Wie kann ich das Web-Interface des AP für WLAN sperren?
Wie muss ich den AP konfigurieren damit die Benutzer des CP sich gegenseitig nicht sehen, oder ist das ohnehin der Fall?
Grüße,
Reitzi
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 181388
Url: https://administrator.de/forum/acces-point-durch-aktivieren-des-captive-portals-vom-lan-aus-nicht-mehr-erreichbar-181388.html
Ausgedruckt am: 23.04.2025 um 09:04 Uhr
6 Kommentare
Neuester Kommentar
Ja, das ist ein logisches Verhalten wenn du mal etwas nachdenkst... 
Sobald du das CP aktivierst, kommt keiner mehr ohne Authentisierung durch das CP so wie es auch sein soll !
Natürlich auch nicht dein AP mit der 172.18.9.2 ! Es sei denn er kann selber das Passwort oder Voucher ID eintragen um das zu tun. Der AP ist ja aus Sicht des CP nichts anderes als ein Client dort wie alle anderen auch.
Wenn du den nun aus deinem 10er LAN per HTTP ansprichst sendet der auch brav die Antwortpakete ins 10er LAN zurück. Sobald diese Pakete aber am CP ankommen sagt das erstmal HALT, Du kommst hier nicht rein ! Erstmal authentisieren !!!
Der arme AP hat aber ja nun keine Hände das er deine Voucher ID oder Passwort automatisch in das Webportal eintippen kann. (So ein AP muss erst noch erfunden werden...)
Folglich ist also alles geblockt. Logisch oder ? Genau so soll ein CP ja auch arbeiten.
Die Lösung ist aber kinderleicht:
Du trägst in die CP Ausnahmeregelung auf der CP Konfig Seite einfach die MAC Adresse des Accesspoints ein damit dieser ohne Authentisierung passieren kann !
"Pass through Mac Adress" ist das Zauberwort dazu :
http://doc.m0n0.ch/handbook/captiveportal.html#id11640226
(Nicht die IP, denn wenn die sich ändert hast du das gleiche Problem oder wenn jemand die sich konfiguriert kommt er ohne Authentisierung durchs CP !! Eine Mac Adresse ist für Computer Laien schwerer zu clonen.)
Die Mac des APs ist meistens aufgedruckt. Wenn nicht pings du ihn einmal an und gibst dann arp -a in der Eingabeaufforderung ein um sie zu sehen.
Damit klappts dann auch mit dem Konfig Zugang auf den AP UND aktivem CP !
Im AP trägst aktivierst du das Feature "Wireless Isolation" im WLAN Setup. Damit ist dann innerhalb des WLANs keine any zu any Kommunikation mehr möglich ! Das ist ein AP Feature was die meisten APs heute supporten !
Das Web Interface des AP zu sperren machst du in den Security Settings des AP. Dort ist in der Regel immer ein Haken über den man den Zugriff auf das WebGUI aus dem WLAN verhindern kann. Das solltest du zwingend aktivieren.
WebGui Zugriff auf den AP sollte nur über das LAN möglich sein. Ein entsprechend sicheres Passwort sollte selbstverständlich sein.
Sobald du das CP aktivierst, kommt keiner mehr ohne Authentisierung durch das CP so wie es auch sein soll !
Natürlich auch nicht dein AP mit der 172.18.9.2 ! Es sei denn er kann selber das Passwort oder Voucher ID eintragen um das zu tun. Der AP ist ja aus Sicht des CP nichts anderes als ein Client dort wie alle anderen auch.
Wenn du den nun aus deinem 10er LAN per HTTP ansprichst sendet der auch brav die Antwortpakete ins 10er LAN zurück. Sobald diese Pakete aber am CP ankommen sagt das erstmal HALT, Du kommst hier nicht rein ! Erstmal authentisieren !!!
Der arme AP hat aber ja nun keine Hände das er deine Voucher ID oder Passwort automatisch in das Webportal eintippen kann. (So ein AP muss erst noch erfunden werden...)
Folglich ist also alles geblockt. Logisch oder ? Genau so soll ein CP ja auch arbeiten.
Die Lösung ist aber kinderleicht:
Du trägst in die CP Ausnahmeregelung auf der CP Konfig Seite einfach die MAC Adresse des Accesspoints ein damit dieser ohne Authentisierung passieren kann !
"Pass through Mac Adress" ist das Zauberwort dazu :
http://doc.m0n0.ch/handbook/captiveportal.html#id11640226
(Nicht die IP, denn wenn die sich ändert hast du das gleiche Problem oder wenn jemand die sich konfiguriert kommt er ohne Authentisierung durchs CP !! Eine Mac Adresse ist für Computer Laien schwerer zu clonen.)
Die Mac des APs ist meistens aufgedruckt. Wenn nicht pings du ihn einmal an und gibst dann arp -a in der Eingabeaufforderung ein um sie zu sehen.
Damit klappts dann auch mit dem Konfig Zugang auf den AP UND aktivem CP !
Im AP trägst aktivierst du das Feature "Wireless Isolation" im WLAN Setup. Damit ist dann innerhalb des WLANs keine any zu any Kommunikation mehr möglich ! Das ist ein AP Feature was die meisten APs heute supporten !
Das Web Interface des AP zu sperren machst du in den Security Settings des AP. Dort ist in der Regel immer ein Haken über den man den Zugriff auf das WebGUI aus dem WLAN verhindern kann. Das solltest du zwingend aktivieren.
WebGui Zugriff auf den AP sollte nur über das LAN möglich sein. Ein entsprechend sicheres Passwort sollte selbstverständlich sein.
Hallo aqui,
die MAC-Adresse des AP(TP-Link Router mit DD-wrt firmeware) hatte ich bereits in der Ausnahmenregelung. Ich habe es jetzt noch einmal probiert, leider ohne Erfolg. Ich nehme an das Captive Portal sperrt in beide Richtungen, deshalb habe ich versuchsweise die MAC-Adresse des Laptops im LAN-Subnet eingetragen. Auch so kommt der Laptop nicht zum AP durch.
Nach herumprobieren mit der Ausnahmeregelung über die IP-Adresse hatte ich jetzt doch noch ein Erfolgserlebnis.
Die Regel dazu:
172.18.9.2 -> any
Der dazugehörige Text aus "Allowed IP-Adresses":
Adding allowed IP addresses will allow IP access to/from these addresses through the captive portal without being taken to the portal page. This can be used for a web server serving images for the portal page or a DNS server on another network, for example. By specifying from addresses, it may be used to always allow pass-through access from a client behind the captive portal.
any -> x.x.x.x All connections to the IP address are allowed
x.x.x.x -> any All connections from the IP address are allowed
@aqui:
Hast du einen Tipp für mich warum es mit den MAC-Adressen nicht funktioniert hat?
Kann die from-Regel von Gästen mißbraucht werden? Dazu müsste man den Laptop doch die IP-Adresse 172.18.9.2 geben, welche auch die IP-Adresse des Routers ist.
-> Adressenkonflikt?
@alle:
Hat jemand einen TP-Link wr1043nd mit dd-wrt Firmware laufen und weis wie man das Web-Interface des Routers für WLAN sperrt und ihn so konfigurieren damit die Benutzer des WLAN sich gegenseitig nicht sehen?
Die von aqui beschriebenen Funktionen habe ich bei diesem Router nicht gefunden.
Grüße,
Reitzi
die MAC-Adresse des AP(TP-Link Router mit DD-wrt firmeware) hatte ich bereits in der Ausnahmenregelung. Ich habe es jetzt noch einmal probiert, leider ohne Erfolg. Ich nehme an das Captive Portal sperrt in beide Richtungen, deshalb habe ich versuchsweise die MAC-Adresse des Laptops im LAN-Subnet eingetragen. Auch so kommt der Laptop nicht zum AP durch.
Nach herumprobieren mit der Ausnahmeregelung über die IP-Adresse hatte ich jetzt doch noch ein Erfolgserlebnis.
Die Regel dazu:
172.18.9.2 -> any
Der dazugehörige Text aus "Allowed IP-Adresses":
Adding allowed IP addresses will allow IP access to/from these addresses through the captive portal without being taken to the portal page. This can be used for a web server serving images for the portal page or a DNS server on another network, for example. By specifying from addresses, it may be used to always allow pass-through access from a client behind the captive portal.
any -> x.x.x.x All connections to the IP address are allowed
x.x.x.x -> any All connections from the IP address are allowed
@aqui:
Hast du einen Tipp für mich warum es mit den MAC-Adressen nicht funktioniert hat?
Kann die from-Regel von Gästen mißbraucht werden? Dazu müsste man den Laptop doch die IP-Adresse 172.18.9.2 geben, welche auch die IP-Adresse des Routers ist.
-> Adressenkonflikt?
@alle:
Hat jemand einen TP-Link wr1043nd mit dd-wrt Firmware laufen und weis wie man das Web-Interface des Routers für WLAN sperrt und ihn so konfigurieren damit die Benutzer des WLAN sich gegenseitig nicht sehen?
Die von aqui beschriebenen Funktionen habe ich bei diesem Router nicht gefunden.
Grüße,
Reitzi
Hallo reitzi !
Ja, sorry, das hatte ich übersehen. Deine erste FW Regel blockt ja alles was vom Gastnetz ins LAN geht und damit hast du dich dann selber ausgesperrt.
Da MUSS natürlich als allererste Regel stehen, das die AP IP 172.18.9.2 erlaubt ist auf den Laptop z.B. 10.14.7.100 und erst dann musst die FW Blocking Regel kommen "Gastnetz darf nicht ins LAN"
Es gibt 2 goldene Regeln bei den Firewall regeln die logisch immer zu beachten sind !
1.) Die Regeln greifen immer nur eingehend ins Interface !
2.) Logisch gilt: "First match wins" ! Also die erste Regel die greift gewinnt und alle Regeln danach werden nicht mehr abgearbeitet !
Deshalb ist die Reihenfolge der Regeln nicht trivial sondern hat erheblichen Einfluss auf die Funktion der FW Regeln allgemein.
Siehe deine Anforderungen oben. Also erst Laptop und AP erlauben und erst dann alles blocken.
Das hast du ja nun auch intuitiv rausbekommen ! Obwohl....dein "any" bei der 172.18.9.2 etwas Scheunentor ist !!
Besser du schränkst das noch auf deine Laptop IP ein oder wenigstens das 10.14.7er Netz und auch NUR den Port TCP 80 HTTP fürs WebGUI. Sicher ist sicher....
Und...du solltest NICHT eine IP Adresse in die CP Ausnahmeregel eingeben sondern immer die Mac Adresse !!
Ja, genau das mit der "From" Regel kann nämlich bei IPs missbraucht werden um Zugriff ohne das CP zu erreichen. Deshalb ja auch Mac !!
Warum ist ja oben hinreichend erklärt worden sofern du das denn überhaupt gelesen hast. IPs sind einfacher zu manipulieren um das CP zu überwinden. Vergiss nicht das du damit auch Zugriff ins sichere 10.14.7er Netz erlaubst !
Vergiss also besser die IPs in der CP Ausnahme und nimm dort IMMER die Mac Adressen !
Wenn es nicht funktioniert, hast du Leerschritte (Spaces) oder sowas in der Mac Adress Eingabe oder schlicht und einfach die falsche Mac eingetippt.
Funktionieren tut es (ausgetestet) definitiv ! Ansonsten mal pfSense flashen, da funktioniert es ebenfalls sicher !
Was die WLAN Isolation auf dem AP anbetrifft: Hat die original Firmware ggf. diese Funktion ?
DD-WRT ist nicht unbedingt nötig für eine popelige WLAN AP Funktion.
Sofern die Original FW diese Funktion hat (siehe Handbuch) solltest du diese ggf. dann wieder in den AP flashen.
Ja, sorry, das hatte ich übersehen. Deine erste FW Regel blockt ja alles was vom Gastnetz ins LAN geht und damit hast du dich dann selber ausgesperrt.
Da MUSS natürlich als allererste Regel stehen, das die AP IP 172.18.9.2 erlaubt ist auf den Laptop z.B. 10.14.7.100 und erst dann musst die FW Blocking Regel kommen "Gastnetz darf nicht ins LAN"
Es gibt 2 goldene Regeln bei den Firewall regeln die logisch immer zu beachten sind !
1.) Die Regeln greifen immer nur eingehend ins Interface !
2.) Logisch gilt: "First match wins" ! Also die erste Regel die greift gewinnt und alle Regeln danach werden nicht mehr abgearbeitet !
Deshalb ist die Reihenfolge der Regeln nicht trivial sondern hat erheblichen Einfluss auf die Funktion der FW Regeln allgemein.
Siehe deine Anforderungen oben. Also erst Laptop und AP erlauben und erst dann alles blocken.
Das hast du ja nun auch intuitiv rausbekommen ! Obwohl....dein "any" bei der 172.18.9.2 etwas Scheunentor ist !!
Besser du schränkst das noch auf deine Laptop IP ein oder wenigstens das 10.14.7er Netz und auch NUR den Port TCP 80 HTTP fürs WebGUI. Sicher ist sicher....
Und...du solltest NICHT eine IP Adresse in die CP Ausnahmeregel eingeben sondern immer die Mac Adresse !!
Ja, genau das mit der "From" Regel kann nämlich bei IPs missbraucht werden um Zugriff ohne das CP zu erreichen. Deshalb ja auch Mac !!
Warum ist ja oben hinreichend erklärt worden sofern du das denn überhaupt gelesen hast. IPs sind einfacher zu manipulieren um das CP zu überwinden. Vergiss nicht das du damit auch Zugriff ins sichere 10.14.7er Netz erlaubst !
Vergiss also besser die IPs in der CP Ausnahme und nimm dort IMMER die Mac Adressen !
Wenn es nicht funktioniert, hast du Leerschritte (Spaces) oder sowas in der Mac Adress Eingabe oder schlicht und einfach die falsche Mac eingetippt.
Funktionieren tut es (ausgetestet) definitiv ! Ansonsten mal pfSense flashen, da funktioniert es ebenfalls sicher !
Was die WLAN Isolation auf dem AP anbetrifft: Hat die original Firmware ggf. diese Funktion ?
DD-WRT ist nicht unbedingt nötig für eine popelige WLAN AP Funktion.
Sofern die Original FW diese Funktion hat (siehe Handbuch) solltest du diese ggf. dann wieder in den AP flashen.
Hallo aqui,
zunächst einmal danke für deine Antwort.
Ja die allererste Regel soll alles blocken was vom Gastnetz ins LAN über das Interface Gasthaus geht.
So und jetzt auch schon meine erste Frage:
Genügt es zum Konfigurieren des AP über WebGui nicht, wenn der Zugriff vom LAN in das Gastnetz zum AP erlaubt ist? Oder muss auch die Verbindung vom AP zum LAN erlaubt sein.
Das komische an der ganzen Sache ist, dass wenn ich das Captiv Portal ausschalte alles funktioniert. So wie ich in meinem ersten Beitrag geschrieben habe, funktioniert dann auch das Konfigurieren des APs vom LAN aus, obwohl kein Zugriff vom Gastnetz ins LAN erlaubt ist.
Deine Warnung, das man keine "Allowed IP-Adresses" verwenden soll, habe ich natürlich gelesen. Leider hatte ich mit der Ausnahme über die MAC-Adresse keinen Erfolg.
Die MAC-Adresse ist auf dem Router aufgedruckt und die stimmt überein mit der die angezeigt wird, wenn man deine Anleitung befolgt. ("... pingst du ihn einmal an und gibst dann arp -a in der Eingabeaufforderung ein um sie zu sehen")
zunächst einmal danke für deine Antwort.
Ja die allererste Regel soll alles blocken was vom Gastnetz ins LAN über das Interface Gasthaus geht.
So und jetzt auch schon meine erste Frage:
Genügt es zum Konfigurieren des AP über WebGui nicht, wenn der Zugriff vom LAN in das Gastnetz zum AP erlaubt ist? Oder muss auch die Verbindung vom AP zum LAN erlaubt sein.
Das komische an der ganzen Sache ist, dass wenn ich das Captiv Portal ausschalte alles funktioniert. So wie ich in meinem ersten Beitrag geschrieben habe, funktioniert dann auch das Konfigurieren des APs vom LAN aus, obwohl kein Zugriff vom Gastnetz ins LAN erlaubt ist.
Deine Warnung, das man keine "Allowed IP-Adresses" verwenden soll, habe ich natürlich gelesen. Leider hatte ich mit der Ausnahme über die MAC-Adresse keinen Erfolg.
Die MAC-Adresse ist auf dem Router aufgedruckt und die stimmt überein mit der die angezeigt wird, wenn man deine Anleitung befolgt. ("... pingst du ihn einmal an und gibst dann arp -a in der Eingabeaufforderung ein um sie zu sehen")
Mmmmhhh, die erste Frage erzeugt etwas Strinrunzeln und läst die vorsichtige Frage hochkommen ob du generell die Basiskommunikation in einem IP Netzwerk verstanden hast...
Du solltest vorher erstmal das hier lesen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Es sollte auch dir nun klar sein das die Kommunikation im IP netzwerk immer didirektional ist. Das ist übrigens bei Menschen genau so. Wenn du mit deinem Freund redest antwortet der dir auch was auf deine Fragen.
Genau das passiert auch bei deiner Kommunikation mit dem AP. Du sendest auf TCP Port 80 (HTTP) Pakete zum AP und der sendet dir doch auch Output zurück wenn du was im WebGui eingestellt hast. Die ganz normale IP Kommunikation also wie du auch mit einem Webserver im Internet redest.
Jedem Erstklässler und hoffentlich auch dir ist ja klar das die Paketkommunikation beidseitig ist.
Die Antwortpakete des APs bleiben aber am CP hängen, da der AP sich nicht authentisiert hat.
Das AP funktioniert so das es die Mac Adresse eines nicht authentisierten Clients nicht in den ARP Cache bzw. die Forwarding Table der Firewall übernimmt ohne Authentisierung. Folglich scheitert also die Kommunikation mit diesem unauthentisierten Client. Der tiefere Sinn eines jeglichen CPs bzw. Hotspots.
Fazit: Die Antwortpakete des APs können also das CP nicht passieren, da der AP sich am CP nicht selber authentisieren kann.
Folglich muss also die Mac Adresse des AP in die Ausnahmetabelle des CPs, damit dieser keine Authentisierung triggert und geblockt wird. Damit ist der AP dann ohne CP erreichbar aus allen Segmenten sofern dort (und auch im AP Segment selber) natürlich zusätzlich noch die Firewall Regeln passen !
Wenn schon Security, dann auch bitte richtig !
Hoffe das das nun verstanden ist von dir ?! Kannst du auch immer verifizieren indem du mal eine * * any any FW Regel auf beiden Ports nimmst und nur das CP überwinden musst.
Die Mac Ausnahme sollte in jedem Falle klappen. Ggf. machst du dort dennoch einen Tippfehler.
Flashe ansonsten einmal eine pfSense Firmware statt der Monowall:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
(pfSense-2.0.1-RELEASE-xg-i386-nanobsd.img.gz "x" = steht für die Größe der verwendeten Flash Karte wenn du ein ALIX Board verwendest)
Damit funktioniert die Mac Adress Ausnahme totsicher.
Du solltest vorher erstmal das hier lesen:
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Es sollte auch dir nun klar sein das die Kommunikation im IP netzwerk immer didirektional ist. Das ist übrigens bei Menschen genau so. Wenn du mit deinem Freund redest antwortet der dir auch was auf deine Fragen.
Genau das passiert auch bei deiner Kommunikation mit dem AP. Du sendest auf TCP Port 80 (HTTP) Pakete zum AP und der sendet dir doch auch Output zurück wenn du was im WebGui eingestellt hast. Die ganz normale IP Kommunikation also wie du auch mit einem Webserver im Internet redest.
Jedem Erstklässler und hoffentlich auch dir ist ja klar das die Paketkommunikation beidseitig ist.
Die Antwortpakete des APs bleiben aber am CP hängen, da der AP sich nicht authentisiert hat.
Das AP funktioniert so das es die Mac Adresse eines nicht authentisierten Clients nicht in den ARP Cache bzw. die Forwarding Table der Firewall übernimmt ohne Authentisierung. Folglich scheitert also die Kommunikation mit diesem unauthentisierten Client. Der tiefere Sinn eines jeglichen CPs bzw. Hotspots.
Fazit: Die Antwortpakete des APs können also das CP nicht passieren, da der AP sich am CP nicht selber authentisieren kann.
Folglich muss also die Mac Adresse des AP in die Ausnahmetabelle des CPs, damit dieser keine Authentisierung triggert und geblockt wird. Damit ist der AP dann ohne CP erreichbar aus allen Segmenten sofern dort (und auch im AP Segment selber) natürlich zusätzlich noch die Firewall Regeln passen !
Wenn schon Security, dann auch bitte richtig !
Hoffe das das nun verstanden ist von dir ?! Kannst du auch immer verifizieren indem du mal eine * * any any FW Regel auf beiden Ports nimmst und nur das CP überwinden musst.
Die Mac Ausnahme sollte in jedem Falle klappen. Ggf. machst du dort dennoch einen Tippfehler.
Flashe ansonsten einmal eine pfSense Firmware statt der Monowall:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
(pfSense-2.0.1-RELEASE-xg-i386-nanobsd.img.gz "x" = steht für die Größe der verwendeten Flash Karte wenn du ein ALIX Board verwendest)
Damit funktioniert die Mac Adress Ausnahme totsicher.
Hallo,
ich bin leider etwas spät dran. Habe aber eine gute Neuigkeit, mit pfsense hat es ohne irgendwelche Probleme funktioniert.
danke für die Hilfe
ich bin leider etwas spät dran. Habe aber eine gute Neuigkeit, mit pfsense hat es ohne irgendwelche Probleme funktioniert.
danke für die Hilfe
