Ich habe mal hier einen Link gefunden:

https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html

Dieser Teil hat mir geholfen :)

Automatic Fix

The Bypass firewall rules for traffic on the same interface option located under System > Advanced on the Firewall & NAT tab activates rules for traffic to/from the static route networks which are much more permissive when it comes to creating states for TCP traffic and allowing it to pass. The rules allow any TCP packets regardless of their flags to create a state, and also utilize “Sloppy” state tracking which performs a less strict state match.

Es sind dann aber auch alle States der internen VLAN Kommunikation mit weg.
Kommt hier scheinbar aber nicht zum tragen, da flache LAN Struktur.

In dem Fall sehe ich eher eine Cold Standby als Zielführend an.

@be1001 Was @viragomann sagt. Man kann durchaus ein Gerät als GW eintragen, die Actions disablen und das dann zum Monitoren nutzen. Warum und weshalb kommt eben drauf an. Dauerhaft würde ich das da auch nicht nutzen, aber wenn man mal über nen Zeitraum bspw. nen Graphen braucht, wann die Kiste weg war oder ob die manchmal keine Antwort gibt, dann kann das helfen.

@nocling
Ich schaue mir das bei Gelegenheit nochmal an. Speziell in den Logs hatte ich blöderweise nicht geschaut. Momentan habe ich an diesem Anschluss einen GL.iNet GL-AR300M der per OpenVPN reinkommt. Wollte aber gerne direkt an der Fritzbox die VPN Verbindung, dass wirklich alle angeschlossenen Clients ohne "Gefummel" der Verbindung nutzen können.

Der Grund für die Last ist gefunden. Auf den drei VPNs gab es einen Trafficshaper. Wenn man den deaktiviert geht die Last weg.

Da das vorher nicht war ist das aber nicht die Ursache.

Ne Fritz kann aktuell nur IKEv1 Aggro Mode, P1: AES256 SHA512 DH2 :P2 ESP AES256 SHA512 DH2 und das auch nur über IPv4.

@tomnick said in IPV6, Pfsense und Fritzbox Problem:

Hilft das weiter? Man, IPV6 nicht so einfach....

Bei mir kriegt pfSense einen 60er und braucht danach leider einen Neustart.

@njord said in PFSense auf Hyper-V:

Und ja ich habe Erfahrungen mit Netzwerk und Virtualisierungen

Dann kannst du uns ja verraten, wie das in HyperV technisch angebunden ist. So wie in deinem Netzplan dargestellt - ich nehme an, der HyperV läuft auf dem PC, müssten beide ja mit einem Switch oder einer Bridge verbunden sein.
Dann müsste auch ein Zugriff vom PC möglich sein.

Haben die virtuellen Netzwerkkarten auch ein MAC Adresse? Also verrät HyperV diese auch?
Wenn ja, überprüfe mal, ob du das LAN am richtigen Interface konfiguriert hast, falls noch nicht gemacht. Mit dem arp Befehl kannst du auf der pfSense die MAC abfragen, wird aber, glaube ich jetzt, auch beim Zuweisen der NICs im Setup angezeigt.

Hatte gestern auch von Sophos die XG Home Edition aufm Hyper-V hochgezogen

Ich würde die Testkandidaten zum Vergleichen nebeneinander installieren, aber getrennt starten, und alle auf dieselben vSwitche hängen.

Wenn alles okay ist, versuch doch einfach eine Neuinstallation. Beim Zugriff aufs LAN darf es eigentlich keine Probleme geben, wenn die Netzwerkkonfiguration in Ordnung ist.

Reboot tut gut. 😉

@exordium Ne kein Problem, du weißt auch mein Augenzwinkern zwischen den Zeilen zu lesen 😄

Ich sage auch nicht, dass die 3.1-devel nicht noch an einigen Ecken ziemlich "rough" rüberkommt. Klar. Und dass es bspw. im CARP Betrieb eher suboptimal läuft. Auch da bin ich sofort dabei, weswegen ich schauen möchte, dass wir spätestens ab Januar für Anthony ne Testumgebung haben, auf der er selbst auch rumspielen kann um das besser zu machen.

Sicher ist auch die Integration DNS Blocking, interner Resolver, etc. je nach Einstellung ruppig. Python mode hat da gerade was RAM Verbrauch und Integration angeht viel gebracht. Ich nutze es selbst minimal bis gar nicht, da tatsächlich oftmals DNS meist außerhalb der pfSense schon behandelt wird (bspw. AdGuard oder PiHole Installation schon vorhanden).
Was wir aber vielfach nutzen und am Start haben ist die IP Blocklist Komponente und die läuft eigentlich auch ganz fein. Gerade - und das ist ein guter Punkt - wenn man wie du den default-auto-Regel-Block-Krimskrams abschaltet 😉 und statt dessen die Listen auf Alias Deny (oder Permit wenns ne Positivliste ist) schaltet und sich selbst Regeln baut.

Einziger Punkt wo man stolpern kann was mir noch einfiel:

Wenn man Regeln selbst erstellt, gibt es einen Hinweis, der gerne untergeht, weil der wirklich nur als Randnotiz irgendwo in den IP Lists in der Hilfe steht:

When manually creating 'Alias' type firewall rules; Prefix the Firewall rule Description with pfb_ This will ensure that that Dashboard widget reports those statistics correctly. Do not prefix with (pfB_) as those Rules will be auto-removed by package when 'Auto' rules are defined.

Quintessenz: als Beschreibung bitte was mit pfb_ reinschreiben, aber NICHT mit pfB_ sonst werden die ggf. rausgeworfen.
Das könnte ggf. ein Grund sein, warum deine Regeln vllt. aufgeräumt wurden ;)

Allerdings: inzwischen scheint mir der Hinweis eh nicht mehr zu stimmen, denn ich habe bei mir auf der Testkiste 2 Regeln drin ohne Description ohne irgendwas - einfach nur das Alias verwendet - und das wird im Widget inzwischen problemlos erkannt und angezeigt. Daher vllt. "Altlast"

Cheers

@slu said in OpenVPN | net30 / subnet | Inter-client communication:

It would be great if we could try that out in your lab.
Tomorrow?

Können wir gern heut abend durchspielen. VMs sind da, VPN ist schnell aufgesetzt und die Config schnell verteilt :)

@mathschut said in Wireguard Tunnel soll Verbindung über anderes Interface aufbauen:

Wenn ich das aber mache, kann der Server nicht zweite entfernte Netz vom zweiten Wireguard Tunnel erreichen. Hast du dafür eine eine Lösung oder soll ich dafür extra Thread auf machen?

Ich verstehe ja schon die Frage nicht ;)

Warum kannst du nicht ganz normal einen zweiten Tunnel bauen und brauchst dafür ausgehend die IP vom Wireguard Tunnel mit dem VPS? Stelle doch einfach die Seite des 2. Tunnels so ein dass sie Request von egal woher akzeptiert. Durch die CryptoKeys kann sich ja eh niemand anderes verbinden als du daher verstehe ich den Sinn nicht, das zwingend über die feste IP von WGtun1 und dem VPS drücken zu müssen? Das liest sich wie ein Problem das keines ist weil die Planung dazu irgendwie falsch ist :)

Cheers

@jegr said in Dynamic DNS Cached IP immer 0.0.0.0 und rot:

@asteroidnixnix Ja die Serverantwort ist ein kompletter XML Block. Anscheinend ist im DynDNS Modul für NC da was nicht 100% sauber oder NC hat (mal wieder) seine Serverantwort minimal modifiziert und somit geht dann das Update Modul nicht mehr, weil es nicht die korrekte Schlußantwort nach der IP Änderung bekommt.

Mit Custom wird ggf. nicht auf eine Antwort gewartet sondern direkt beendet und "gehofft" dass es korrekt ist. Oder man trägt im Textfeld selbst ein, was als Antwort gern gesehen wird. Wie man das genau formatiert steht in der Doku, man kann das aber ganz gut steuern damit und könnte bspw. auf <ErrCount>0</ErrCount> als "OK" warten. Bei einem Force Update mit gleicher IP müsste sich der Output ja entsprechend verändern und dementsprechend ein anderes Feedback zurückkommen.

Cheers

Ja genau, das denke ich auch. Ich hoffe, damit diese änderung aber bald behoben wird, dann kann ich wieder die Officielle Version verwenden. In der zwischenzeit nutze ich aber die Custom version.

@jegr Jau, denke auch, dir letzte Änderung war ein fritzos-update.
Habe mal "Flush all states when a gateway goes down" aktiviert und heute Morgen gab es das Problem nicht, vielleicht hat sich das also wieder erledigt.
Wobei, wenn ich gerade lese, was das macht, würde es vielleicht ausreichen, wenn ich stattdessen "Reset all states if WAN IP Address changes" aktiviere... Denn Gateways habe ich durch zig VPN-Clients so einige. 😉

@viktor_g

i have change my suricata_global conf from your line-commit, but i became a php memory error after paste and activating suricata with the extra-rule. and my deposited rules from all interfaces-rules were gone and i had to deposit / activate the rulesets them again.

is this a gui bug or it is not allow to take this change manually and i must wait for the official version from suricata?

BR

Achja, in der CoCoBox muss dann noch für das von dir verwendete RFC1918 Netz die Route zur pfSense auf der Seite der CoCoBox rein.
Hoffe du kannst einfach 192.168.0.0/16 auf GW setzen.

/56 is wohl richtig was ich so gelesen haben DG rückt ja auch nicht wirklich raus mit der sprache.

Die sense brauch nach neustart erstmal 5 min bis das ipv4 wieder anliegt und ipv6 nochmal deutlich länger.

besorg mir grad ne 7590 zum testen aber damits wirds denk ich sofort laufen

Ich würde sagen bei IP Blocklisting:

PRI1 (ggf. ausgemistet, manchmal sind da noch Feeds drin die inzwischen schon wieder gestorben sind) Je nach Bedarf PRI2, PRI3 Firehol Level 1 (ca. 2-4h) Firehol Level 2 (alle Stunde) eventuell Firehol Level 3 noch, da können aber inzwischen (leider) auch einige false positives drin sein (weil sich bspw. Dumpfnasen Kram auf Github oder Discord geteilt/gehostet haben und die IPs damit auf der Blocklist gelandet sind)

Bei Firehol 2/3 dann ggf. auf allowlisting/suppression achten. Wie bspw. Github FRA IP die aktuell noch auf FH3 drauf ist. Generell Suppression mit an haben, damit die internen IP Ranges rausgefiltert werden.

Bei PRI1 beim Feodo Tracker ggf. die aggressive List statt der default nehmen, da Emotet gerade wieder doll rumgeht.

Nicht nur von außen, sondern auch intern NACH außen abgehend rejecten!

DNS Blocking mach ich hier aktuell mit 2 PiHoles weil da nicht nur ich dran muss und die einfach leichter zu bedienen sind, aber sonst sind die genannten Listen auch gut. Steve_Black Liste ggf. noch auf Github die richtige Mischung raussuchen und mit hinzufügen. Da kann man sich dann auch viel Murks wegholen. (https://github.com/StevenBlack/hosts)