Kai2

Danke für den Hinweis mit dem RAM. Hatte ich garnicht mehr auf dem Schirm. Darauf freue ich mich am meisten... Werde W-LAN technisch erstmal bei den Unifi APs bleiben bis zum umstieg auf Wifi6. Dann mal gucken was Mikrotik so zu bieten hat. Danke für die Hilfe. Grüße

ok, ich habe es wieder am laufen. Scheint teilweise ein Bug zu sein. In den einstellungen von Wireguard kann man sich die Serverconfig anzeigen lassen. Dort werden auch automatisiert die Routen erstellt. Und zwar werden jedes mal alle regeln gelöscht, sobald man die Verbindung trennt und neu erstellt wenn dieser wieder hergestellt wird. Habe also in der /etc/wireguard/wg0.conf meine Route eingetragen. Jetzt sollte, zumindest das, auch nach einem neustart funktionieren. Das alleine hat aber nicht geholfen. Ich musste außerdem in den Dockersettings die Einstellung „Host access to custom networks“ einmal deaktivieren, docker aktivieren, docker deaktivieren, „Host access to custom networks“ wieder aktivieren, docker wieder aktivieren. Das muss irgendwie ein Bug sein. KAnn ja nicht so gewollt sein. Das ist auch meine Idee. Werde demnächst umsteigen von Unifi auf Mikrotik weil ich mit den Routern von Unifi eher unzufrieden bin. Die Gui geht mir jedes mal mehr auf die Nüsse. Wollte mir einen Mikrotik CCR 2004 besorgen auch weil wir bald die Möglichkeit auf Glasfaser haben. Da macht meine kleine USG-3 schnell schlapp. Dann werde ich Wireguard im Router auf ein VLAN legen und fertig. Habe ich nicht irgendwo gelesen das du auch Mikrotik nutzt Ford Prefect?

Rolle rückwärts. Musste den Server neu starten. Seitdem geht nichts mehr. Sowohl die Kommunikation zwischen den Containern in verschiedenen vlans als auch wg0 funktioniert nicht mehr. Habe die Route wieder eingerichtet, ohne Erfolg. Bis zum Neustart hat alles so funktioniert wie ich es haben wollte. Keine Probleme. Firewallregeln sind die selben. Wie kann das sein? bin kurz davor unraid zu verbannen.

Ich habe die Lösung anscheinend gefunden. Habe mir die Routing Tabellen auf dem Unraid Server nochmal angeguckt weil es eigentlich nur daran liegen konnte. root@UNRAID:~# ip rule 0: from all lookup local 32763: from all lookup main suppress_prefixlength 0 32764: not from all fwmark 0xca6c lookup 51820 32765: from 172.31.200.0/24 lookup 200 32766: from all lookup main 32767: from all lookup default Über ip rule habe ich herausgefunden dass wg0 die tabelle 200 nutzt. root@UNRAID:~# ip route show table 200 default via 10.2.0.2 dev wg0 192.168.1.0/24 via 192.168.1.1 dev br0 192.168.40.0/24 via 192.168.40.1 dev wg0 In der table ist mir aufgefallen das 192.168.40.0 (VLAN40 in meinem Fall) versucht über das GW 40.1 über wg0 raus will. Kann ja nicht funktionieren. Ich frage mich nur wie diese route dahin gekommen ist. root@UNRAID:~# ip route del 192.168.40.0/24 via 192.168.40.1 dev wg0 table 200 root@UNRAID:~# ip route show table 200 default via 10.2.0.2 dev wg0 192.168.1.0/24 via 192.168.1.1 dev br0 root@UNRAID:~# ip route add 192.168.40.0/24 via 192.168.1.1 dev br0 table 200 root@UNRAID:~# ip route show table 200 Wie dem auch sei. Habe die Route gelöscht und durch 40.0/24 via 1.1 über br0 ersetzt. Jetzt kann ich über den NPM auf z.B. 192.168.1.200:3000 weiterleiten und bekomme, in diesem Beispiel jetzt den Firefox über meine Subdomain. Ich danke dir, lieber Ford Prefect für deinen Einsatz. Ich hoffe das hier hilft noch anderen. Grüße

Ja. Firefox im wg0 = IP vom VPN Provider Browser Lokal = IP vom ISP Nein, ich kann aus dem Firefox im Container mit wg0 auf das Webif zugreifen. Als Docker Netzwerk habe ich auch 172.17.0.0. Das 172.32.200.0 ist nur für wg0. Dann habe ich das richtig verstanden. Route 172.32.200.0/24 GW: 192.168.1.200 Das habe ich, meiner ansicht nach, gemacht. Ich habe für 172.31.200.0 und 10.2.0.0 Routen mit 192.168.1.200 als GW eingetragen. Wenn ich jetzt z.B. aus dem NPM Container nen traceroute auf z.B. 172.31.200.2 mache (Firefox Container in wg0) dann bekomme ich das: traceroute 172.31.200.2 traceroute to 172.31.200.2 (172.31.200.2), 30 hops max, 46 byte packets 1 192.168.40.1 (192.168.40.1) 0.702 ms 2.171 ms 1.628 ms 2 unifi (192.168.1.200) 2.802 ms 3.083 ms 2.215 ms 3 * * * 4 * * * 5 * * * usw...

Puh, das ist kompliziert. Ich versuche es mal… Also Firefox Container in wg0. Aufruf einer subdomain die auf einen Container in vlan40 weiterleitet funktioniert. Aufruf des gleichen Containers direkt über die IP funktioniert nicht. Aufruf von Unraid Web Inteface funktioniert. Wo kommt das Netz 172.31.200.0 eigentlich her? Was mache ich damit? Wenn ich die Routen erstelle nehme ich immer 192.168.1.200 als GW richtig? Dann brauche ich aber doch keine Netze mehr im Router zu erstellen oder liege ich da falsch? Soweit ich weiß werden die Anfragen vom NPM mit der IP des NPM durchgeführt. Bin dir sehr dankbar. Kann man hier eigentlich nen Bier spendieren? Grüße

Sorry ich meinte untagged. Habe mich verschrieben. Der Port ist passend konfiguriert.

Hallo Ford Prefect, danke das du dich mir annimmst. br1 hängt an tagged VLAN40 am Unifi Switch. Das VLAN ist nicht in Unraid konfiguriert. IPs werden nur in den Containern eingetragen Ich weiß nicht ob ich die Frage richtig verstanden habe. Ich hänge hier mal ein paar Screenshots an in der Hoffnung das es die richtigen Einstellungen anzeigt. Aus dem Firefox Container kann ich den Unraid Server anpingen. VLAN40 nicht. Das möchte ich aber auch garnicht. Im Router habe ich, nach dieser Anleitung, eine statische route für 10.2.0.0/24 eingetragen mit 192.168.1.200 als Gateway. (192.168.1.230 ist Adguard) Nein der Container läuft im wg0. Unraid macht anscheinend ein Portmapping. Deswgen dachte ich ich könnte einfach den npm auf 192.168.1.200:Port zeigen lassen. Geht aber nicht. Wenn ich den Container im Bridgemode betreibe bekomme ich sofort zugriff per npm. Ich denke schon. Zugriff von DMZ auf LAN ist gesperrt LAN auf DMZ ist frei. NPM habe ich testweise den zugriff auf LAN freigegeben, funktioniert. Was bedeutet die Tunnel IPs konfigurieren? Muss ich in der Firewall ein weiteres Netzwerk erstellen und die Regeln definieren? Wenn ich es richtig interpretiere macht wg0 kein Nat. Vielen Dank für deine Mühe. Grüße

Hallo, sorry für den ungelenkten Titel. Ich versuche mal meine Situation verständlich darzustellen. Mein Setup sieht aktuell folgendermaßen aus. Unifi Router, Switches, APs Wan - Statische IP Lan - 192.168.1.0 VLAN 20 IoT - 192.168.20.0 VLAN 40 DMZ - 192.168.40.0 Unraid Server 2x NIC 1 - br0 LAN - 192.168.1.200 1.2 - br0.20 VLAN 20 2 - br1 VLAN 40 wg0 Wireguard über ProtonVPN - VPN tunneled access for Docker Ich habe verschiende Container am laufen. Ich nutze das VLAN40 für Container die ich im Internet exposen möchte. Portweiterleitungen 80/443 laufen auf den Nginx Proxy Manager mit der IP 40.200. Von dort verteile ich auf die anderen Container im selben VLAN u.A. Emby, Baikal etc.. Läuft alles ohne Probleme. Ich habe jetzt einen Container den ich auch gern über das Internet erreichbar machen möchte, der aber über wg0 ins Internet gehen soll. Das Problem ist, wie schaffe ich es das ich den Container per Reverse Proxy erreiche obwohl er VPN nutzt. Ist das überhaupt möglich? Wenn ich das Webinterface des Containers lokal aufrufe, kann ich das über die IP des Unraid Servers (192.168.1.200) mit dazugehörigem Port. Ich habe es schon mit einer Firewallregel probiert NPM -> Unraid erlauben. Hat aber nicht funktioniert. Das gleiche Problem habe ich mit der kommunikation der Container untereinander. Sobald ich das Netzwerk wg0 auswähle funktioniert der Zugang zum Internet über VPN und lokal über die IP vom Unraid Server aber sonst nichts. Ich bin mit meinem Latein echt am ende und für jeden Tipp dankbar. Grüße

Same for me. Log: Initializing nextcloud 24.0.1.1 ... Upgrading nextcloud from 23.0.4.1 ... Another process is initializing Nextcloud. Waiting 10 seconds... Another process is initializing Nextcloud. Waiting 20 seconds... Another process is initializing Nextcloud. Waiting 30 seconds... Another process is initializing Nextcloud. Waiting 40 seconds... Another process is initializing Nextcloud. Waiting 50 seconds... .... then the Container stops.