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)

@micneu ja, das thema ist gelöst.

thema scheint ja gelöst zu sein, gestatte mir aber mal die fragen:

wenn du wenig erfahrung hast, warum machst du dir es dann extra komplexer wenn du die sense als vm laufen lässt? habe ein nuc mit promox laufen. auf dem laufen mehrere container und vms. unter anderem die pfsense vm. warum die fritzbox? die fritzbox ist (noch) der haupt router wo die meisten geräte und wlan drüber laufen. weil man keine nordvpn verbindung in der fritzbox einrichten kann und ich ein bisschen basteln wollte, hab ich den nuc geholt. auf der 2ten nic vom nuc läuft jetzt eine permanente nordvpn verbindung. ist natürlich auch doof, dann ich die geräte, die an der pfsense hängen nicht über das fritzbox netz erreiche.. warum kein modem? habe gerade erst angefangen alles aufzubauen. ist alles noch nicht final und so wie ich es mir vorstelle. wird schon irgendwann kommen

sollte ich öfters eure hilfe gebrauchen, erstelle ich gerne ein netzplan. versuche so weit es geht ohne hilfe aus zu kommen :)

@kall32 Da zweifle ich mal kurz das Prinzip an ;) Das hört sich für mich an, als würde man das Pferd verkehrt herum aufzäunen.

pfSense steht am nähesten am Internet, es macht also Sinn, wenn die Sense Upstream ist bspw. für die PiHole(s). Somit würde es dann aber keinen Sinn machen, die Sense als DNS rauszurollen und dort dann die PiHoles als Upstream anzugeben, nur damit die wieder irgendwas im Internet als Forwarder haben, da die PiHoles kein Resolving per default machen.

Sinnvoller wäre da für mich:

PiHole(s) als Default DNS per DHCP rausgeben Intern Regeln, dass DNS erlaubt wird auf die PiHole IP(s) alles was intern DNS spricht auf PiHoles umleiten wenn was externes aufgerufen werden soll (redirect) In PiHoles pfSense als Upstream reinmachen pfSense Unbound im Resolver Mode laufen lassen in pfSense Regeln anlegen, dass intern nichts direkt gegen die Sense DNS machen darf (direkt an unbound) sondern alles via PiHole gefiltert wird

Dann wird Unbound sinnvoll genutzt mit DNSsec und Resolving (und nicht forwarding zu irgendeinem Datensammler) und intern wird durch PiHole aber ordentlich DNS gefiltert und kann über deren Admin UI sauber administriert werden.

Hab ich mit 2x Pis und Gravity hier zu Hause schon ewig so laufen und das brummt gut. Für Update/Redundanz einfach 2 PiHole Instanzen aufsetzen, 2. Instanz via Gravity an 1. Instanz dranhängen, dann muss man Blocklisten und Ausnahmen nur auf einer Instanz verwalten und hat trotzdem nen 2. PiHole als DNS zum Eintragen, dass es nen Fallback gibt.

Zusätzlich kann man ggf. noch ausgehend Port 853 (DoT) aus den internen Netzen verbieten und 443 auf bekannte DoH Server verbieten, damit irgendwelche internen Kisten den PiHole nicht "überspringen" können. (oder zumindest nicht so einfach).

Cheers

Wenn du dann eh schon mal dabei bist, dann kannst auch gleich ein schickes /22er Netz aussuchen und hast LAN; PV; IoT, Gastnetz schon mal sauber als /24er rumliegen.
Planst du mehr, nimmst halt irgendwas im Bereich /19, dann hast du 32 Netze für die interne Verwendung.
Passt dann auch gut, wenn du ein /59er Prefix vom Provider bekommst, so hast du auch hier gleich 32 Netze die du sauber mit Dual Stack versehen kannst.

Gerade PV würde ich von den IoT Seuche noch mal sauber trennen, denn du kannst ja nicht überall ein Tasmota drauf schieben.

@jegr Danke Jens! Nach einem Update wird der Patch vermutlich nur noch unter System / Patches angezeigt und kann gelöscht werden.
Gruß Micha