Hi Rico

Danke für die Rückmeldung. Ich konnte es mittlerweilse lösen, hab die Schnittstelle zwar angelegt, aber nicht aktiviert.

Danke

Gruss

/status ... ich noch immer nicht dazu gekommen ... fffu*****

Nicht unbedingt falsch, nein. Es könnte aber auch ein rate-limiting für Prozesse sein (wie Curl) das man dann durch anderen User-Agent aushebelt. Hatte pfBlocker mit einer bestimmten Liste schon mal (weiß gerade nicht mehr welche), die Änderung auf anderen User-Agent hatte dann aber nur ein paar Wochen was gebracht, weil das dann ausgeweitet wurde (die sehen das in den Logs ja trotzdem!). Da aber BBCans eigene Liste mit in deiner Aufführung drin stand, würde ich da in seinem Unterforum nochmal gezielt nachhaken und das Debuggen, denn wie gesagt, es kann nichts allgemeingültiges sein, da mein Test-pfB die Listen bspw. problemlos abrufen konnte. Also ist da mutmaßlich irgendwas im Zusammenspiel am Danebengreifen :)

@tpf said in pfSense redundant an Switch Stack:

Danke für die Info.Dann lag ich ja grundsätzlich richtig. Der Stack kann zwei Uplinks. Muss über STP zwar irgendwie konfigururiert werden, da es sonst zu einer Loop führt. Allerdings sollte das ja machbar sein.

Hey Thorsten,

dann ist das aber kein LACP (normalerweise), denn LACP kümmert sich selbst um Loop Detection etc. Lieber nochmal genau nachlesen/nachschauen, wie gesagt nicht jeder Stack kann wirklich LACP über zwei unterschiedliche Backplanes. Wenn das dann doch nur ein Failover Bond ist muss das auch an pfSense Seite anders konfiguriert werden. Wenn man am Switch dazu mit (R)STP erst nochwas rumbasteln muss wäre ich auf der Hut, das klingt wie gesagt nicht danach, dass wirklich Active-Active LACP konfigurierbar ist.

Wenn doch - umso besser :)

Gruß Jens

Ziel "alle" bei der Regel auf dem LAN ist zwar Unsinn, denn der VPN Server hört nur auf die "LAN address" aber das ist in diesem speziellen Einsatz eh egal. :) Und das VPN Netz muss natürlich auf dem anderen Router des Netzes zur pfSense hin hinzugefügt werden.

@nobanzai said in Pfsense Gateway Down States Full:

Ich habe in der Doku gelesen: "The DNS Resolver can work with Multi-WAN but the exact configuration depends on the desired behavior and current settings."

Can/may work - richtig. Aber es ist eben nicht unbedingt trivial einfach und nicht sicher, dass es funktioniert. Schon alleine, weil einige ISPs ihre Netze abgesägt haben was DNS angeht oder es eben bei Resolving aus den Netzen heraus immer wieder Probleme gibt. Wir hatten das bei mehreren Kunden in Zusammenarbeit mit Netgates eigenem Support und die Aussage war immer bei Problemen: Resolving aus, Forwarding an (also nicht den DNS Resolver abschalten, sondern in den Einstellungen den Forward Mode anmachen!). Forwarding zu 2 oder mehr spezifischen DNS Servern, die man in General Settings auch manuell den beiden Interfaces zuordnet, funktioniert dann erstmal ohne Probleme egal was die Leitungen und sonstwas machen. Resolving wäre zwar schöner, aber nachdem auch immer mehr eh gern ihren gesamten DNS Traffic irgendwo hin schicken (Google, Cloudflare, whatever) ist das jetzt keine große Einschränkung - wenn überhaupt.

Habe ich da nur Glück, dass das klappt?

Wahrscheinlich alles zusammen. Glück, dass aus allen ISP Netzen heraus Resolving kompetent funktioniert, die richtige Einstellung im Resolver gefunden und Glück beim Regelset bzw. Failover, dass das Resolving sauber über die 2. Leitung geht und Abfragen macht. Hatten wir bei DSL Leitungen nicht ganz so viel Glück leider :/ Dann spielt auch noch rein, ob DNSSEC sauber läuft/laufen soll etc. etc.

https://docs.netgate.com/pfsense/en/latest/book/multiwan/interface-and-dns-configuration.html#dns-server-configuration

sagt ja hierzu auch, dass u.a. Default Gateway Switching funktionieren muss.

Daher ist es ggf. einfach leichter, wenn man zwei gute Forwarder hat die auch DNSSEC sauber schon validieren und man die als Forwarder nutzt bei Multi-WAN. Damit hat man an der Stelle einfach mit weniger Problemen und Abhängigkeiten zu kämpfen :)

Moment eine Fritzbox auf Seiten von Netz B? Wo ist die denn und warum spielt die eine Rolle? Ich dachte du hast auf beiden Seiten ne pfSense wozu dann noch eine Fritzbox im gleichen Netz? Das fängt an immer weniger Sinn zu machen wie gedacht ;)

Ja der Banditen Hinweis hat was für sich.
Cloudf wirds wohl eher werden... Mal schauen

Ach guck... da hatte ich selbst mit 2.4.4 Probleme - nicht mit hoher Last oder großem Paketverlust, aber mit dubiosem Verhalten was das Pingen über die FB angeht. Die hatte ich die ganze Zeit in Verdacht, da das Problem früher mit älteren FBs nicht auftrat. Ich habe aber seit der letzten Umstellungauf Vodafone jetzt mal testweise in der Box auf einem LAN Port den Bridge Modus aktiviert und siehe da, die pfSense hinter der FB bekommt dann eine eigene/andere public IP4 und kann sich ein v6 Netz holen, obwohl die FB trotzdem weiter rumroutet (getestet am FB WLAN, FB hat andere IP4 und anderes IP6).

Mit der Einstellung sind dann auch plötzlich die ominösen Ping Probleme mit dem dpinger verschwunden und auch andere seltsame Aussetzer... Wenn du die Option hast - ein Test ist es wert :)

Die Feeds sind vom pfBlockerNG Autor gepflegte "one-click" Lösungen, damit man fürs erste Aufsetzen schnell ein paar brauchbare Listen zusammen hat. Du kannst in dieser Ansicht nicht selbst irgendwas hinzufügen oder löschen. Wie gesagt, sind das lediglich Templates. Was du in deinen eigenen Listen aktiviert hast ist das Einzige was für die Installation bzw. den Service relevant ist. :)

OK, ist das ein Business Anschluß von UM? Und ist der umgestellt auf echtes Routing? Soweit das bei unseren Kunden in BW der Fall ist, war nach Umstellung über das Kundencenter der eigene Adressraum als /28 oder /29 Netz definiert mit einem Gateway und den anderen IPs als freie Vergabe. Wenn das der Fall ist, kann hier sauber CARP eingerichtet werden (1 IP pro Firewall und eine dritte als HA IP + alle übrigen IPs als Alias der HA IP).

VG Jens

Danke für Deine Antwort. Entschuldige meine späte Rückmeldung, aber es hat doch länger gedauert als vermutet, bis ich mir ein genaueres Bild von der aktuellen Situation machen konnte. Leider dauert es noch etwas länger bis zur Umsetzung. Ich melde mich daher später ggf. nochmal an dieser Stelle zurück. Bisher sind zu viele Variablen ungeklärt, sodass die Spekulationen vermutlich nicht zielführend sind. Also erstmal: Danke und bis später! ;)

@vigeland said in auf einer Seite Kable IPv6, Site2Site möglich?:

Nicht sehr freundlich. Thema ist "IPv6, Site2Site möglich" und genau um das Thema geht meine Frage und darum das keine Packete auf der einen Seite beim Aufbau ankommen.

Nein er hat dich korrekt darauf hingewiesen, dass Thread-Hijacking - also das Reingrätschen in andere Themen mit dem eigenen Problem - nicht freundlich und OK ist. Zudem hat er vollkommen recht, egal was im Thema steht, im Thema des OP steht ganz klar, dass er hier mit OVPN arbeitet. Dann kann ich nicht mit einer vollkommen anderen Konstellation, die ganz andere Komponenten benötigt zwischenrein grätschen und verlangen, dass ich jetzt gerne mein Problem gelöst haben möchte. Das ist wirklich nicht die feine Art und jede Netiquette weist da gern drauf hin. Zumal @Rico im Wording absolut korrekt und freundlich war mit Bitte und Danke. Neues Thema ist da der richtige Weg und jeder der kann wird dann auch gern dort helfen.

@pixel24 noch als Zusatz: Wenn die Seite der Freudin DSlite hat mit v6 würde ich tatsächlich eher mal versuchen, den Tunnel selbst schon mit IPv6 zu bauen - sofern dein Glasfaseranschluß v6 bietet. Denn wir haben da u.a. auch bei Kunden und Kollegen bei VPN dann gern das Problem, dass die MTU durch das DSlite so vermurkst wird, dass der Zugriff ziemlich ätzend wird. Wenn man das direkt via OVPN und IPv6 als S2S aufbaut, kann man aber trotzdem intern IPv4 mit IPv4 verbinden - egal wie sich Server und Client gefunden haben. Damit hat man dann keinen MTU Salat und intern trotzdem eine v4 an v4 Site2Site Kopplung :)

@reventix-GmbH said in [2.4.5] Kann keine User mehr anlegen:

Benutzer der Gruppe "admin" konnten das nicht.

Das war wohl ebenfalls ein Problem mit der Konfiguration, normal ist das nicht - nur sollte das angenommen worden sein.

Intel Core i7-7700
pfSense 2.4.5-RELEASE

AES-256-GCM 519 Mbit/s
AES-128-GCM 522 Mbit/s
AES-256-CBC 477 Mbit/s
AES-128-CBC 479 Mbit/s

-Rico

Hab inzwischen auch mehrere (Sub-)Netze und heute alles ein wenig umgestellt.

gfdsgfd.PNG

PS: Jetzt wo ich mir so meinen post angucke, fehlt mir noch eine IPv6 Regel für die VPNer. 😉

PPS: Weiter drüber nachgedacht und ist doch nicht nötig, da ich den betreffenden Hosts eh IPv6 entzogen habe, weil es anders nicht zuverlässig geht in meinem Setup. Hier, vermute ich, limitiert einfach pfSense, was das Management von IPv6 angeht.

pfBNG Habe ich entfernt - bringt leider nix. Es scheint wirklich nur für .intra-Domains zu geben...