Wireguard - ufw Port Forward auf localhost

    Ich habe gerade einen Knopf in der Leitung, weshalb ich mich an euch wende. Ich habe auf einem VPS mit Ubuntu 24.04 eine Server-Anwendung die auf http://127.0.0.1:9000 horcht. Der Client dazu befindet sich auf meinem PC zu Hause. Als Firewall benutze ich auf beiden Seiten ufw.

    Jetzt habe ich Wireguard eingerichtet. Dabei nutzt Wireguard das Netzwerk 10.121.1.0/24. Der Server hat daraus die Adresse 10.121.1.1 und mein PC die Adresse 10.121.1.2. Horcht der Anwendungs-Server auf dem VPS auf alle Adressen, also z.B. auf http://0.0.0.0:9000, dann kann ich mit curl http://10.121.1.1:9000 problemlos über Wireguard auf die Anwendung zugreifen. Damit das soweit funktioniert habe ich in der ufw auf dem Server folgende Regeln gesetzt:

    Code
    To                         Action      From
--                         ------      ----
51820/udp                  ALLOW       Anywhere                  
10.121.1.1 9000/tcp on wg0 ALLOW       Anywhere

    Aber was, wenn meine Anwendung auf http://127.0.0.1:9000 hört? Bis jetzt habe ich das nicht hinbekommen.

    Ich nutzte Wireguard schon vorher, aber da lief die Anwendung in einem LXD/LXC Container und ich konnte das Problem über das Forwarding an den Container lösen. Jetzt habe ich aber keine Ahnung, wie ich das so hinbekommen kann, dass der Port 9000 der über wg0 reinkommt sozusagen an 127.0.0.1:9000 weitergeleitet wird.

    Die folgenden sysctl-Settings könnten noch von Bedeutung sein. Das sind die aktuellen Werte:
    sysctl net.ipv4.ip_forward = 1
    net.ipv4.conf.all.route_localnet = 0

    route_localnet auf 1 zu setzen hat bisher nichts gebracht, deshalb habe ich es wieder auf die Vorgabe zurückgesetzt.

    Auf dem VPS läuft übrigens ansonten noch gar nichts. Also kein Docker oder LXD oder sonstwas, das ufw oder iptables beeinflussen könnte.

    Was hab ich noch nicht verstanden?

    Zitat von pgloor

    Horcht der Anwendungs-Server auf dem VPS auf alle Adressen, also z.B. auf http://0.0.0.0:9000, dann kann ich mit curl http://10.121.1.1:9000 problemlos über Wireguard auf die Anwendung zugreifen.

    Natürlich. Und genau da ist auch das Problem, wenn du den Server nur auf 127.0.0.1 lauschen lässt. Denn dein Client schickt ja keine Pakete mit der Ziel-Adresse 127.0.0.1, sondern mit Zieladresse 10.121.1.1. Da lauscht aber kein Server. Der Aufruf funktioniert, weil das lauschen auf 0.0.0.0 dazu führt, dass auf allen Interfaces gelauscht wird - auch auf 10.121.1.1.

    Du hast also zwei Möglichkeiten: Entweder eine Portweiterleitung mit NAT (NAT muss sein, da 127.0.0.1 auf deinem Client nicht ins VPN geroutet wird), oder du lässt den Server auch auf 10.121.1.1 lauschen (0.0.0.0 ist nicht erforderlich). Im zweiteren Fall musst du vermutlich dafür sorgen, dass der Server erst gestartet wird, wenn der Tunnel schon existiert.

    Ich denke nat ist das Zauberwort. So was in der Art in den before rules?

    Code
    *nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 80 -j DNAT --to-destination external_ip:80
COMMIT

    Ich werde mir das am Donnerstag oder Freitag mal anschauen.

    Das einzige was dagegen spricht auf der 10.121.1.1 zu lauschen ist, dass ich noch lokale Prozesse habe, welche über die gleiche Schnittstelle auf die API zugreifen. Ich dachte über eine Portweiterleitung wäre am einfachsten.

    Ich werde nochmals einen Versuch starten und falls es nicht klappt, nutze ich einen Proxy. Mir ist wichtig, dass die Lösung so einfach und klar wie möglich ist. Edge-Cases von denen man nicht so recht weiss, was dahinter steckt, mag ich nicht. Zur Zeit habe ich auf all meinen Servern einen Proxy, aber ich dachte, dass ich mir das sparen kann.

    Danke für eure Hinweise. Ich hatte gestern einen etwas stressigen Tag - Serverumzug etc - an dessen Ende ich vor lauter Bäumen den Wald nicht mehr gesehen habe.

    Meine Lösung: Wireguard, wie gehabt. Nichts weiter geändert. Auch ufw, belassen wie es von mir oben in #1 beschrieben ist. Dann Caddy installiert und konfiguriert.

    In /etc/caddy/Caddyfile habe ich im wesentlichen diesen Eintrag hinzugefügt:

    Code
    # Access demo from home LAN
:9000 {
    bind 10.121.1.1
    reverse_proxy localhost:9000
}

    Anschliessend das Caddyfile mit sudo caddy fmt --overwrite /etc/caddy/Caddyfile sauber formattiert und mit sudo systemctl reload caddy Caddy neu gestartet. Dann, nach einen ersten Test, den Server neu gestartet und weitere Tests mit der echten Anwendung gemacht. Im Rahmen einer halben Stunde war alles erledigt.

    Mit dem ufw *nat Prerouting hätte ich mich intensiver befassen müssen, denn beim ersten Versuch bin ich gar nicht mehr auf den Server gekommen und musste zuerst mal über das Rescue System die Datei /etc/ufw/before.rules wieder korrigigieren.

    Nginx wäre auch eine Lösung gewesen, aber ich kenne Caddy schon lange und besser. Es kann aber durchaus Fälle geben, in denen Nginx die bessere Wahl, oder sogar notwendig ist.

    Ich bin jetzt mit dem was ich mit dieser Lösung erreicht habe sehr zufrieden, zumal ich damit ausschliesslich Systemkomponenten verwende, die ich aus diversen Projekten bereits gut kenne.:)

    Einmal editiert, zuletzt von pgloor (11. März 2026 um 16:38) aus folgendem Grund: IP korrigiert

    Was meine Server-Software betrifft, so ist es nicht so trivial. Sie ist modular aufgebaut und unterscheidet zwischen internen und externen Schnittstellen, bzw. Ports. Das ist zwar alles konfigurierbar, war mir aber für meine Zwecke zu komplex. Ich brauche die Verbindung über Wireguard nur um ein Modul zu testen an dem ich arbeite und so kann ich auf dem Port und der Schnittstelle aufsetzen, die normalerweise konfiguriert und verwendet wird.