Pfsense - Bandbreite niedrig
Hallo,
Ich habe bereits seit 5 Jahren pfsense im Einsatz - als Firewall und mit Captive Portal für das Gäste-WLAN.
Netzwerkaufbau siehe Beitrag Netzwerkkonfiguration und Firewall-Regeln in pfSense
Am OPT1 wird das Gäste-WLAN (Captive Portal) und über VLAN ein privates WLAN betrieben.
Nun habe ich folgendes Problem:
Es steht ein Breitbandanschluss mit 40 MBit/s zur Verfügung. Über das Captive Portal habe ich den Traffic auf 5 MBit (down) und 1 MBit(up) eingeschränkt.
Über das WLAN "Privat" erreiche ich aber nie mehr als 18 MBit/s. Am Ausgang vr02 an welchem über Kabel der PC angeschlossen ist, sind ca. 38 MBit/s vorhanden?
Als AP sind sind Edimax ew-7416apn v2 (300 MBit/s) installiert.
Habe auch schon den Smart Switch überbrückt und einen AP direkt an OPT1 angeschlossen - keine Veränderung.
Die Interfaces sind alle auf 100baseTX full-duplex.
Als Hardware wird ein ALIX Board 2D13 verwendet. Derzeit ist (noch) die Version 2.1.5 installiert. Habe schon vor einigen Jahren versucht ein Update zu machen, anschließend war die CPU jedoch immer auf Anschlag und pfsense nicht mehr bedienbar. Da der WLAN-Empfang für die Gäste schnell vorhanden sein musste, wurde die alte Software wieder installiert und bis heute nicht geupdatet.
Kann die alte Version ein Problem sein oder liegts an der Hardware? Früher ists nicht aufgefallen, da nur ein 16 MBit/s ADSL-Anschluss vorhanden war.
Spiele auch mit dem Gedanken das ALIX Board durch ein APU-Board APU.2C4 zu ersetzen und die neueste Version von pfsense oder OPNsense aufzuspielen.
Wo kann die Ursache liegen?
Schöne Grüße und noch einen schönen Sonntag,
Michael
Ich habe bereits seit 5 Jahren pfsense im Einsatz - als Firewall und mit Captive Portal für das Gäste-WLAN.
Netzwerkaufbau siehe Beitrag Netzwerkkonfiguration und Firewall-Regeln in pfSense
Am OPT1 wird das Gäste-WLAN (Captive Portal) und über VLAN ein privates WLAN betrieben.
Nun habe ich folgendes Problem:
Es steht ein Breitbandanschluss mit 40 MBit/s zur Verfügung. Über das Captive Portal habe ich den Traffic auf 5 MBit (down) und 1 MBit(up) eingeschränkt.
Über das WLAN "Privat" erreiche ich aber nie mehr als 18 MBit/s. Am Ausgang vr02 an welchem über Kabel der PC angeschlossen ist, sind ca. 38 MBit/s vorhanden?
Als AP sind sind Edimax ew-7416apn v2 (300 MBit/s) installiert.
Habe auch schon den Smart Switch überbrückt und einen AP direkt an OPT1 angeschlossen - keine Veränderung.
Die Interfaces sind alle auf 100baseTX full-duplex.
Als Hardware wird ein ALIX Board 2D13 verwendet. Derzeit ist (noch) die Version 2.1.5 installiert. Habe schon vor einigen Jahren versucht ein Update zu machen, anschließend war die CPU jedoch immer auf Anschlag und pfsense nicht mehr bedienbar. Da der WLAN-Empfang für die Gäste schnell vorhanden sein musste, wurde die alte Software wieder installiert und bis heute nicht geupdatet.
Kann die alte Version ein Problem sein oder liegts an der Hardware? Früher ists nicht aufgefallen, da nur ein 16 MBit/s ADSL-Anschluss vorhanden war.
Spiele auch mit dem Gedanken das ALIX Board durch ein APU-Board APU.2C4 zu ersetzen und die neueste Version von pfsense oder OPNsense aufzuspielen.
Wo kann die Ursache liegen?
Schöne Grüße und noch einen schönen Sonntag,
Michael
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 384551
Url: https://administrator.de/contentid/384551
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
22 Kommentare
Neuester Kommentar
Spiele auch mit dem Gedanken das ALIX Board durch ein APU-Board APU.2C4 zu ersetzen
Langfristig ist das das Beste !!Was du machen musst damit es klappt:
- Live und RRD Grafiken im Setup komplett abschalten und deaktivieren. Frisst viel Performance !
- Kein Rate Limit mehr verwenden. Frisst noch mehr Performance bei High Speed, da das in CPU gemacht wird a.d. 2D13.
- Keine überflüssigen Module im Dashboard !
- IPv6 komplett deaktivieren wenn du es nicht benötigst.
- Mac Exeptions, sofern verwendet im CP, in einer Alias Liste definieren.
- Power D und Crypto Chip aktivieren:
- Aktuelles Image flashen auf die SD. 2.3.5p2 ist aktuell !
Mehr kannst du nicht machen. Außer....
Ein neues APU Mainboard verwenden...
Hi,
welche Bandbreite misst du wenn du ein Gerät per Kabel (nicht WLAN !) direkt an OPT1 anschliesst ?
-
Wenn du schreibst
Version 2.3.5 läuft auf den alten Alix-Board problemlos.
ggf. hilft folgendes: Bckup der Konfiguration, Neuinstallation (kein Update durchführen !) mit Version 2.3.5 und dann das Backup einspielen
CH
welche Bandbreite misst du wenn du ein Gerät per Kabel (nicht WLAN !) direkt an OPT1 anschliesst ?
-
Wenn du schreibst
Habe schon vor einigen Jahren versucht ein Update zu machen, anschließend war die CPU jedoch immer auf Anschlag und pfsense nicht mehr bedienbar.
tippe ich auf ein Defekt des Alix Boards oder auf eine Fehlkonfiguration der pfSense.Version 2.3.5 läuft auf den alten Alix-Board problemlos.
ggf. hilft folgendes: Bckup der Konfiguration, Neuinstallation (kein Update durchführen !) mit Version 2.3.5 und dann das Backup einspielen
CH
wo finde ich rate limit?
Bei deinen CP Usern !Bekomme jedoch am WLAN-Client (Tablet) nur ca. 17 MBit/s zusammen.
Das hat rein gar nix mit der pfSense zu tun !Im WLAN hast du soviel Einflüsse die die Bandbreite beeinflussen. Die WLAN Bandbreite ist hochdynamisch und wird je nach Feldstärke immer variiert !
Das liegt vermutlich zu 90% an deiner Funkschnittstelle.
https://www.tomsnetworking.de/content/reports/j2005a/report_wlan_luege/i ...
- TKIP aktiv
- Störungen von Nachbarkanälen ? Hier mindestens 4 Kanäle Abstand !
- Störungen von anderen 2,4 Ghz Usern, Bluetooth, drahtlosem Audio/Video, Mikrowellenherd
Seit WLAN Umstellung von Cisco WAP 200 auf Zyxel NWA3560-N schlechtere Verbindung
DAS solltest du also als Allererstes mal Troubleshooten und dann vor allem mit einem Protokoll unabhängigen Tool wie NetIO messen weil das auch unterschiedliche Paketgrößen berüksichtigt !!
https://web.ars.de/netio/
http://www.nwlab.net/art/netio/netio.html
Dann sehen wir mal weiter...
Wenn überhaupt dann solltest du also IMMER Kabel basierend messen um die variable WLAN Bandbreite auszuschliessen.
Nur so lässt sich ja eine verlässliche Aussage treffen was die pfSense wirklich kann. Mal angenommen das dann auch der Provider wenigstens die zugesagte Bandbreite halten kann. Normal überbuchen die auch ihr Kundenanschlüsse.
Frage zum VLAN 10:
Gehe also mal strategisch vor:
Um dir hier nicht selber eine Falle zu stellen solltest du ggf. Die VLAN 10 Regel mal testweise auf eine Scheunentor Regel setzen also: PASS, Protocol: any, Source: VLAN10_net, Destination: ANY
Damit darf dann erstmal alles aus dem VLAN 10 raus.
Dann auf der pfSense unter Diagnostics --> Ping folgendes eingeben:
Das zeigt dann das generell aus dem VLAN 10 Internet Konnektivität gegeben ist. (ICMP muss in den VLAN10 Regeln erlaubt sein !)
Dann Test PC ins VLAN 10 klemmen und checken:
- Betreibst du die pfSense in einer Kaskade mit einem Router oder direkt an einem NUR Modem zum Provider ?
- Hast du im VLAN 10 einen DHCP Server laufen und bekommst du von dem entsprechend richtige IP, Gateway und DNS Adressen ?
- Ist das Captive Portal auch am VLAN 10 Interface aktiv ?
- Welches ist das physische Parent Interface vom VLAN 10 Int. ? Das LAN Interface ??
- Deine FW Regel im VLAN 10 Interface ist etwas unökonomisch. Du erlaubst hier Port 53 (DNS) und danach nochmal alle TCP Ports und damit auch TCP 53. Nicht falsch aber könnte man etwas anders machen.
Gehe also mal strategisch vor:
Um dir hier nicht selber eine Falle zu stellen solltest du ggf. Die VLAN 10 Regel mal testweise auf eine Scheunentor Regel setzen also: PASS, Protocol: any, Source: VLAN10_net, Destination: ANY
Damit darf dann erstmal alles aus dem VLAN 10 raus.
Dann auf der pfSense unter Diagnostics --> Ping folgendes eingeben:
- Hostname = 8.8.8.8
- Source address = VLAN10_Interface
Das zeigt dann das generell aus dem VLAN 10 Internet Konnektivität gegeben ist. (ICMP muss in den VLAN10 Regeln erlaubt sein !)
Dann Test PC ins VLAN 10 klemmen und checken:
- ...das er eine korrekte IP, Gateway und DNS bekommen hat
- das VLAN 10 Interface 192.168.10.1 der pfSense pingen zum Check das die pfSense erreichbar ist. OK würde auch schon der Fakt zeigen wenn der VLAN 10 Client eine IP Adresse per DHCP bekommen hat von der pfSense.
- Klappt der pfSense Ping dann jetzt die 8.8.8.8 pingen vom Client
- Sollte auch klappen.
- Dann VLAN 10 Firewall Regel entsprechend anpassen zu dem Protokollen die du durchlassen willst.
Am DSL-Router war und ist entgegen der Grafik DHCP aktiv.
Generell ist das kein Problem nur die Kardinalsfrage hier ist ob du das mit der pfSense in irgendeiner Art und Weise nutzt ???Das solltest du natürlich NICHT tun ! Klar, denn im 10er Koppelnetz sollte man niemals dynamische IPs verwenden sondern immer statische.
Solange du also statische IPs dort hast außerhalb der aktiven DHCP Range, mindestens aber eine feste DHCP Reservierung über die Mac Adresse des pfSense WAN Ports, kann das so bleiben. Dann lässt man die DHCP Funktion einfach brach liegen, was ja nicht stört.
Habe die Firewall-Regeln auf VLAN10 deaktiviert und deine Regel hinzugefügt. --> Ping funktioniert.
So sollte es sein ! Nur...Ping von wo nach wo ?? Hast du die Ping Funktion der pfSense (Diagnostics) benutzt ???
Von hier solltest du:
- a.) das pfSense VLAN 10 Interface pingen können
- b.) die 10er LAN IP Adresse des Pirelli Routers pingen können
- c.) eine Internet IP wie die 8.8.8.8 pingen können
Dazu solltest du nochmal ein Feedback geben !
Test noch mit einem Desktop-Rechner durchführen, es wird aber nur das OPT1 (vr2) angezeigt. Über OPT1 (Captive Portal) ist die Verbindung problemlos möglich.
Sorry, Bahnhof, Ägypten ????Was meinst du damit ??
OPT1 ist das physische Parent Interface über das auch tagged das VLAN 10 rennt.
Sprich also die physische IP und die des VLAN 10 liegen auf diesem Interface.
Dazu ist deine Zeichnung oben schlciht falsch, denn sie zeigt mit keiner Beschriftung WIE die IP Adressierung im VLAN 10 aussieht. Dort müsste ein eigenes IP Netz konfiguriert sein wie 192.168.10.0 !!
Was noch irreführend ist in deiner Zeichnung:
Der Büro PC-EG ist oben am vr2 Interface. Aber am vr2 Interface ist laut pfSense Interface Konfig ja dein OPT1 Interface. Hier stimmt also was mit der Zeichnung nicht.
Vermutlich ist der PC Büro-EG am LAN Interface vr1 und OPT1 und VLAN 10 am vr2 ?! Kann das sein ?
Folgende ToDos müssen dafür gegeben sein:
- Haken am WAN Port Setup der pfSense "Blocking RFC1918 networks" MUSS entfernt sein !
- VLAN 10 Interface auf dem Parent Interface OPT1 eingerichtet (sieht aus also ob das passiert ist ?!)
- OPT1 Parent Firewall Regel: PASS, Protocol: any, Source: OPT1_net, Destination: ANY
- VLAN 10 Firewall Regel: PASS, Protocol: any, Source: VLAN10_net, Destination: ANY
- DHCP Server einrichten auf der pfSense für OPT1 und VLAN 10
- Switchport, wo die pfSense am Switch mit dem OPT1 Port verbunden ist, muss so eingestellt sein:
- Untagged für Default VLAN 1
- Tagged für VLAN 10
- Genau diese Port Einstellung gilt auch für alle Switchports an denen die MSSID APs angeschlossen sind.
Zum Test solltest du auf dem Switch Endgeräde Ports (Mode Access) unatgged ins VLAN (ist eh Default) und ins VLAN 10 legen zum Testen.
Wenn du jetzt den PC ins VLAN 1 klemmst am Switch, dann sollte follgendes möglich sein:
- PC hat IP Adresse, Gateway aus OPT1 Netzwerk 192.168.1.0 /24 (ipconfig (Windows))
- Ping auf die OPT1 IP Adresse der pfSense
- Ping auf die 10er LAN IP des Pirelli Routers
- Ping auf die 8.8.8.8 im Internet
- PC hat IP Adresse, Gateway aus OPT1 Netzwerk 192.168.10.0 /24 (ipconfig (Windows))
- Ping auf die VLAN 10 IP Adresse der pfSense
- Ping auf die 10er LAN IP des Pirelli Routers
- Ping auf die 8.8.8.8 im Internet
Ist dem so und hast du das alles überprüft ?
Wie kann ich auf das VLAN10 zugreifen? In den Adaptereinstellungen finde keinen Reiter VLAN. Treiber-Update der Netzwerkkarte erforderlich?)
Das ist doch ganz einfach !!Weise dem Switchport einfach das VLAN 10 zu und stecke den Testrechner dort rein. Am Rechner selber ist nichts dafür einzustellen !!
Der Switchport hat den Mode: Access und ist Untagged im VLAN 10 (PVID auf 10)
Fertisch !
So sähe das aus L3 Sicht aus wenn du alles richtig gemacht hast:
Die pfSense nummeriert die Portalseiten hoch je nach Interface Index. Du solltest eine Range von 8000-8005 freigeben, wie hier in diesem Beispiel wo das VLAN 10 fehlerlos mit dem CP funktioniert:
Logisch ist deine Filterliste auch schlecht. Du solltest immer zuerst die CP relevanten Dinge erlauben und erst dann die DENY Regeln zu den anderen Interfaces. Danach dann das was du aus dem CP erlauben willst.
Erstelle erstmal eine normale CP Regel wie die obige im Screenshot und checke das CP das es sauber funktioniert mit den entsprechenden Interfaces.
Das Parent Interface ist immer untagged.
Hast du aber richtig gemacht wenn es bei dir funktioniert !
Logisch ist deine Filterliste auch schlecht. Du solltest immer zuerst die CP relevanten Dinge erlauben und erst dann die DENY Regeln zu den anderen Interfaces. Danach dann das was du aus dem CP erlauben willst.
Erstelle erstmal eine normale CP Regel wie die obige im Screenshot und checke das CP das es sauber funktioniert mit den entsprechenden Interfaces.
Bezüglich VLAN1 und VLAN10 an einem kabelgebundenen Client
Das ist dann am pfSense Interface so das VLAN 1 untagged ist und (bei dir) am OPT1 Interface anliegt und VLAN 10 dann Tagged was am VLAN 10 Interface anliegt.Das Parent Interface ist immer untagged.
Hast du aber richtig gemacht wenn es bei dir funktioniert !
Ein Bug diesbezüglich ist schon lange gefixt:
https://redmine.pfsense.org/issues/851
Siehe auch:
https://forum.netgate.com/topic/51998/captive-portal-on-vlans
Was an deinen Screenshots oben auffällt ist die Tatsache das du eigentlich die OPT1 Regeln auf dem "WAN" Interface aktiv hast ?!?
Oben sieht man ja das WAN selektiert ist dann ist das Regelwerk aber darunter genau das Regelwerk was am OPT1 Interface sein soollte !!!
Kann das sein das du hier was gründlich falsch gemacht hast ???
Am WAN Interface können logischerweise niemals Pakete auftauchen die als Absender das OPT1 Interface haben !!!
Das sollte dir doch klar sein.
Vermutlich ist genau das dein Kardinalsfehler !
https://redmine.pfsense.org/issues/851
Siehe auch:
https://forum.netgate.com/topic/51998/captive-portal-on-vlans
Was an deinen Screenshots oben auffällt ist die Tatsache das du eigentlich die OPT1 Regeln auf dem "WAN" Interface aktiv hast ?!?
Oben sieht man ja das WAN selektiert ist dann ist das Regelwerk aber darunter genau das Regelwerk was am OPT1 Interface sein soollte !!!
Kann das sein das du hier was gründlich falsch gemacht hast ???
Am WAN Interface können logischerweise niemals Pakete auftauchen die als Absender das OPT1 Interface haben !!!
Das sollte dir doch klar sein.
Vermutlich ist genau das dein Kardinalsfehler !
dachte ich mir es ist einen Versuch wert die Regeln hier einzutragen.
Was sollte der tiefere Sinn sein falsche Regeln auf einem falschen Interface als "Versuch" einzutragen ??!!Muss man sicher nicht weiter kommentieren....
Korrigier das bitte auf ein sinnvolles Regelwerk und lösche diesen Unsinn wieder und dann sehen wir weiter...
Nun ist eine Verbindung sowohl über VLAN1 als auch VLAN10 möglich.
Nimm mal bitte NICHT die IP Adressen, denn die ändern sich logischerweise durch die Dynmaik von DHCP. Das macht also wenig Sinn, es sei denn du machst eine Reservierung im DHCP über die Mac Adresse.Nimm als Ausnahme mal die Mac Adressen dieser Endgeräte und trage die ein !
Die IPs dann natürlich wieder löschen.
Ist das Verhalten da identisch ?
Ein Zugriff vom LAN-Netzwerk auf das OPT1- Netzwerk ist jedoch weiterhin nicht möglich
Entsprechende Regeln die das erlauben hast du eingetragen ??Bedenke auch den Rückweg der Pakete also Antworten von den Geräten aus OPT1 ins LAN !!
Auch die Antwortpakete vom OPT1 Port müssen passieren dürfen ! Wenn du am OPT1 global den Zugriff auf LAN blockierst bleiben die Antwortpakete dort logischerweise hängen.
Sinnvoll ist es hier eine Regel zu erstellen die nur Pakete mit einem gesetzten "Established" Bit (Advanced Options)
passieren zu lassen von OPT1 auf LAN. So kommen Antwortpakete durch aber direkter Sessionaufbau von OPT1 auf LAN ist nicht möglich !
Weiterer, häufiger Fehlerpunkt bei Switch und APs:
Haben die ein Default Gateway oder eine Default Route gesetzt im IP Adress Setup ?? Ohne die ist natürlich eine Kommunikation in andere IP Netze unmöglich !
Sind noch Einstellungen zu machen,
Ja, wenn du eine Router Kaskade betreibst, dann kannst du die Block Bogon Regel am WAN Port aktivieren. Die kann übrigens generell aktiv bleiben den Bogons sind im Internet inexistente IP Netze die man immer blocken sollte.In einer Kaskade solltest du unten am WAN Port Setup noch den Haken entfernen bei "Block RFC 1918 IP networks". Klar, denn das kaskadierte Netz am WAN Port zum Internet Router ist ein RFC 1918 IP.
Ansonsten sind deine Regeln jetzt soweit OK.
OPT1 entspricht ja dem VLAN 1 auf dem angeschlossenen Switch. Dort ist mit dem Regelwerk dann nur Browser Zugang erlaubt. Alles andere geht dort nicht auch kein Ping usw.
VLAN 10 darf alles.
Wo hast du denn jetzt das CP aktiviert ? Vermutlich am OPT1 Port direkt, richtig ?
Bei normaler Funktion ist das VLAN 10 davon völlig unberührt wenn auf dem OPT1 das CP aktiv ist sollten alle VLAN 10 Clients davon völlig unberührt sein und weiterhin alles dürfen.
Solltest du dennoch Probleme haben solltest du das Konzept ggf. mal umdrehen. Sprich das Gastnetz was das Captive Portal hält eben nicht auf das native Interface legen sondern auf ein VLAN Interface.
In der Regel ist es ja auch so das man Gastnetze niemals auf das Default VLAN legt sondern immer auf ein dediziertes VLAN. In sofern ist dein Design da auch nicht ganz sauber.
Das wäre nochmal einen Versuch wert. Ich mache parallel mal ein Testsetup von dem Design auf einem APU Board.
Ich hatte das zwischenzeitlich auch im Testsetup laufen und konnte dein Verhalten nachstellen:
Möglicherweise ist das aber ein Bug wenns wirklich in der 2.1.5 funktioniert haben sollte.
Aber so gibt es ja damit einen Workaround !
Als Alternative könntest du hier im DHCP Server eine feste Reservierung über die Mac Adresse der pfSense eintragen:
Die FritzBox z.B. supportet sowas.
Dann kannst du das Interface im DHCP Client Mode laufen lassen bekommst aber über die Mac Adresse so immer eine "feste IP Adresse" vom DHCP Server des Routers.
Beides geht und ist sinnvoll !
Bei einer statischen Konfig ist das korrekt !
- Mit dem CP auf dem Parent Interface gehts nicht....oder nicht richtig.
- Setzt man das CP aber auf eins der VLAN Interfaces funktioniert es fehlerlos !
Möglicherweise ist das aber ein Bug wenns wirklich in der 2.1.5 funktioniert haben sollte.
Aber so gibt es ja damit einen Workaround !
Habe WAN von DHCP auf STATIC umgestellt:
Das sollte man auch immer machen wenn man in einer Router Kaskade arbeitet !Adresse außerhalb von DHCP-Range des Routers eingetragen.
OK, du meinst den kaskadierten Router davor, oder ?Als Alternative könntest du hier im DHCP Server eine feste Reservierung über die Mac Adresse der pfSense eintragen:
Die FritzBox z.B. supportet sowas.
Dann kannst du das Interface im DHCP Client Mode laufen lassen bekommst aber über die Mac Adresse so immer eine "feste IP Adresse" vom DHCP Server des Routers.
Beides geht und ist sinnvoll !
Ist das soweit korrekt?
Ja, ganz genau.Bei einer statischen Konfig ist das korrekt !