Netzwerkkonfiguration und Firewall-Regeln in pfSense
Hallo Community,
zu Beginn möchte ich mich recht herzlich bei "aqui" bedanken, der mich mit seinen Tutorials zum Aufbau von Gast-Netzwerken und Verwenden der Firewall "pfSense" über ein ALIX-Board sehr begeistert und weitergeholfen hat.
Wir vermieten einige Ferienwohnungen und Gästezimmer und haben den Gästen bisher WLAN über eine verschlüsselte WPA2-Verbindung angeboten. Immer wieder hat es Anmeldeschwierigkeiten (aufgrund der Verschlüsselung) gegeben. Zudem ist das private Netzwerk nicht vom Gastnetzwerk getrennt. Deshalb möchte ich pfSense mit einem CaptivePortal einsetzen.
Der Netzaufbau sollte ungefähr so aussehen:
Derzeit habe ich neben dem Pirelli einen Linksys WRT160N als Access Point sowie einen Fritz Repeater im Einsatz für das WLAN-Netz zur Verfügung.
Ich möchte nun die Situation nutzen und das WLAN-Netzwerk, wie oben dargestellt, erweitern bzw. optimieren. Für das 1.OG und 2.OG benötige ich nur ein Netzwerk für die Gäste. Die AP würde ich via Power-LAN (http://www.amazon.de/Devolo-Network-Ethernet-Netzwerk-Steckdose/dp/B003 ..) versorgen. Doch im Erdgeschoss ist neben dem Gäste- auch ein privates WLAN-Netzwerk erforderlich.
Es stellen sich mir folgende Fragen: Könnte ich mit dem Cisco RV110W zwei VLAN im EG aufspannen und den Linksys WRT160N weiterverwenden? So würde ich mir einen AP sparen. Müsste dieser mit DD-WRT geflasht werden? Ich könnte auch den Pirelli für privates WLAN verwenden - doch dann wäre die pfSense-Firewall nutzlos und das Netz angreifbar, oder? Oder sollte gleich ein VLAN aufgebaut werden? Lohnt sich der Aufwand? Bin kein Netzwerktechniker.
Sind für die oberen Stockwerke diese AP (Edimax EW-7416, Draytek_AP-800) ratsam oder gibt es Alternativen.
Ich habe bereits einige Experimente mit pfSense und dem ALIX-Board durchgeführt. Während am LAN-Port alles erlaubt ist, habe ich am OPT1-Port Regeln in der Firewall definiert. Dabei ist mir aufgefallen, dass Internetseiten über den OPT1-Port sehr langsam und teilweise unvollständig (Bilder) geladen werden. Liegt das an den freigegebenen Ports/Adressen? Gibt es eine grobe Standardkonfigurarion welche Ports/Adressen heutzutage im Alltagsumfeld freigegeben werden sollten (imap, smtp,...)?
Hier meine (derzeitigen) Regeln am Gäste-(OPT1) Port:
Ich bitte um Entschuldigung für den langen Text und die vielen Fragen. Für baldige Antworten wäre ich euch sehr dankbar.
Gruß
Michael
PS: IP-Adresse des Switches ändern:
PORT to VLAN:
zu Beginn möchte ich mich recht herzlich bei "aqui" bedanken, der mich mit seinen Tutorials zum Aufbau von Gast-Netzwerken und Verwenden der Firewall "pfSense" über ein ALIX-Board sehr begeistert und weitergeholfen hat.
Wir vermieten einige Ferienwohnungen und Gästezimmer und haben den Gästen bisher WLAN über eine verschlüsselte WPA2-Verbindung angeboten. Immer wieder hat es Anmeldeschwierigkeiten (aufgrund der Verschlüsselung) gegeben. Zudem ist das private Netzwerk nicht vom Gastnetzwerk getrennt. Deshalb möchte ich pfSense mit einem CaptivePortal einsetzen.
Der Netzaufbau sollte ungefähr so aussehen:
Derzeit habe ich neben dem Pirelli einen Linksys WRT160N als Access Point sowie einen Fritz Repeater im Einsatz für das WLAN-Netz zur Verfügung.
Ich möchte nun die Situation nutzen und das WLAN-Netzwerk, wie oben dargestellt, erweitern bzw. optimieren. Für das 1.OG und 2.OG benötige ich nur ein Netzwerk für die Gäste. Die AP würde ich via Power-LAN (http://www.amazon.de/Devolo-Network-Ethernet-Netzwerk-Steckdose/dp/B003 ..) versorgen. Doch im Erdgeschoss ist neben dem Gäste- auch ein privates WLAN-Netzwerk erforderlich.
Es stellen sich mir folgende Fragen: Könnte ich mit dem Cisco RV110W zwei VLAN im EG aufspannen und den Linksys WRT160N weiterverwenden? So würde ich mir einen AP sparen. Müsste dieser mit DD-WRT geflasht werden? Ich könnte auch den Pirelli für privates WLAN verwenden - doch dann wäre die pfSense-Firewall nutzlos und das Netz angreifbar, oder? Oder sollte gleich ein VLAN aufgebaut werden? Lohnt sich der Aufwand? Bin kein Netzwerktechniker.
Sind für die oberen Stockwerke diese AP (Edimax EW-7416, Draytek_AP-800) ratsam oder gibt es Alternativen.
Ich habe bereits einige Experimente mit pfSense und dem ALIX-Board durchgeführt. Während am LAN-Port alles erlaubt ist, habe ich am OPT1-Port Regeln in der Firewall definiert. Dabei ist mir aufgefallen, dass Internetseiten über den OPT1-Port sehr langsam und teilweise unvollständig (Bilder) geladen werden. Liegt das an den freigegebenen Ports/Adressen? Gibt es eine grobe Standardkonfigurarion welche Ports/Adressen heutzutage im Alltagsumfeld freigegeben werden sollten (imap, smtp,...)?
Hier meine (derzeitigen) Regeln am Gäste-(OPT1) Port:
Ich bitte um Entschuldigung für den langen Text und die vielen Fragen. Für baldige Antworten wäre ich euch sehr dankbar.
Gruß
Michael
PS: IP-Adresse des Switches ändern:
PORT to VLAN:
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 214199
Url: https://administrator.de/contentid/214199
Ausgedruckt am: 25.11.2024 um 21:11 Uhr
24 Kommentare
Neuester Kommentar
zu Beginn möchte ich mich recht herzlich bei "aqui" bedanken, der mich mit seinen Tutorials zum Aufbau von Gast-Netzwerken und Verwenden der Firewall "pfSense" über ein ALIX-Board sehr begeistert und weitergeholfen hat.
Na dann kannst du ja auch einmal schnell zu der Anleitung hin und ihm einen Punkt dafür vergeben.Hier noch ein Buch was sich ausführlich mit pfSense befasst, ist zwar auf englisch geschrieben, aber das sollte denke
ich nicht viel ausmachen.
pfSense: The Definitive Guide (Taschenbuch)
Gruß
Dobby
Eins ist nicht ganz klar: Der private AP arbeitet der im gleichen IP Segment wie der "EG Büro PC" ??
Wenn ja musst du den AP einfach dort mit in das IP Segment einhängen und gut ist.
Ist der private AP ein weiteres privates IP Segment was isoliert zum "EG Büro PC" arbeiten soll, dann kommst du um ein VLAN nicht drumrum, da ja schon alle physischen 3 Ports des ALIX benutzt sind.
Dann gehst du so vor wie es hier im Tutorial beschrieben ist:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
im Kapitel "Praxisbeispiel".
Wenn du also im EG mit den APs (die dann Multi SSID fähig sein müssen) einmal das Gastsegment bedienen willst und gleichzeitig das private WLAN, dann nimmst du das Gast Segment als Parent Interface und erzeugst dort ein Subinterface drauf in das du das private WLAN legst.
Die FW Regeln des Gast Interfaces passt du dann so an das du sowohl den Zugriff ins private WLAN Segment aus auch den Zugriff ins Segment "EG Büro PC" verbietest und das wars.
Damit sollte das dann problemlos funktionieren. Wenn du mehrere Multi SSID APs dafür verwenden musst um das EG mit beiden WLANs auszuleichten dann benötigst du einen kleinen VLAN Switch (z.B. Cisco SG-200-8 o.ä.) um beide VLANs vertielen zu können.
Eigentlich ist das eine einfache Angelegenheit. Welche APs du dabei verwendest ist eigentlich völlig egal. Wichtig ist einzig das es Multi SSID APs sein müssen, wenn sie beide SSIDs (Gast und Privat) gleichzeitig bedienen sollen.
Dein restliches Design ist klasssicher Standard und richtig gemacht.
Du solltest ein Gast WLAN natürlich niemals verschlüsseln mit WPA o.ä., das wäre völliger Unsinn und würde einem Captive Portal widerspechen, da du die Authentisierung der Gäste ja immer mit einem Einmal Passwort (Voucher) machst.
Zudem bringt es nix, da du ja jedem immer dieses Passwort mitteilen musst und es damit quasi offen ist. Dann kannst du gleich an der Eingangstür ein Schild anbringen: "Unser WLAN Passwort ist xyz" Fazit also: Gäste Netze mit einem Hotspot zu verschlüsseln ist Unsinn !
Nochwas zu deiner FW Regel oben in der ein fataler Fehler ist !!:
Die Portalseite wird durch TCP 80 Traffic getriggert. Der kann aber nur kommen wenn es eine erfolgreiche DNS Auflösung gegeben hat !!! Bei dir fehlt die Freigabe von DNS aber völlig !! (Siehe Tutorial Beispiel !)
Deshalb kommt es vermutlich auch zu der rumpeligen Connectivity am OPT1 Port bei dir !
Du solltest also zwingend die folgende Reihenfolge einhalten:
1.) Zuerst UDP/TCP 53 DNS von Source: Gastsegment auf Destination any erlauben
2.) Dann Source: Gastsegment auf Destination: private Netze verbieten. Ggf. wiederholen bei mehreren priv.Netzen
2.) Dann TCP 80 von Source: Gastsegment auf Destination any erlauben
3.) Dann TCP 8000 von Source: Gastsegment auf Destination any erlauben
4.) Dann restliche Protokolle der Gast Whitelist immer von Source: Gastsegment auf Destination any erlauben.
So wird dann ein Schuh draus.
Der Rest bei dir ist aber perfectly OK !
Allgemeine Standardports für die Freigabe für Gäste sind:
HTTPS TCP 443
SMTP (Mail) TCP 25, 465, 587
POP3 TCP 110, 995
IMAP TCP 143, 993
NTP (Zeit) UDP 123
Das reicht damit Gäste Emailen und Surfen können !
Wenn du ihnen z.B. noch VPN Dienste erlauben willst (Business Gäste) komm folgendes hinzu:
IPsec VPN: UDP 500, 4500, ESP Protokoll
PPTP VPN: TCP 1723, GRE Protokoll
L2TP: UDP 500, 4500, TCP 1701, ESP Protokoll
OpenVPN UDP 1194
SSH TCP 22
Manche wollen noch RDP um remote auf Windows Terminal Server raufzukommen:
RDP TCP 3389
Wenn du noch Gamecenter, Updates und Stores für Smartphone Nutzer erlauben willst:
TCP 5223 Apple Facetime, iCloud
TCP 5228 Android Market Gtalk
Was du von obigem alles freigeben willst musst du dann selber entscheiden. Oder...lass erstmal nur Surfen und Email zu und warte bis sich Gäste beschweren oder noch zusätzliches wollen was du dann sukzessive freigeben kannst. Its up to you und deinem Security Bauchgefühl !!
Wenn ja musst du den AP einfach dort mit in das IP Segment einhängen und gut ist.
Ist der private AP ein weiteres privates IP Segment was isoliert zum "EG Büro PC" arbeiten soll, dann kommst du um ein VLAN nicht drumrum, da ja schon alle physischen 3 Ports des ALIX benutzt sind.
Dann gehst du so vor wie es hier im Tutorial beschrieben ist:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
im Kapitel "Praxisbeispiel".
Wenn du also im EG mit den APs (die dann Multi SSID fähig sein müssen) einmal das Gastsegment bedienen willst und gleichzeitig das private WLAN, dann nimmst du das Gast Segment als Parent Interface und erzeugst dort ein Subinterface drauf in das du das private WLAN legst.
Die FW Regeln des Gast Interfaces passt du dann so an das du sowohl den Zugriff ins private WLAN Segment aus auch den Zugriff ins Segment "EG Büro PC" verbietest und das wars.
Damit sollte das dann problemlos funktionieren. Wenn du mehrere Multi SSID APs dafür verwenden musst um das EG mit beiden WLANs auszuleichten dann benötigst du einen kleinen VLAN Switch (z.B. Cisco SG-200-8 o.ä.) um beide VLANs vertielen zu können.
Eigentlich ist das eine einfache Angelegenheit. Welche APs du dabei verwendest ist eigentlich völlig egal. Wichtig ist einzig das es Multi SSID APs sein müssen, wenn sie beide SSIDs (Gast und Privat) gleichzeitig bedienen sollen.
Dein restliches Design ist klasssicher Standard und richtig gemacht.
Du solltest ein Gast WLAN natürlich niemals verschlüsseln mit WPA o.ä., das wäre völliger Unsinn und würde einem Captive Portal widerspechen, da du die Authentisierung der Gäste ja immer mit einem Einmal Passwort (Voucher) machst.
Zudem bringt es nix, da du ja jedem immer dieses Passwort mitteilen musst und es damit quasi offen ist. Dann kannst du gleich an der Eingangstür ein Schild anbringen: "Unser WLAN Passwort ist xyz" Fazit also: Gäste Netze mit einem Hotspot zu verschlüsseln ist Unsinn !
Nochwas zu deiner FW Regel oben in der ein fataler Fehler ist !!:
Die Portalseite wird durch TCP 80 Traffic getriggert. Der kann aber nur kommen wenn es eine erfolgreiche DNS Auflösung gegeben hat !!! Bei dir fehlt die Freigabe von DNS aber völlig !! (Siehe Tutorial Beispiel !)
Deshalb kommt es vermutlich auch zu der rumpeligen Connectivity am OPT1 Port bei dir !
Du solltest also zwingend die folgende Reihenfolge einhalten:
1.) Zuerst UDP/TCP 53 DNS von Source: Gastsegment auf Destination any erlauben
2.) Dann Source: Gastsegment auf Destination: private Netze verbieten. Ggf. wiederholen bei mehreren priv.Netzen
2.) Dann TCP 80 von Source: Gastsegment auf Destination any erlauben
3.) Dann TCP 8000 von Source: Gastsegment auf Destination any erlauben
4.) Dann restliche Protokolle der Gast Whitelist immer von Source: Gastsegment auf Destination any erlauben.
So wird dann ein Schuh draus.
Der Rest bei dir ist aber perfectly OK !
Allgemeine Standardports für die Freigabe für Gäste sind:
HTTPS TCP 443
SMTP (Mail) TCP 25, 465, 587
POP3 TCP 110, 995
IMAP TCP 143, 993
NTP (Zeit) UDP 123
Das reicht damit Gäste Emailen und Surfen können !
Wenn du ihnen z.B. noch VPN Dienste erlauben willst (Business Gäste) komm folgendes hinzu:
IPsec VPN: UDP 500, 4500, ESP Protokoll
PPTP VPN: TCP 1723, GRE Protokoll
L2TP: UDP 500, 4500, TCP 1701, ESP Protokoll
OpenVPN UDP 1194
SSH TCP 22
Manche wollen noch RDP um remote auf Windows Terminal Server raufzukommen:
RDP TCP 3389
Wenn du noch Gamecenter, Updates und Stores für Smartphone Nutzer erlauben willst:
TCP 5223 Apple Facetime, iCloud
TCP 5228 Android Market Gtalk
Was du von obigem alles freigeben willst musst du dann selber entscheiden. Oder...lass erstmal nur Surfen und Email zu und warte bis sich Gäste beschweren oder noch zusätzliches wollen was du dann sukzessive freigeben kannst. Its up to you und deinem Security Bauchgefühl !!
Ja, das funktioniert so natürlich auch wie oben beschrieben mit dem RV 110W und ist logischerweise problemlos mit allen Komponenten realisierbar !
Alternativ kannst du auch einen kleinen VLAN Switch wie den Cisco SG-200-8 nehmen und die VLAN und LAN Ports dort in den entsprechenden VLANs terminieren.
Für unten kannst du dann jeden belibigen Multi SSID Accesspoint nehmen und vom Switch lässt du dann nur eine Gast VLAN Strippe nach oben gehen.
Die Frage nach dem Dual Radio AP ist schwer zu beantworten. Das Gros aller PCs, Laptops und Smartphones gerade im Billigbereich oder Mittelbereich supportet nur 2,4 Ghz.
Eher höherwertige Laptops und Smartphones supporten beide Bänder. Das Groß der Gäste wird sicher mit 2,4 Ghz arbeiten.
Ob du deinen Gästen den Luxus von 5 Ghz bescheren willst ist ganz allein deine Entscheidung.
Ggf. macht das Sinn in größeren Räumen wie Lobby, Kaminzimmer usw. wo viele Gäste zusammenkommen um dort den Traffic etwas zu entzerren mal einen einzelnen Dual Radio AP zu plazieren.
Wie gesagt...deine Entscheidung was du den Gästen Gutes tun willst !
Alternativ kannst du auch einen kleinen VLAN Switch wie den Cisco SG-200-8 nehmen und die VLAN und LAN Ports dort in den entsprechenden VLANs terminieren.
Für unten kannst du dann jeden belibigen Multi SSID Accesspoint nehmen und vom Switch lässt du dann nur eine Gast VLAN Strippe nach oben gehen.
Die Frage nach dem Dual Radio AP ist schwer zu beantworten. Das Gros aller PCs, Laptops und Smartphones gerade im Billigbereich oder Mittelbereich supportet nur 2,4 Ghz.
Eher höherwertige Laptops und Smartphones supporten beide Bänder. Das Groß der Gäste wird sicher mit 2,4 Ghz arbeiten.
Ob du deinen Gästen den Luxus von 5 Ghz bescheren willst ist ganz allein deine Entscheidung.
Ggf. macht das Sinn in größeren Räumen wie Lobby, Kaminzimmer usw. wo viele Gäste zusammenkommen um dort den Traffic etwas zu entzerren mal einen einzelnen Dual Radio AP zu plazieren.
Wie gesagt...deine Entscheidung was du den Gästen Gutes tun willst !
Ich wollte daraufhin im Webinterface des Switches die IP-Adresse ändern (siehe Screenshot 1.Post), doch nach einem Klick auf Apply hängt sich die Seite auf.
ist doch normal oder? Wenn Du mit einer IP Adresse eine Verbindung hast und diese ändert sich dann, ist die Verbindungeben futsch!
- Versuch doch danach einmal die neue IP Adresse aufzurufen und den Switch darüber zu erreichen.
- Versuche doch einfach die Sache über CLI abzuwickeln bzw. erledigen.
Gruß
Dobby
Wie funktioniert das mit CLI (Kommandozeile)?
Das sollte immer im Handbuch stehen was mit dem Switch kommt, denn das kann von Hersteller zu Hersteller auch malabweichen, klar irgend wie ist es schon ähnlich, aber eben nicht immer gleich.
Gruß
Dobby
P.S. Es kann natürlich auch sein dass dieser Switch erst gar keine CLI Eingabe unterstützt!
Deine Firewall Regel "Block any from OPT to LAN" ist wieder komplett falsch !!
Niemals darf da als Destination "LAN Adress" stehen !
Das ist doch totaler Blödsinn wo man auch von selber stutzig wird !!
"LAN Adress" ist die IP Adresse des LAN Ports an der Firewall ! Was diese Regel also macht ist lediglich den Zugriff vom OPT1 Segment auf die Firewall LAN IP zu verbieten mehr nicht !
Du merkst wie unsinnig das ist, oder ?
Hier muss also hin Source: OPT1 network und dann logischerweise als Destination: LAN network !!
So wird ein Schuh draus, denn du willst ja den Zugriff auf alle Komponenten im gesamten LAN Netzwerk verbieten !
Noch einen üblen Fehler solltest du unbedingt korrigieren:
Als Source immer * anzugeben ist ein Fehler und schafft nur wieder Sicherheitslöcher.
Hier muss stehen OPT1 network du willst ja nur einzig und allein Absender buw. Nutzern aus dem OPT1 Netzwerk das erlauben nicht aber der ganzen Welt oder Leuten die sich mit x-belibigen IP Adressen in dem Segment befinden. Genau das erlaubst du nämlich mit der fehlerhaften Regel !
Korrigier das also besser !
Ob du deinen PC für den Zugriff am ALIX oder PC anschliesst ist vollkommen Latte ! Port und Switch werden nur geswitcht, das spielt also keinerlei Rolle.
Anders wenn du damit einen dedizierten pfSense Port meinst. Der ist im Default immer geroutet, d.h. der PC befindet sich dann in einem anderen separaten IP Segment. Genau ebenso wenn du VLANs definierst an einem der pfSense Ports.
Anders wenn du eines diese IP Segmente an der pfSense per Bridging Konfig in der pfSense mit einem anderen FW Segment verbindest. Dazu sagst du aber nix, deshalb kann man deine Gedanken hier nur im freien Fall raten...
Was dein Tagging anbetrifft ist das so richtig wenn dein AP ein Multi SSID AP ist und die entsprechende SSIDs ind VLANs (10 und 20) forwardest.
Beide VLANs dann auf tagged und den AP dran anschliessen.
Den Port der zur pfSense geht ebenso wenn du auch an der pfSense mit tagged Ports arbeitest.
Ohne Tagging wenn du z.B. eine Strippe aus VLAN 10 auf den LAN Port steckst und VLAN 20 auf den OPT1 Port.
Siehst du also richtig und der Gedankengang ist so korrekt.
Niemals darf da als Destination "LAN Adress" stehen !
Das ist doch totaler Blödsinn wo man auch von selber stutzig wird !!
"LAN Adress" ist die IP Adresse des LAN Ports an der Firewall ! Was diese Regel also macht ist lediglich den Zugriff vom OPT1 Segment auf die Firewall LAN IP zu verbieten mehr nicht !
Du merkst wie unsinnig das ist, oder ?
Hier muss also hin Source: OPT1 network und dann logischerweise als Destination: LAN network !!
So wird ein Schuh draus, denn du willst ja den Zugriff auf alle Komponenten im gesamten LAN Netzwerk verbieten !
Noch einen üblen Fehler solltest du unbedingt korrigieren:
Als Source immer * anzugeben ist ein Fehler und schafft nur wieder Sicherheitslöcher.
Hier muss stehen OPT1 network du willst ja nur einzig und allein Absender buw. Nutzern aus dem OPT1 Netzwerk das erlauben nicht aber der ganzen Welt oder Leuten die sich mit x-belibigen IP Adressen in dem Segment befinden. Genau das erlaubst du nämlich mit der fehlerhaften Regel !
Korrigier das also besser !
Ob du deinen PC für den Zugriff am ALIX oder PC anschliesst ist vollkommen Latte ! Port und Switch werden nur geswitcht, das spielt also keinerlei Rolle.
Anders wenn du damit einen dedizierten pfSense Port meinst. Der ist im Default immer geroutet, d.h. der PC befindet sich dann in einem anderen separaten IP Segment. Genau ebenso wenn du VLANs definierst an einem der pfSense Ports.
Anders wenn du eines diese IP Segmente an der pfSense per Bridging Konfig in der pfSense mit einem anderen FW Segment verbindest. Dazu sagst du aber nix, deshalb kann man deine Gedanken hier nur im freien Fall raten...
Was dein Tagging anbetrifft ist das so richtig wenn dein AP ein Multi SSID AP ist und die entsprechende SSIDs ind VLANs (10 und 20) forwardest.
Beide VLANs dann auf tagged und den AP dran anschliessen.
Den Port der zur pfSense geht ebenso wenn du auch an der pfSense mit tagged Ports arbeitest.
Ohne Tagging wenn du z.B. eine Strippe aus VLAN 10 auf den LAN Port steckst und VLAN 20 auf den OPT1 Port.
Siehst du also richtig und der Gedankengang ist so korrekt.
Na ja das liegt ja nur an dir und deinen fehlerhaften FW Regeln das du auf den Switch nicht zugreifen kannst !
Zuerst erlaubst du natürlich in den FW Regeln den Zugriff von deiner PC IP auf die Switch IP.
Dann erst den Rest verbieten...und et voila ! Schon kannst du auf den Switch zugreifen !
Hast du ein CP dazwischen definierst du für die Mac des Switches (oder PCs) eine Ausnahmeregel ! So einfach ist das....
Wo ist also dein Problem ?
Mit der richtigen FW Regel ist das doch alles kein Thema...!
Zuerst erlaubst du natürlich in den FW Regeln den Zugriff von deiner PC IP auf die Switch IP.
Dann erst den Rest verbieten...und et voila ! Schon kannst du auf den Switch zugreifen !
Hast du ein CP dazwischen definierst du für die Mac des Switches (oder PCs) eine Ausnahmeregel ! So einfach ist das....
Wo ist also dein Problem ?
Mit der richtigen FW Regel ist das doch alles kein Thema...!
Kein Wunder das du auf der Leitung stehst, denn du hast die Grundfunktion einer Firewall Regeln nicht verstanden !
Genau da liegt dein Denkfehler....
Bei einer Firewall Regel gilt immer:
First Match wins !
Was bedeutet nachdem ein Regeleintrag positiv ist werden die restlichen Einträge NICHT mehr abgearbeitet !!!
Steht auch so mehrfach im Tutorial (wenn man es denn mal wirklich liest...!)
Da du in der 2ten Zeile/Regel allen Traffic verbietest und die damit positiv ist (als "Match"), kommt so der PC gar nicht mehr zum Zug an 3ter Stelle, da diese Regel gar nicht mehr abgearbeitet wird !!
Das muss also logischerweise VOR der allgemeinen Verbotsregel ins LAN stehen !!
So wird ein Schuh draus....
Genau da liegt dein Denkfehler....
Bei einer Firewall Regel gilt immer:
First Match wins !
Was bedeutet nachdem ein Regeleintrag positiv ist werden die restlichen Einträge NICHT mehr abgearbeitet !!!
Steht auch so mehrfach im Tutorial (wenn man es denn mal wirklich liest...!)
Da du in der 2ten Zeile/Regel allen Traffic verbietest und die damit positiv ist (als "Match"), kommt so der PC gar nicht mehr zum Zug an 3ter Stelle, da diese Regel gar nicht mehr abgearbeitet wird !!
Das muss also logischerweise VOR der allgemeinen Verbotsregel ins LAN stehen !!
So wird ein Schuh draus....
Hört sich gut an wenn nun alles klappt wie es soll.
Mit der Wärme ist das kein Thema das ist normal und damit laufen sie Jahre störungsfrei ! Es ist dann wohl eher der Switch der warm wird, denn die ALIX werden nicht mehr als handwarm !
Dann kannst du dich ja nun an den Webserver für die Browserbasierte Vouchervergabe machen
Voucher für pfSense online verwalten und optional Voucher per SMS verschicken
bzw.
Netzwerk Management Server mit Raspberry Pi
Mit der Wärme ist das kein Thema das ist normal und damit laufen sie Jahre störungsfrei ! Es ist dann wohl eher der Switch der warm wird, denn die ALIX werden nicht mehr als handwarm !
Dann kannst du dich ja nun an den Webserver für die Browserbasierte Vouchervergabe machen
Voucher für pfSense online verwalten und optional Voucher per SMS verschicken
bzw.
Netzwerk Management Server mit Raspberry Pi
Mmmhhh...gute Frage ! Es ist zu bezweifeln das Traffic Shaping auf virtuellen Interfaces also NICHT Parent Interfaces funktioniert. Das erfordert meist großen HW Aufwand, da die Subinterfaces in SW (Treiber) realisiert sind.
Ist aber der pfSense Doku so nicht zu entnehmen. Für die Parent Interfaces selber klappt das sicher !
Fazit: Versuch macht klug....teste es aus und miss die Bandbreite mal mit NetIO. Oder über FW oder CP Regeln die Bandbreite limitieren.
Besser ist eine Whitelist in der FW und nur das zu erlauben was Feriengäste so generell brauchen. Surfen, Email und Schluss..
Ist aber der pfSense Doku so nicht zu entnehmen. Für die Parent Interfaces selber klappt das sicher !
Fazit: Versuch macht klug....teste es aus und miss die Bandbreite mal mit NetIO. Oder über FW oder CP Regeln die Bandbreite limitieren.
Besser ist eine Whitelist in der FW und nur das zu erlauben was Feriengäste so generell brauchen. Surfen, Email und Schluss..
Nein nicht unbedingt ! Du musst nichts derartiges dafür machen.
Das stellt du allein in der Voucher Generierung (Services -> Captive Portal -> Voucher) unter # of Ticket Bits ein. Dieser Wert gibt vor wie lang der Voucher String ist ! (Default 10 Stellen)
Dann generierst du eine neue Roll und gut iss !
Das stellt du allein in der Voucher Generierung (Services -> Captive Portal -> Voucher) unter # of Ticket Bits ein. Dieser Wert gibt vor wie lang der Voucher String ist ! (Default 10 Stellen)
Dann generierst du eine neue Roll und gut iss !