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

@tobi Nochmal Dein TUNNEL Netzwerk DARF sich nicht mit einem lokalen Netz überlappen. Das TUT es aber! Nimm für dein Tunnelnetz IRGENDWAS anderes. 10.20.30.0/24 völlig egal. Das ist lediglich das Netz, was deine Clients nach der Einwahl bekommen. Sinnvoll packt man das einfach mit dazu in den Range, den man sich definiert mit dazu, für den Fall dass man mal nen Tunnel baut und man dann eine schöne große Netzmaske macht, in der alle Netze - auch VPN - mit drin sind. Aber es dürfen keine Netze doppelt vergeben sein! Schon gar nicht wenn da Tunnelnetz mit Uplink zur Fritze kollidiert. Das ist mal ganz mies. Das "funktioniert" aktuell gerade so mal eben weil deine Fritze nicht auf .1 oder .254 liegt sondern auf irgendeiner komisch krummen IP .118 und .10 die Sense ist. Da hast du einfach nur Glück gehabt, weil OpenVPN sich dann automatisch .1 und .2 vom Tunnelnetz klaut und es deshalb zu keiner IP Kollision kommt. In jedem normalen Netz was .1 oder .254 als Gateways nutzt wäre dir die Konfiguration schon beim Einrichten mit Anlauf um die Ohren geflogen

@papa_joe said in Konfiguration sichern/rückspielen und/oder Festplatte klonen ?: Ich habe keine Ahnung was da im Hintergrund passiert, bzw. auf was da so ewig gewartet wird. Über Hinweise - vielleicht auch zum ganzen Verfahren - bin ich dankbar. Kann man ohne Diagnose bei dir im speziellen Fall nicht sagen. Das ist nicht das normale Verhalten und passiert so auch nicht. Was bei einem Full Restore natürlich passiert ist, dass sämtliche Config wieder hergestellt wird und damit auch Fehler die ggf. im laufenden Betrieb nicht aufgefallen sind sondern erst bei einem Neustart. Also ggf. sowas wie fehlerhafte DNS Konfiguration o.ä. Ansonsten wird im Anschluß an die Installation darauf vertraut(!), dass man Internet sauber anliegen hat, damit etwaige installierte Pakete in der Config wieder geladen, installiert und konfiguriert werden können. Wer also einen full restore macht ohne Internet wird da potentiell weniger Spaß haben, weil die Installation dann im Limbo hängt weil sie kein Netz findet und keine Pakete nachladen kann. Mehr bekommt man aber nur via Console und Logfiles raus, alles andere wäre Raten oder Astrologie ;)

@viragomann Ja das Problem sitzt ja immer vor dem Bildschirm ;-) Der Fehler war das umbennen.. keine Ahnung warum ich das vor Jahren gemacht hatte. Danke dir!

@ihaveastream Das erste, das der first level Support einem User empfiehlt.

@eyespeak Du wirst natürlich nach einer Umsetzungsmöglichkeit für Nginx suchen müssen. Ich habe mal eine solche gesehen und sie sieht ganz ähnlich aus. Ich habe bei Apache die Module proxy und proxy_http installiert. Die Konfig für meinen Photovoltaik Wechselrichter sieht dann so aus: # Photovoltaik Proxy <VirtualHost *:80> ServerName pv-meine.domain.eu ProxyPass / http://10.50.10.6/ retry=1 timeout=50 ProxyPassReverse / http://10.50.10.6/ </VirtualHost> Auf ProxyPass folgt das virtuelle Verzeichnis des VHosts (/), das auf den Proxy geleitet werden soll und dahinter die Ziel-Adresse. Hier kann auch ein spezieller Port mitgegeben werden. retry und timeout sind optional. Mein Wechselrichter schaltet aber nachts ab und ist damit nicht mehr erreichbar, daher sind diese Angaben hier ganz sinnvoll. TLS Offloading mache ich nicht, sollte aber auf gleiche Weise funktionieren, nur dass dem VHost noch eine Zertifikatskette zugewiesen werden muss. Nutzt du zufällig Collabora Online oder ein anderes Plugin in Dokker in Nextcloud? Das wird nämlich auch über ein Proxy ungebunden. Die Konfiguration dafür habe ich mir im Netz gesucht. Diese hat mich für die Einrichtung der weiteren Proxys inspiriert. Und eben genau in diesem Zusammenhang bin ich auf Nginx-Konfigurationen gestoßen. Wenn du aber nach einer Lösung für HAproxy suchst, könntest du bei der Nextcloud Community eher Erfolg haben als hier.

IPv4 oder auch IPv6? Für erstes reicht ein Alias in den alle RFC1918 Netze rein kommen. Dann kommt ein Deny auf diesen Alias in das LAN Netz. Netz zu Netz Zugriff musst du dann davor regeln, also freigeben. Unter die RFC1918 Regel dann eine Regel die IP auf any erlaubt im LAN für Internetzugriff. IPv6 wird ein wenig komplexer. Weil Clients hier 3 IPs gleichzeitig haben.

Danke erstmal @JeGr ! Funktioniert seit gestern problemlos. Ich habe sogar das Gefühl, dass die Browser auf dem Handy schneller laufen. Ich beobachte gerade noch, ob so auch die Fritz Geräte endlich mit Ihrem NTP arbeiten können, ohne dass dies immer extra freigegeben sein muss wie bisher.

@dogfight76 und zu deinem problem mit nordvpn. ich hatte 3 jahre lang nordvpn am laufen, lief ohne probleme nutze es aber nicht mehr deshalb keine möglichkeit mehr wie ich es konfiguriert hatte. PS: du solltest deinen grafischen netzwerkplan nochmal anpassen (wirst du hier öfter brauchen). denn wenn die fritzbox dein modem ist gehört es vor dein internet und dann erst die sense oder nicht? hier nochmal für dich als einsteiger wie du ordentlich fragen stellst :) https://forum.netgate.com/topic/154920/wie-stelle-ich-fragen-damit-man-mir-helfen-kann/1

@jegr said in mDSN/ avahi/IGMP - ich verstehe nur Bahnhof :( (Sky Q über VLAN Grenzen erreichen): Wenn ich einen Dienst habe der potentiell die Möglichkeit hat, Netzgrenzen zu überwinden, die man extra geschaffen hat, sollte man ggf. zweimal drüber nachdenken, was man wo wie korrekt konfiguriert hat. Ja und da meine Konfiguration eh viel Blödsinn hat (Unwissenheit, keine Idee wie es anders/ besser umgesetzt werden kann), werde ich es wohl zumindest vorerst nicht installieren. Vielleicht wenn ich irgendwann in naher Zukunft meine Konfiguration nach und nach von Blödsinn bereinige.

[image: 1635335430944-26ca4843-4c0a-4a93-8a6e-0043406696be-image.png] Nach Neustart : [image: 1635336011527-9bbaee5d-a18a-4427-ae33-8e2634b5b41b-image.png] Am Switch etc. kann es auch nicht liegen da ich mit dem Speedtest den Switch überspringe da das WAN Interface direkt mit dem Modem verbunden ist. BTW für später: Solche Tests sind etwas sinnbefreit, wenn sie nicht gegen die selbe Gegenstelle gehen, denn so kann niemand feststellen, ob die Leitungsgeschwindigkeit von der Gegenstelle oder von dir gedrosselt wird. In diesem Fall waren die Package Loss Angaben schon ein Indikator, dass da was mit der Leitung nicht stimmt. Aber man kann bei Speedtests auch manuell den Server einstellen - bei Vergleichen dann immer den gleichen nehmen, sonst hat man keine verwendbaren Daten :) Cheers

@noplan Soweit ich bei Exchange so grob noch weiß läuft deren RPC via HTTP/S also sollte das schon laufen wenn Front- und Backends halbwegs sauber sind. Ansonsten müssen sich die GruschelKasper aussprechen und klar sagen, was für Ports der RPC Rempel läuft :)

@theonlyone-0 Es gibt aber auch problemlos Modems wie das Vigor 165 dass VLAN7 ggf schon selbst übernimmt und dann einfach auf einem default untagged Port wie jedes andere Gerät auch ansprechbar ist und die PPPoE Verbindung angefordert bekommt.