Nein, DoD ist für Einwählverbindungen, die an einem Zeit- oder Volumenanschluß genutzt werden. Heute bspw. UMTS Links. Hier wird die Verbindung nur aufgebaut, wenn tatsächlich Traffic nach extern geroutet werden soll. Ist das Interface down, wird auch kein Traffic durch bspw. DNS Anfragen oder Pings an das Gateway verschwendet (sofern es andere DNSe gibt die antworten bspw.). Somit kann man hier einen über Zeit oder Volumen abgerechneten Zugang einschränken, damit dessen Verbindung nicht versehentlich mitgenutzt wird oder unnötiger Traffic anfällt. (Deshalb nicht bei Bedarf herstellen, sondern nur bei Bedarf - hier liegt der Witz im Detail ;) )

TTL ist notwendig für den Eintrag den du via pfSense DDNS Client setzen lässt. Wenn du also bspw. up0.dyn.domain.tld setzen lässt, wird beim TTL von 300 bspw. die IP für 5min gecached. Kleiner als 5min wird bei den meisten DynDNS Anbietern selten angeboten und reicht m.E. nach auch aus. Man kann aber bspw. auch 180 für 3min machen. Die Frage ist da eher, was dein Provider zulässt als Minimum, da seine Server für diese Adresse dann ziemlich oft gefragt werden (kleines TTL heißt auch dass ggf. nach der Zeit die Anfragen direkt wieder an den Primary DNS durchschlagen) Öhm… bietet dir dein Provider wirklich(!) Dynamic DNS nach RFC2136 an oder willst du dir das selbst irgendwie hinfrickeln? Hier brauchst du nämlich DNSSec Daten, die auf dem DNS Server des Hosters entsprechend vorliegen müssen (du musst die dynamische DNS Zone - bspw. dyn.domain.tld - mit User/Key absichern und mit diesen Daten meldet sich dann der DNS Client beim DNS Server des Providers an). Wenn du keine Ahnung hast, was du dort eintragen musst, bezweifle ich, dass der Hoster das anbietet, denn sonst hätte der die Informationen mitgeben müssen. (Meistens ist es Key Type "Host" für einen direkten Eintrag wie oben - up0.dyn.domain.tld - und als Key Name wird ein sprechender Name vergeben und dann ein HMAC MD5 Key für das Key Feld) UDP (prot). Use Public IP ist nur für dich relevant, da es beeinflussen kann, was die pfSense dann als IP in den DynDNS Record reinschreibt. Da hatte ich zu ein Ticket aufgemacht, da - anders als bei den DynDNS Diensten - bei RFC2136 immer die WAN IP benutzt wurde. Wenn man aber vorne dran noch einen Provider Router und damit ein privates Transfernetz hatte, wurde in den A Record immer die private 192er (oder sonstige) IP der pfSense eingetragen anstatt der IP, die sie extern beim Provider hat. Das Feld wurde eingebaut um das Verhalten wie DynDNS und Co zu simulieren. Dazu wird ein externer Check gemacht, wie die IP nach außen ist und das statt der WAN Adresse eingetragen. Grüße

Das ist - sofern die DSL Lines jetzt schon sauber funktionieren - eigentlich kein direktes "Routing" Problem. Was du konfiguriert hast, geht aber nicht. 2 Interfaces dürfen nicht eine IP aus dem selben Subnetz haben! (Dürfen schon, aber nur in speziellen Fällen in spezfischen Konstellationen und das hat nichts mit deinem Problem zu tun). Wenn bei dir Outdoor und LAN wirklich ins gleiche Netz sollen (warum?), bleibt eigentlich nur eine Bridge über LAN und Outdoor. Der Traffic für den Outdoor Bereich (entsprechende Einteilung im DHCP vorausgesetzt), kann man dann per PolicyBasedRouting in einer extra Firewall Regel setzen. (Eine Pass Regel mit Source <von-bis bereich="" des="" dhcp="" für="" outdoor="">zu Destination any und in advanced Settings dann nicht Default Route, sondern direkt das Gateway für DSL2) Grüße</von-bis>

@Dodger: Über 2.1 bis 2.1.3 hin alle. @virago / Dodger: Ist bei uns ähnlich, allerdings haben wir da 2 SSDs als RAID1 was transparent an der pfSense als 1 Laufwerk ankommt (problemlos). Einzig einige Netzwerkeinstellungen mussten wir tunen, da durch die vielen (hyperthreaded) Kerne der CPU es ein Problem mit den MBufs gab. Das ist aber auch unter doc.pfsense.org zu finden. Einen SingleCore Kernel gibt es inzwischen allerdings nicht mehr, also keine Angst. Das war noch 2.0 und früher. Mit 2.1 gibt es nur noch einen Kernel, der automatisch multicore nutzt. Unser Problem mit den MBUFs wurde auch durch die Kerne verursacht, weswegen ich die Installation mit BootOptionen durchgeführt habe, um an den CPUs nichts drehen zu müssen. Hintergrund war, dass die Puffer pro Kern und Queue verteilt werden und es bei vielen Kernen dann zu viel für die Default Settings wurde. (https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards) Grüße

Der BSD network stack ist da etwas anders als Linux. Wenn aber bspw. das Netz 172.25.1.0/24 hinter dem Router 192.168.0.200 steht, würde ich das als Netzroute auch genau so in die pfSense eintragen und erwarten (war in der Vergangenheit auch immer so ;)), dass die Pakete dann auch direkt an 200 geschickt werden. Gruß

@robby: Aber kommst du bspw. von extern auf die pfSense (sollte nicht, es sei denn du hast den Port auf WAN geöffnet)? Bzw. siehst du einen fehlgeschlagenen Portzugriff auf 80/443 auf die pfSense WAN IP wenn du drauf zugreifst? Ich versuche nur auszuschließen, dass da überhaupt was ankommt ;) da aber das NAT ja läuft von innen nach außen gehe ich mal sicher davon aus. Die andere Frage wäre, ob du in den FW Logs was siehst. Also bspw. mal testen bei "wieistmeineip" o.ä. wie deine aktuelle IP ist und schauen, ob die im FW Log auftaucht beim Zugriff auf die media-Maschine. @csamaggi: Dein Setup sieht irgendwie verbogen aus. Die vmWare Einstellungen sollten schon wie bei robby aussehen, wenn deine VM nicht im LAN, sondern direkt "neben" der pfSense auf dem WAN Interface hängt, wird das nie funktionieren, da Hetzner einen MAC Blocker auf dem Port hat und die VMs dann nicht raus können. Deshalb muss man ja den Spaß mit Routing VM machen :) Grüße Jens

Erhellst du uns auch, wie?

Danke, daran lag es. In vorherigen Versionen musste der Haken nicht gesetzt sein.

Hi, sie scheint sich manchmal auf 115200 zu stellen. Das kannst du aber auch fest einstellen dann ist das vorbei.

Ich habs jetzt über PPPoE laufen. Mal sehen, ob der Fehler wieder auftritt

Hi! Wie kann ich das Durchsatzproblem erkennen/testen? Gruß Thomas

Hallo tommysense, vielleicht schreibst Du wirklich mal genauer die Config hier rein (vom CP, wo sind welche Netze konfiguriert, was hängt an welchen Port …) Hast du noch mehr WLANs, in die sich die Clients evtl. unbemerkt einbuchen können? Was passiert, wenn du alle User der CP-Gruppe in pfSense entfernst? Du tippst selbst auf DNS. Was hast Du da denn konfiguriert?

Entweder du erlaubst das der DNS Forwarder localhost benutzen darf oder du gehst in General Setup und setzt den hacken bei Do not use the DNS Forwarder as a DNS server for the firewall.

Servus, keiner ne Idee? Ich habe das Problem noch nicht lösen können. Es ist auch egal ob der Squid transparent ist oder nicht - es kommt immer invalid request. Für nen Tipp wäre ich sehr dankbar. Grüße

@JeGr: UDP/67 und /68 sind DHCP Pakete. Da läuft was anderes falsch, wenn die im Log auftauchen, es sei denn du hast 2 LANs und das eine Segment versucht ins andere zu funken. nein, hab nur eins, em0 wan und em1 lan, es hängen allerdings zwei router als ap drann. proto udp src any port 67 wo muss ich das eintragen? (bin noch der vollnoob^^) @viragomann: Broadcasts sind nur für das eigene Netzwerksegment bestimmt und werden daher an der pfSense Schnittstelle geblockt. Zuständig ist die "Default deny rule", also die die auf Pakete ansetzt, die von keiner anderen Regel abgehandelt werden. Diesen Traffic per Regel zu erlauben wäre sinnlos. Wenn du die Logs nicht sehen magst, kannst du sie mit einer Block-Regel im abfangen, für die du keine Logging aktivierst. Wo abfangen? (da fehlt das Wo, grins) Aber eigentlich scheint dieser traffic normalerweise nicht auf?

wenn du es einfach haben willst, mach eine Bridge zwischen VPN und Lan ;)

ich habe das gesamte lightsquid package bereits deinstalliert und wieder installiert, selbe fehlermeldung.. wird die konfiguration nicht gelöscht wenn das package deinstalliert wird?

Das ist das default color scheme für Farboutput und Consolen die das unterstützen. Entweder du gaukelst dem Ziel vor, deine Konsole unterstützt das nicht (xterm statt xterm-color o.ä.), oder die jeweilige User-spezifische .tcshrc anzupassen (dort ggf. die Zeile CLICOLORS mit # auskommentieren). Ob/wie blau dargestellt wird, liegt aber an deinem Terminal, die Farben sind wie gesagt default und nicht anders wie bspw. bei einem color-output unter Linux (Verzeichnisse sind nunmal immer blau dargestellt) :)

Hallo User1378, das Dashboard bis 2.1.x kann man leider nicht in der Breite verändern. Den Screenshot den du gesehen hast, stammt sehr wahrscheinlich entweder von einem Versuch, das Layout mittels responsive twitter theme besser zu gestalten (in Form eines alternativen Themes) oder von einem alten Patch (für 2.0.x), bei dem einige Dateien des jetzigen Themes modifiziert wurden, um mehr Spalten zu ermöglichen. Allerdings frohe Kunde: Diese Bemühungen haben dazu geführt, dass es in den aktuellen Quellen zu 2.2 bereits ein neues Theme gibt, welches sich der verfügbaren Bildschirmbreite anpasst (insbesondere bei Log-Views sehr praktisch), evtl. wir dieses Theme dann auch für 2.1-stable zurückportiert. Grüße Jens