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?

"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!

Hi Sven,

Dazu wirst du sehr wahrscheinlich hier nicht viel herausfinden. Ich denke da wäre es sinnvoller, wenn du ggf. auf englisch im Package Subforum die Frage stellst bzw. den Package Maintainer direkt anschreibst. Warum läuft denn die Platte in kürzester Zeit voll (und wieviel ist Platte / kürzeste Zeit?) Und warum muss das "gelöst" werden? Werden da zu viele Daten geschrieben (Debugging o.ä.)? Ansonsten würde ich vermuten dass die Daten wohl gebraucht werden, sonst würden sie ja nicht geschrieben -> wie soll das dann gelöst werden?

Ich kenne die Problemstellung nicht, deshalb frage ich nacht :)

Gruß

Hi,

für die Erreichbarkeit braucht es nun noch einen NAT-Eintrag, der eine "Filter rule association" generieren wird damit Externe diese externe IP erreichen braucht es abschließend noch eine Roule auf dem externen Interface

Bist du dir da mit dem ersten Punkt sicher? Da die pfSense selbst ja den Traffic annimmt - Welchen NAT Eintrag musst du dir dann erstellen? Von extern auf localhost?
Und wenn ja und du eingestellt hast, dass für den Eintrag eine Filterregel erstellt wird, warum dann nochmals eine im nächsten Punkt erstellen?

Grüße

#push  :)