Hmm, klappt trotzdem irgendwie nicht… naja, ich werde mich nochmal nach dem Urlaub dransetzen und intensiv mit dem Blocker beschäftigen. Danke für die Hilfe soweit!

@JeGr:

Dass es trotzdem empfohlen ist, liegt eher in der sinnvolleren Debugging und Netzlayer Verfügbarkeit weil man von außen sonst die Knoten direkt einfach nicht erreichen kann.

Das ist natürlich ein gutes "Pro"-Argument. Dann lass ich die Konfig so wie sie ist.

@lendrod:

Hallo,

zur Zeit ist da ja eine Login Page wo dann der Voucher Code eingegeben wird.

Zukünftig soll ja erstmal nur eine Seite sein wo halt die checkbox ist für AGBs gelesen und akzeptiert und die AGBs verlinkt.

Wenn ich das gemacht habe, soll der Gast für XX Minuten/Stunden/Tage Zugang zum WLAN bekommen

Wie setze ich das in Captive Portal um?
Hat das schon jemand gemacht?

Zum Thema "Störerhaftung" und rechlichem Schnickschnack weiss ich nichts, kann dazu keine Auskunft geben.

Wie ist denn Dein Internet-Zugang nun genau aufgebaut?

Ich gehe davon aus, dass das WLAN unverschlüsselt offen ist, und ihr den Local User Manager/Voucher-Manager der Pfsense nutzt.
-> Jeder kann sich ins WLAN einbuchen - erhält sofort eine IP-Adresse, lediglich das Captive-Portal verhindert einen Zugriff aufs Netzwerk/Internet solange kein Voucher eingegeben wurde?
-> Das der Zugang künftig über den Haken "AGB anerkannt" freigegeben werden soll, hat nichts mit dem Capitve-Portal der Pfsense zu tun. Das mußt Du auf der
    Capitve-Portal-Page separat lösen. Die Portal-Page so aufbauen, dass MAC-Adresse, IP-Adresse und das "AGB anerkannt" dann irgendwo mitgeloggt werden und nur der Zugang zum   
    Internet freigegeben wird, wenn der Haken "AGB anerkannt" auch gesetzt ist - meines Wissens stellt Pfsense für sowas keine Standard-Lösung bereit.
-> Da es hierbei keine Authentifizierung durch den Local User Manager/Voucher-Manager mehr gibt, hat die Portal-Seite keine Authentifizerungs-funktion mehr, die mit Pfsense zusammenhängt.
    die Authentication-method des CP ist dann auf "No Authentication" zu setzen. Das bedeutet, dass jeder der auf Deiner Portalseite irgendeinen Push-Button drückt, oder einen Haken setzt,
    dann automatisch Netzwerk/Internetzugang bekommt
–> Die Zeitbegrenzung kann über das "Hard-Timeout" und /oder "Idle Timeout" des CP gesteuert werden. Allerdings kann die Person sich nach dem Timeout sofort wieder einlogen indem die 
    AGB auf der Portal-Seite  wieder aktzeptiert werden. Das kannst Du dann mit den "Pass-through-Credits" limitieren.

Danke das war es

Da du nichts dazu geschrieben hast, wie du deinen Zugriff vom LAN überhaupt konfiguriert hat, kann ich dir da konkret auch keine Antwort zu geben. Deshalb war auch meine Antwort oben bereits, dass es m.E. um ein neues Thema geht und ihr euch beim Beschreiben von Fehlern bitte auch bemühen solltet, alle Daten sinnvoll zu liefern damit man helfen kann. Nur immer das Nötigste zu erzählen und dann ständig nachfragen zu müssen ist wie Kindern Details aus der Nase zu ziehen - das macht auf Dauer keinen Spaß ;)

Und da bei dir anscheinend ein Client-VPN auf LAN Seite mitspielt, hat das nichts mit diesem Thread zu tun, wo der OP ja nur ein RoadWarrior VPN definiert hat. Zumindest ist das das, was ich bisher aus deinem wenigen Informationen ausmachen kann.

da steht ja auch ubuntu.testzuhause.de soll auf xy umgeleitet werden. Ist das Absicht?

Natürlich nicht, ich Trottel  :o, der Host muss leer bleiben und nun klappt es auch…ja ja wenn man zuviel auf eien Stelle schaut....vielen Danke für die Unterstützung

Moin,

hatte ich auch. Bei mir hat das abschalten der IPSEC-Anzeige in der Startseite geholfen.

pfsense hat ja 4 Netzwerkkarten

1.10 (Netzbereich für Gäste)
2.10 (Netzbereich für "Freifunk" Projekt)
3.10 –> 192.168.3.118 (Fritzbox)
14.10 (hier sind meine eigene Klients und Server)

Hier noch 2 *.pcap Dateien

xn0.pcap
xn1.pcap

Für ein weiteres IPv6 Netz sehe ich für mich keinen Bedarf. Dies bringt mir bei Hetzner nichts wenn ich dem ESXi eine eigene IPv6 geben sollte da alles zur Link Local geroutet wird und der ESXi daher nicht abbekommen kann außer nach der routerVM.

Es geht an der Stelle nicht um den ESXi, sondern um ordentliches IPv6 Deployment. Wie gesagt es wird in jedem RFC und jeder Beschreibung stark davon abgeraten, irgendwas kleineres als /64 in Netzen zu verarbeiten. Das kann man ignorieren, muss sich dann aber damit rumschlagen, dass gewisse Dinge einfach nicht sauber funktionieren werden. Und gerade da v6 Adressen jetzt keine Mangelware sind, sollte man für ein valides und gültiges v6 Deployment über verschiedene Netze gar nicht erst mit herumstückeln und schneiden anfangen.

Natürlich gibt Hetzner default für einen Server erstmal ein /64, weil dort nicht von Virtualisierung per se ausgegangen wird. Und für eine Kiste wäre das Netz auch absolut genug. Wer aber mit mehreren Netzen, Virtualisierung und Routing anfängt, sollte auch bei v6 ordentlich und sauber arbeiten.

Hatten wir auch in diversen v6 Workshops schon die Diskussion. Quintessenz: "Das kannste schon so machen, aber dann isses halt kacke." :D

Eine Geschwindigkeitsbegrenzung pro Schnittstelle durchführen

Das ließe sich IMHO mit dem Shaper machen.

Einen Traffic Report pro Tag, das heißt einmal am Tag wird eine Mail versendet, in der steht welche Schnittstelle wie viel Traffic generiert hat

Eine Grafik lässt sich versenden mit der täglichen Ansicht (mailreport package). Aber Daten dazu werden m.W. nicht gesammelt. Dazu braucht es andere Pakete.

Am Sinnvollsten lässt du das aber gar nicht erst auf der pfSense machen, sondern lässt diese die Daten via Flows an einen Flow Collector senden und machst auf dieser Kiste dann die Traffic Auswertung etc.
Eine Begrenzung pro Schnittstelle bei Verbrauch X auf Geschwindigkeit Y ist IMHO nicht wirklich (schön) lösbar.

Gruß

@JeGr:

Sehr diffuses Fehlerbild… gibt es denn für ADSL2 irgendwelche Meldungen evtl aus dem PPP Log?

im log der pfSense steht dazu nichts. Werde aber morgen noch einmal die Meldungen vom Modem durchgehen.

Habe jetzt die Firewall auf einem anderen PC installiert. Selbiges Ergebnis, auch mit (viel) mehr Leistung.

Also des Rätsels Lösung war:

auf dem 192.168.1.2 eine Rule eintragen:

Protocol:IPv4* Source:172.16.100.0/24 Port:* Destination:LAN net Port:* Gateway:(Name des lokalen GW auf .1.1)

Was jetzt im Nachhinein logisch ist.

Vielen Dank und viele Grüße
JBBERLIN

Moin,

gerade ausprobiert, kann ich nicht bestätigen. Heise.de im Squid der pfSense gesperrt.
Habe in das Feld Bypass Proxy for These Source IPs" einen Eintrag "server" getätigt, mein Host tux wird nach wie vor zwangsbeglückt mit der Filterung. Habe dann den server als Proxy im tux eingetragen und ich komme wieder raus auf Heise.de.
Funktioniert bei Dir die Namensauflösung auf den Hosteintrag sauber?

-teddy

Dann wäre es vermutlich an der Zeit ein Bugreport zu erstellen (wenn es noch keinen gibt).

Ich habe gesehen das es mittlerweile eine neue Version von Squid gibt, mal schauen ob es dort dasselbe Problem gibt. Ohne den Destination Bypass weiß ich leider nicht wie ich es hinbekommen soll das meine Clients mit Windows Updates versorgt werden.

Man kann nicht mehrere Ports in einer Regel angeben, bestenfalls einen Bereich mithilfe der From und To Felder.

Für dein Vorhaben musst erst einen Port-Alias (Firewall > Alias) mit den drei Ports anlegen, dann in der Regel als Port "(other)" selektieren, dann kann im Feld custom der Alias ausgewählt werden.

Wäre eine schöne Erklärung, ist aber leider nicht so, betrifft auch andere Seiten. Bei vielen Seiten habe ich das Gefühl, dass sie langsamer laden.

Ich würde mal mit den erweiterten Netzwerkeinstellungen variieren, also TSO, LTO, Hardware offloading etc.