Kurioses Problem mit Unraid und Wireguard

[Mainfrezzer]

Ich habe hier ein sehr komisches Phänomen welches mich so langsam den Verstand kostet.

Ich versuche, ich verrate nicht wie lange schon, Server 2 Server access via Wireguard aufzusetzen. Gut, in der Theorie sollte das ja recht simpel sein.

Ich habe nen Tunnled Access auf Server 2 erstellt.

Ich kann auf den Server 2 zugreifen via mein Telefon, via Laptop und Wireguard Software, via VPN-Dockercontainer. Das funktioniert alles wunderbar. Unraid auf Server 1 will ums verrecken sich nicht sich mit den Server verbinden.

Wenn ich das Spiel umdrehe, Server 1 wie Server 2 einrichte, dann verbindet sich Server 2 zu 1 ohne Probleme. Ich hab das ganze auch mal versucht mit einem 3. Server und dort Verbindet sich Server 1 hin. Selbst zu meinen ganzen Servern bei externen Hostern funktioniert das ganze.

Server 2 steht hinter nem Speedport "Smart" 3 und ich denke das Stück macht Unraid aus irgendeinem Grund Probleme, ich hab nur keine Ahnung wieso. Hat da jemand ne Idee woran das liegen könnte?

Ich hatte kurzeitig Server 2 Server ans laufen bekommen, allerdings wollte das nur funktionieren wenn ich auf Server 2 den Server 1 via Wireguard-Netz-IP anpinge, sonst baute sich die Verbindung nicht auf.


Edit: Ich hab ja ganz ganz ganz stark die Vermutung dass die fehlende icmp response das Problem bei Unraid verursacht. Hab jetzt keine Lust zu gucken ob das so nun bei Unraid integriert ist, was anderes kann ich mir allerdings nicht erklären.

Edit #2: Hab gerade meine Fritzbox modifiziert und jap. Ohne icmp reponse funktioniert Unraids Wireguard nicht. FUCK

Edited September 14, 2023 by Mainfrezzer

[Ford Prefect]

23 hours ago, Mainfrezzer said:

Ich versuche, ich verrate nicht wie lange schon, Server 2 Server access via Wireguard aufzusetzen. Gut, in der Theorie sollte das ja recht simpel sein.

unraid spezifisch kann ich nicht helfen, da ich WG im externen Router nutze....klar geht Site 2 Site mit WG, aber das Routing muss stimmen,

 

Bedenke/beachte:

• Der Endpoint auf der anderen Seite des Peers ist die externe IP
• WG ist ein Mesh....alle WG-Peers nutzen am WG-Interface ein Transfer-Netz, zb 10.10.10.0/24
  Die IPs aus diesem Netz werden auf den jeweils lokalen Seiten im Routing als Gateways genutzt.
• Aber, sobald der Tunnel steht, können zwei Systeme auf der jeweils anderen Seite/Site nur kommunizieren/Services aufrufen (wie zB das unraid UI), wenn das jeweils lokale IP-Netz unterschiedlich ist. 
  beide Sites brauchen eine Route zum Netz auf der anderen Seite.
  Also zB:
  Server1 / Site1: 192.168.1.99 in 192.168.1.0/24 und Server2 / Site2: 192.168.2.99 in 192.168.2.0/24
  WG1/Site1-IP: 10.10.10.11 und WG2/Site2-IP: 10.10.10.12
  damit Route Site1 -> Site2: 192.168.2.0/24 GW 10.10.10.11 und Route Site2 -> Site1: 192.168.1.0/24 GW 10.10.10.12

....hope it helps.

 

[Mainfrezzer]

Die ganze Konfiguration war schon richtig. Das Problem ist der Speedport bzw Unraids implementierung von Wireguard. Das ausbleiben von "Ping" antworten, ich hab nicht genau geguckt welche spezifische icmp Abfrage da gestartet wird, macht Unraids Wireguardclient unnutzbar. Wundert mich dass das nicht schon vorher bemerkt wurde. Die ollen Telekomrouter sind ja doch sehr verbreitet. Aber ich denke mal dass die Leute die sowas hier aufsetzen ne Fritzbox haben und die hat, solange man nicht die Box manipuliert, keine möglichkeit ipv4 icmp anfragen zu blocken.

Achja:
Ich habs jetzt einfach so gelassen dass sich Server 2 zu Server 1 verbindet. Ist ja im Endeffekt egal und wahrscheinlich auch besser weil so Server 1 nicht warten muss dass die öffentliche IP von Server 2 geupdated wird.

Edited September 15, 2023 by Mainfrezzer

[Ford Prefect]

19 minutes ago, Mainfrezzer said:

Das Problem ist der Speedport bzw Unraids implementierung von Wireguard. Das ausbleiben von "Ping" antworten, ich hab nicht genau geguckt welche spezifische icmp Abfrage da gestartet wird, macht Unraids Wireguardclient unnutzbar.

Wiregurad an sich braucht davon (icmp) nix um zu funktionieren/einen Tunnel aufzubauen, aber ich kenne die Implementierung im unraid Plugin/Docker nicht.

Steht der Tunnel einmal braucht man auch kein icmp/ping zum Endpoint (Fritz, Router)...das keep-alive der peers untereinander hat damit auch nix zu tun.

 

22 minutes ago, Mainfrezzer said:

Ich habs jetzt einfach so gelassen dass sich Server 2 zu Server 1 verbindet. Ist ja im Endeffekt egal

Ja, zwei Peers können jeweils die andere Seite als Endpoint konfiguriert haben, ohne Konflikte. Aber es reicht, wenn eine Seite die Verbindung aufbaut (den Endpoint konfiguriert hat)...der Tunnel selbst ist dann bidirektional.

 

[Mainfrezzer]

2 minutes ago, Ford Prefect said:

Wiregurad an sich braucht davon (icmp) nix um zu funktionieren/einen Tunnel aufzubauen, aber ich kenne die Implementierung im unraid Plugin/Docker nicht.

 

 

Ja das ist ja das, was mich auch verwundert hat. Die ganzen VPN-Docker, Telefone und PCs hier im Netz haben sich wunderbar verbunden, nur Unraid nicht.

Ich hab gestern deswegen noch nen Bugreport aufgemacht. Habs ja dann hier getestet.

Server 2 zu 1 ging wunderbar.
Modifizier ich meine Fritzbox damit die icmp blockiert funktioniert Server 2 zu 1 nicht mehr. Kann nur daran liegen. Weil sonst funktioniert ja alles

[Ford Prefect]

22 minutes ago, Mainfrezzer said:

Ich hab gestern deswegen noch nen Bugreport aufgemacht. Habs ja dann hier getestet.

...man soll halt ein NAS nicht zum Router / Edge im Netz machen.

[Mainfrezzer]

Ist das einfachste Konstrukt um den externen Unraid Server zu dem hiesigen zu verbinden um sich gegenseitig Backupdaten zuzuschieben und Medien für Jellyfin jeweils zur Verfügung zu stellen. Ob ichs jetzt mit Wireguard mache oder die (aktuell) kaputte Tailscale variante ist am Ende egal^^

Selbstverständlich hab ich natürlich den Zugriff zum Unraid Webinterface untersagt, IPTables ist einfach wunderbar. Wobei das eigentlich nicht nötig gewesen wäre, ich vertraue der anderen Person doch schon sehr.

 

(Anmerkend und nachträglich, ist ja nur Server zu Server, kein Nat, kein LAN zu LAN, einfach nur ne simple Verbindung. Ich denke das ist noch sehr verkraftbar in der Hinsicht auf den Sinn und Zweck der Verbindung. Für etliche TB an Daten die über meine externen Server geschaufelt werden möchte ich dann doch nicht den Traffic bezahlen^^)

Edit:

Ich möchte, falls jemand etwas ähnliches sucht, natürlich nicht vorenthalten wie das ganze funktioniert

Folgendes Beispiel blockiert alles bis auf das Unraid Gui, bzw was auch immer auf tcp 80 läuft. Das TCP 80 kann man sich ja anpassen wie man lustig ist, z.b. 445 für SMB mit UD Plugin. Die FORWARD Regel(n) sind für Dockercontainer da.

(Lustige Anmerkung, selbst im Tunnel benötigt man icmp, lol. Man kann es zwar deaktivieren muss aber manuell vom Server zum Client pingen um ne Verbindung aufzubauen)
 

PostUp=logger -t wireguard 'Tunnel WireGuard-wgX started'
PreUp=iptables -I INPUT -s 10.12.12.2 -j DROP;iptables -I FORWARD -s 10.12.12.2 -j DROP;iptables -I INPUT -p icmp -s 10.12.12.2 -j ACCEPT;iptables -I INPUT -p tcp --dport 80 -s 10.12.12.2 -j ACCEPT
PreUp=ip6tables -I INPUT -s fc00:12:12:0::2 -j DROP;ip6tables -I FORWARD -s fc00:12:12:0::2 -j DROP;ip6tables -I INPUT -p icmpv6 -s fc00:12:12:0::2 -j ACCEPT;ip6tables -I INPUT -p tcp --dport 80 -s fc00:12:12:0::2 -j ACCEPT
PostDown=logger -t wireguard 'Tunnel WireGuard-wgX stopped'
PostDown=iptables -D INPUT -s 10.12.12.2 -j DROP;iptables -D FORWARD -s 10.12.12.2 -j DROP;iptables -D INPUT -p icmp -s 10.12.12.2 -j ACCEPT;iptables -D INPUT -p tcp --dport 80 -s 10.12.12.2 -j ACCEPT
PostDown=ip6tables -D INPUT -s fc00:12:12:0::2 -j DROP;ip6tables -D FORWARD -s fc00:12:12:0::2 -j DROP;ip6tables -D INPUT -p icmpv6 -s fc00:12:12:0::2 -j ACCEPT;ip6tables -D INPUT -p tcp --dport 80 -s fc00:12:12:0::2 -j ACCEPT

10.12.12.2 und fc00:12:12:0::2 ist die Wireguard-Netz-Client IP

Edited October 7, 2023 by Mainfrezzer
Code Modifizierung.