@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

@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.