Hallo, klar könnte es ein Sicherheitsgewinn sein, das WLAN vom LAN zu trennen. Ganz vereint sind die Netze ja auch nicht, wenn sie auf der pfSense gebrückt sind. Du kannst immer noch auf jedem Interface getrennte Firewall-Regeln erstellen. Dazu müssen die beiden Parameter in System > Advanced > System Tunables "net.link.bridge.pfil_member" (1) und "net.link.bridge.pfil_bridge" (0) die entsprechenden Werte habe. Meines Wissens ist das jetzt standardmäßig so gesetzt, dass man die Filterregeln auf dem Interface setzen kann, war früher anders. Dann kannst du am WLAN Interface eine Regel wie die o.g. anlegen, nur eben als Quelle und Ziel das neue Netz (dasselbe) eintragen. Für Multicasts kannst du eine Regel erstellen, die das IGMP-Protokoll erlaubt, das dürfte aber ohnehin nur LAN-seitig nötig sein, wo vermutlich eh alles erlaubt ist. Und darunter eine Regel, die Zugriff auf LAN blockt. Dann noch eine, die den Traffic ins Internet erlaubt. Grüße

Ja, das sind erfolglose und unberechtigte Zugriffe auf einen meiner ssh Server (Port Forward vom Port 443 auf Port 22). Und es sind leider öfters fehlende Einträge zu verzeichnen. Unvollständige Log's sind weniger schön. Gruß Peter

Eine NAT Rule brauchst Du nicht, der Loadbalancer / Reverseproxy nimmt den Traffic ja aussen an und reicht ihn nach innen weiter.

Könnte gefixt sein: https://doc.pfsense.org/index.php/2.3.2-p1_New_Features_and_Changes Worked around a Chrome bug with regular expression parsing of escaped characters within character sets. Fixes "Please match the requested format" on recent Chrome versions.

Moin, keine Problem: https://www.freebsd.org/releases/10.3R/hardware.html#ethernet Insbesondere http://www.freebsd.org/cgi/man.cgi?query=em&sektion=4 Bezüglich WLan solltest Du aber Rat von Fachleuten einholen, da kann ich nicht weiterhelfen, vermute aber, Du kommst um eine Lösung mit Kontroller nicht umzu. Ob Unifi das wuppt? Nachteil ist natürlich wenn Du 5Ghz als Uplink nutzt wird es mit den wenigen nutzbaren Kanälen im 2.4 Ghz Band sehr eng… -teddy Nachtrag: Thema Blitzschutz nicht vergessen: https://www.lancom-systems.de/fileadmin/pdfs/products/WLAN_OUTDOOR_MANUAL_DE.pdf

Super, vielen Dank. Die fehlenden NAT Outbound Rules waren das Problem… Danke!

@groovesurfer: Habe auch noch versucht: Block Management LAN, Ziel: Firewall (self). Da kann ich dann aber nicht mehr ins Internet. Du meinst, "Block Public LAN", denke ich? @groovesurfer: Dann einfach den Port in den Advanced Settings auf z.B. 57 ändern, neue FW Rule Block Source: Public LAN, Ziel: Firewall (Self) Port 57? Günstiger ist ein Port oberhalb 1024. Wichtig ist, dass der Port nicht sonst in deinem Netz verwendet wir. Es gibt in Netz Listen über standardisierte Port, z.B. https://de.wikipedia.org/wiki/Liste_der_standardisierten_Ports Anstatt "Firewall self" versuch die Block Regel mit Ziel "Public LAN address". Es müssten aber auch die MM-Addresse blockiert werden und je nach Konfig auch die WAN, aber auf dieser sollte die pfSense GUI ohnehin nicht lauschen. Du kannst dir für die Sammlung an zu blockieren Addressen / Netzen einen Alias anlegen.

Sollte funktionieren. Du hast das eth2 der pfSense, an dem die VLANs liegen, nicht konfiguriert, aber hast du es aktiviert? VLANs lassen sich auch zu einem deaktivierten Interface hinzufügen.

IPv6 scheint bei KD nicht zu funktionieren. Man konnte das Problem nur durch Umstellung auf IPv4 lösen.

Danke für die Geduld und für die ausführliche Erklärung.

Es war ein Fehler im Provider CPE welches per se ab einer gewissen Firmware einen Schuss ab hatte: http://supportcommunity.swisscom.ch/t5/Diskussionen-und-Feedback-zu/IPv6-mit-PPPoE-passthrough-bei-My-KMU-Office/m-p/455806#M1958 IPv6 mit /48 Prefix Bezug funktioniert nun einwandfrei. Offen wäre noch /52 Perfix Bezug im DMZ Modus des CPE. (CPE erhält /48 und verteilt angeblich im Netz mittels PD /52) Hat jemand eine Ahnung wie ich das analog auf der pfsense hinbekommen? [image: delegated-prefix.jpg]

"pfSense/Chrome Firewall-Regeln bearbeiten Bug" Autsch. Ja, das ist ein ziemlich dämlicher Chrome RegExp Bug im Moment. Frage mich aber auch wie der von v52 in v53 reingerutscht ist ohne dass das mal jemand aufgefallen ist…

@jahonix: @JeGr: … ARM Branch ... auch auf anderen Kisten wie den Minnowboards läuft ist ebenfalls bekannt. Haben die Minnowboards nicht Intel Atom CPUs an Bord? Die brauchen die ARM Unterstützung doch gar nicht. Ich glaube er meint die SG-1000, statt das Minnowboard. Auf Twitter hat sich ja bereits ein Minnowboard mit 2xLAN blicken lassen, auch wenn im Shop nur ein "Router on a Stick" derzeit vorhanden ist. Mal schauen was 2.4 mit sich bringt und auf was es läuft!

Mit dem Wizard?? Kann ich nicht glauben. Das eingetragene Subnetz beinhaltet die Ziel-IP nicht. Dass dies vom Wizard kommt, mag ich bezweifeln. Entweder musst du 172.29.0.0/16 nehmen oder 172.29.174.0/24, was immer dein LAN ist.

Alles klar. Bisher hatte ich nie die DNS Einträge drin und hatte noch keine Probleme. Sind jetzt aber drin  :) Hast Du auch eine Lösung zu meiner ersten Frage?

Vom Routing her wäre das jedenfalls sauberer und bei DHCP ist es auch kein großer Aufwand.

Da hat virago natürlich recht :) Mein Beispiel bezog sich da eher auf größere Kisten in Rechenzentren o.ä. die auch nicht unbedingt an einer lokalen USV hängen. Mein Fehler :D

Super. Das war's. Meldung ist weg. Vielen Dank!