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.
:)

@viragomann:

Wenn HA richtig konfiguriert ist, also bei "Synchronize Config to IP" die Slave-IP eingetragen ist, und die Regeln für die Synchronisation gesetzt sind, sollte die VIP ganz von selbst am Slave auftauchen.

Stimmt - geht von selbst.
Ich hatte gar nicht nachgeschaut - nur überlegt, wie's gehen könnte! :-[

Gruss

bakunin

@xalx:

Und bei google gabe ich natürlich falsch gesucht, habe nicht gewusst, das es doc rule heißt, aber man lernt ja nie aus!

Das "doc" steht für "documentation", also das doc, das auch in der Adresse https://doc.pfsense.org/index.php drinnen steckt. "rule" ist ein Kapitel darin.

Aber freut mich, dass es nun funktioniert.

was genau möchtest du wissen?
ich betreibe nen multiwan bestehend aus einem KD 100Mbit und dem Magenta Hybrid M (50/10 VDSL + 50/10 LTE). pfSense läuft hinter dem Speedport Hybrid und hinter einer Fritzbox 7390 die am KD Modem hängt. Das funktioniert soweit auch.
Komme zwar nicht ganz auf die 100Mbit DOWN und 20Mbit UP vom Telekom Hybrid aber auf 80-85Mbit DOWN und 15-18Mbit UP. Im Multiwan ergibt das in der Regel 180-185Mbit DOWN und 20-24Mbit UP.

von eben:

nen älterer wert: