Hi, Dementsprechend ist es schon paradox, daß das Thema MTU so selten Erwähnung findet. Da kann ich Dir nur recht geben. Die Standarteinstellung von 1500 sollte man nicht beibehalten, obwohl sich bei geringerer MTU-Größe meist die Logs beschweren. Ist wohl auch immer die Server-/Client-seitige DSL-Anbindung entscheidend, ob Probleme auftreten oder nicht. Ich hatte z.B. Tunnel über 2 Jahre mit MTU 1500 laufen, bis Clientseitig die DSL-Technik wechselte. Erst dann traten hier Probleme auf. Wobei ich in diesem Fall von MTU 1500, sogar bis auf MTU 1342 korrigieren musste, bis alles problemlos lief. Gruß orcape

Hallo Stefan, schön, dass es funktioniert. Mein nächstes Projekt war ein Teamspeak 3 Server in einer VM - Umgebung in Betrieb zu nehmen und diesen von außen erreichbar zu machen. Als VM benutze ich einen Qnap TS853 Pro auf dem kann man direkt virtuelle Maschinen laufen lassen. Er läuft. Sollte jemand wissen wollen warum….. bitte schreiben. Gruß Jörg

Hi, entweder gibt es das gewünschte Paket für die Version von pfSense noch nicht, oder es ist für die Plattform (NanoBSD) nicht verfügbar. Ich bin auf der aktuellen v2.2.2 und bei NanoBSD wird das Paket nicht angezeigt. Eine aktuelle 2.2.2 mit HD Installation habe ich gerade nicht zur Hand. Grüße

Zwischenupdate: … die Sinnhaftigkeit der Portumstellung für die WebUI zweifle ich inzwischen an. Die WebUI war sowieso nur aus dem LAN erreichbar, damit also eigentlich die externe IP nicht betroffen ... Aber geschadet hat's nichts. Mir ist inzwischen noch ein anderer Fehler aufgefallen: einer der von aussen erreichbaren Server steht in einer DMZ. Vermutlich war es also notwendig, die Durchlass-Regel auch für die DMZ zu erstellen. Das habe ich getan. Einen Ausfall habe ich seit der Änderung nicht mehr bemerkt, aber was nicht ist, kann ja noch werden ... :-( Gruss E

die Firewall an sich kann nur Ports und IP's blocken. Die müsstest du wissen. Ansonsten mal google befragen. Da findet man die bestimmt. https://support.google.com/drive/answer/2589954?hl=de Es gibt dann noch die Möglichkeit mit einem Proxy etwas mehr zu machen wie mit SQUID z.B. kommt eben drauf an was du genau machen willst. Wenn du den Traffic nur lenken willst dann geht das auch ohne Proxy. Musst eben die IP's bzw. die Ports wissen.

pfBlockerNG just collects and parses the lists. It's actually pf (packet fence) in FreeBSD that does the actually blocking. Unfortunately pf is very sensitive and will crash with a single error in any table. If I can get a copy of the list, I can adjust the parser.

Hi viragomann, es mag sein, dass IP Adressen auf einem Interface gleichwertig sind. Jedoch verbirgt sich hinter dem Alias "WAN Address" immer nur eine. Das Problem in meinem Fall bestand darin, dass beim Beziehen einer neuen IP Adresse über DHCP statt der neuen öffentlichen Adresse das IP Alias als WAN Address gesetzt wurde, wodurch natürlich keine Verbindung ins Internet möglich ist. Ein Gateway für den IP Alias ist nicht gesetzt, ist auch garnicht nötig. Ich habe für alle Subnetze hinter der Firewall entsprechende manuelle Outbound NAT Regeln gesetzt (automatische Erstellung von Regeln ist deaktiviert). Die bestehende Konfiguration hat auch vollkommen korrekt funktioniert, ein Problem bestand erst nachdem das WAN Interface eine neue IP Adresse bezogen hat.

Sorry für den Push … das Problem ist für mich nicht zu lösen ohne Hilfe... Also wie kann ich VoIP-Traffic priorisieren der von unserem LAN durch einen OpenVPN-Tunnel zu einem VoIP-Telefon auf der anderen Seite des Tunnels geht? gruß

Kann mir bitte mal jemand meine Erwartungen kommentieren. Ich erwarte nämlich folgendes Verhalten: 1. Beim Umschalten von GW A auf B kommt es zu kurzen Unterbrechungen bestehender  Verbindungen 2. Ein ping -t www.google.de von einem Client aus kommt nach kurzer Unterbrechung wieder von selbst hoch 3. Der OpenVPN-Tunntel baut sich erneut auf 4. Ping -t auf einen Rechner am anderen Endes Tunnels kommt wieder hoch 5. Ist GW A wieder online, schaltet alles wieder zurück von B auf A 6. Beim Abschalten von GW B dürfte folglich gar nichts passieren Folgendes passiert OHNE Eingreifen meinerseits (State Reset): 1. Jupp 2. Nope. Ping kommt nicht selbstständig hoch 3. Jupp, 5 Pings Aussetzer und schon gehts weiter. 4. Jupp, 5 Pings Aussetzer und schon gehts weiter. 5.   a)Ping -t aus 2. kommt wieder. Es wurde also keine neue Route gesucht   b)Ein Ping Verlust und der Tunnel steht wieder, Ping läuft 6. Jupp Folgendes passiert MIT Eingreifen meinerseits (State Reset): 1. Jupp 2. Nope. Ping kommt nicht selbstständig hoch 3. a) Tunnel steht wieder, Ping geht weiter State Reset: 3. b) Ping -t www.google.de ist nach State Reset wieder da 4.Tunnel läuft immer noch 5. Tunnel schaltet zurück auf GW A, ein Ping Verlust. ping -t www.google.de läuft weiter. 6.  ping -t www.google.de läuft wieder nicht! Ping hat also NICHT auf GW A umgeschalten. Folgende Konfig: Aktuelle pfS mit zwei static WAN.  Haken bei "State Killing one Gateway Failure" ist drin (default) Folgende Konfig: Aktuelle pfS mit zwei static WAN. 1. GW A Tier 1     GW B Tier 2 2. GW B Tier 1     GW A Tier 2

Ein Fehler 5.0.5? Wie sieht der aus bzw. wo tritt der auf? Soll das ein Webserver 505er sein? Der wäre wirklich selten und sollte auf dem Gerät im Syslog zu finden sein, ggf. mit etwas mehr Info, was da falsch aufgerufen wird.

Heute wurde ein neuer Rekord aufgestellt… 1622 Emails wegen einer Großstörung (ca 9 Std. down) bei Kabeldeutschland. Mein Postfach hat sich gefreut. Schönes Wochenende

Danke, jetzt klappt Alles. Gruss bakunin

Da ich nicht weiß auf WAS eigentlich deine pfSense gerade läuft wird das schwer…

Schritt eins ist geklärt - es lag wohl daran, dass keine Schreibrechte bestanden.

Hallo, der Chip ist eingetroffen. Habe diesen gleich eingebaut. Das System hat Ihn erkannt und ich konnte den Chip ansprechen und diesen in Pfsene parametrieren. Danke –------------------- Closed

Vielen,  vielen Dank, ein perfekter Tip. Mit dem 32bit-System ist alles gelaufen. :)