WireGuard Site-to-Site mit UDM SE (Client) zu VPS (Server) – Tunnel Connected, aber kein Traffic!

  • Hey Leute,

    ich bin grad dabei, mein Heimnetzwerk nach einem ziemlich detaillierten Plan aufzusetzen und hänge leider an einem echt hartnäckigen WireGuard-Problem fest. Ich habe schon einiges probiert, aber ich komme einfach nicht weiter und brauche dringend eure geballte UniFi- und WireGuard-Erfahrung!

    1. Was ist mein Ziel / Wie soll es aussehen?

    Ich will mein Heimnetzwerk sicher über einen Netcup VPS von extern erreichen, ohne Dienste direkt an meinem Heimrouter (UDM SE) ins Internet zu exponieren. Der VPS soll als WireGuard Server/Hub fungieren und der zentrale Eingangspunkt sein.

    • Site-to-Site-Tunnel: Der VPS (10.10.10.1) soll einen WireGuard-Tunnel zur UDM SE (10.10.10.2) aufbauen. Die UDM SE fungiert dabei als WireGuard Client, da mein primärer Glasfaseranschluss Carrier-Grade NAT (CG-NAT) hat und die UDM SE deshalb keine eingehenden Verbindungen annehmen kann.
    • Client-to-Site-Tunnel: Externe Clients (z.B. mein MacBook) verbinden sich ebenfalls mit dem VPS (10.0.0.0/24).
    • Relay-Funktion: Der VPS soll den Traffic von externen Clients über den etablierten Site-to-Site-Tunnel zur UDM SE und von dort ins Heimnetz weiterleiten.
    • Reverse Proxy: Ein Nginx-Reverse-Proxy auf dem VPS leitet HTTPS-Anfragen ebenfalls über diesen Tunnel an interne Dienste weiter.

    2. Mein aktuelles Setup:

    • Heimnetzwerk (UniFi UDM SE):
      • Gerät: UniFi Dream Machine Special Edition (UDM SE)
      • WAN1 (Primär): Glasfaser mit Carrier-Grade NAT (CG-NAT)
      • WAN2 (Sekundär/Temporär Primär für VPN-Tests): Telekom DSL, ohne CG-NAT (Ist aktuell für VPN-Tests als Primär eingestellt)
      • Interne VLANs (alle 192.168.X.X/24, zusammen 192.168.0.0/16): Infrastructure (10.x), Home Assistant (20.x), Services (30.x), Family (40.x), IoT (45.x)
      • WireGuard Client Konfiguration (S2S_to_VPS_CGNAT in Settings > VPN Client):
        • Connection Status: Connected (Das ist das Verrückte!)
        • Local IP: 10.10.10.2/24
        • Remote IP/Hostname: [UDM_SE_WAN2_PUBLIC_IP]
        • Remote Port: 51820
        • Public Key: [PUBLIC_KEY_VPS]
        • Allowed IPs: 10.10.10.1/32, 192.168.0.0/16
        • Persistent Keepalive: 25
      • Firewall Regel (WAN In):
        • Name: ALLOW_S2S_FROM_VPS (ID 200000)
        • Action: Accept
        • Category: WAN In
        • Interface: WAN2 (aufgrund des CG-NAT-Workarounds)
        • Source: Network, 10.10.10.0/24 (WireGuard VPN Subnetz vom VPS)
        • Destination: Network Group, ALL_HOME_VLANS (enthält 192.168.10.0/24 bis 192.168.45.0/24)
        • Protocol: Any
        • Logging: Yes (aktiviert)
      • Associated Policies: Sind leer/deaktiviert, um Konflikte auszuschließen.
    • Netcup VPS:
      • Betriebssystem: Debian 12 (Bookworm)
      • Public IP: [VPS_PUBLIC_IP]
      • SSH Port: [SSH_PORT] (geändert von Standard 22)
      • UFW Firewall Status (sudo ufw status verbose):
        • Status: active
        • Default: deny (incoming), allow (outgoing), deny (routed) (Standardeinstellung für FORWARD ist deny).
        • Erlaubt Ports (ALLOW IN Anywhere): [SSH_PORT]/tcp, 51820/udp, 80/tcp, 443/tcp (IPv4 & IPv6).
      • IP Forwarding: net.ipv4.ip_forward = 1 (aktiviert)
      • WireGuard Konfiguration (/etc/wireguard/wg0.conf):

      • WireGuard Status (sudo wg): Zeigt beide Peers (UDM SE und MacBook) als aktiv an, mit aktuellem "latest handshake" (wenige Sekunden alt) und bidirektionalem Transfer-Traffic.

    3. Das eigentliche Problem & Was ich schon probiert habe:

    Obwohl der Tunnel laut sudo wg und der UDM SE App "Connected" ist und Handshakes stattfinden, kommt kein Datenverkehr vom VPS in mein Heimnetzwerk.

    • Pings vom VPS ins Heimnetz (z.B. ping 10.10.10.2 oder ping 192.168.30.13): 100% Paketverlust.
    • UDM SE Firewall-Logs: Keine Einträge von Pings vom VPS. Das bedeutet, die Pakete erreichen die UDM SE Firewall gar nicht erst.
    • VPS IP Forwarding: Ist aktiv (net.ipv4.ip_forward = 1).
    • VPS Routing-Tabelle (ip route): Hat die korrekte Route 192.168.0.0/16 dev wg0 scope link. Der VPS weiß also, dass der Traffic ins Heimnetz über das wg0-Interface muss.
    • VPS UFW: Wurde temporär deaktiviert (sudo ufw disable). Problem bleibt bestehen. Dies ist sehr verwirrend, da die UFW dann eigentlich nicht blockieren sollte.
    • Workaround mit WAN2 (DSL): Habe extra den Site-to-Site Tunnel auf WAN2 (Telekom DSL, ohne CG-NAT) umgestellt, da WAN1 CG-NAT hat. Auch das hat nichts gebracht.

    4. Meine Hypothesen / Was mich ratlos macht:

    • Wenn sudo wg Handshakes und Traffic anzeigt, der UDM SE Client "Connected" ist, aber nichts in den Firewall-Logs der UDM SE auftaucht, wo verschwinden die Pakete?
    • Liegt es an einem tieferen Layer der iptables-Regeln auf dem VPS, die ich übersehe, selbst wenn UFW deaktiviert ist und PostUp/PostDown scheinbar korrekt sind? (Vielleicht ein Konflikt, der den Forward-Traffic innerhalb des VPS immer noch blockiert?)
    • Könnte es ein MTU-Problem sein, das zu stillen Paketverlusten führt, bevor die Pakete die UDM SE erreichen?
    • Gibt es eine spezifische Eigenheit der UDM SE als WireGuard Client, die den Traffic aus dem Tunnel intern nicht korrekt routet oder einer weiteren unsichtbaren Firewall unterwirft, bevor er im LAN ankommt?

    Ich bin echt am Verzweifeln. Jede Hilfe, jeder Tipp oder Denkanstoß ist willkommen!

    Vielen Dank im Voraus!

    Edited once, last by MaTekki (July 5, 2025 at 10:02 AM).

  • Firewall lässt Pakete vom Wireguard IP Netz von Zone External nach Zone Internal durch? Das gleiche für External nach Gateway, falls Du auf das Unifi Gateway zugreifen willst? Die Regeln musst Du explizit erstellen.

    Spezifisch ist z.B. dann noch, dass der Unifi Wireguard Client NAT macht, kann man aber wegkonfigurieren.

    Funktioniert die Gehenrichtung? Könnte noch eine fehlende oder fehlerhafte policy based routing Regel sein ... dann geht die Antwort nicht in den Tunnel sondern über den WAN raus.

    Und drauf achten was man anpingt. Windows Client OS antwortet per default nicht auf pings aus anderen IP Subnetzen. Nicht das man nen Fehler sucht, der gar nicht da ist.

  • Vielen Dank. Ich habe tcpdump auf der UDM SE gemacht und die Pakete des VPS kommen dort an. Es muss also am Routing oder der Firewall der UDM SE liegen

    Siehst Du denn was in den Flow Logs zufällig?

    IPv4 oder IPv6?


    Firewall lässt Pakete vom Wireguard IP Netz von Zone External nach Zone Internal durch? Das gleiche für External nach Gateway, falls Du auf das Unifi Gateway zugreifen willst? Die Regeln musst Du explizit erstellen.

    Spezifisch ist z.B. dann noch, dass der Unifi Wireguard Client NAT macht, kann man aber wegkonfigurieren.

    Funktioniert die Gehenrichtung? Könnte noch eine fehlende oder fehlerhafte policy based routing Regel sein ... dann geht die Antwort nicht in den Tunnel sondern über den WAN raus.

    Und drauf achten was man anpingt. Windows Client OS antwortet per default nicht auf pings aus anderen IP Subnetzen. Nicht das man nen Fehler sucht, der gar nicht da ist.

    Im neuen Zone Based gibts für VPN eine extra Zone, die sollte das meines Wissens sein.

  • Siehst Du denn was in den Flow Logs zufällig?

    IPv4 oder IPv6?


    Im neuen Zone Based gibts für VPN eine extra Zone, die sollte das meines Wissens sein.

    Die VPN Zone ist für den Wireguardserver. Die Wireguardclients sind in der Zone Extern ... sieht man doch eindeutig in der Auflistung. Und da es hier um einen VPS geht, wird im Unifi ein Client aktiviert sein, was ja auch prima zum Verhalten der Firewall passt.

    Ach und in den Flows wird da vermutlich nichts zu sehen sein, ist halt für die Firewall Traffic von Extern der stillschweigend geblockt wird ... Wäre ja auch schlimm wenn jedes Paket aus dem Internet, welches ungefragt bei einem landet dort aufgelistet wäre.

  • Vielen Dank an alle für die Unterstützung. Das Problem besteht nicht mehr, auch wenn mir nicht ganz wohl dabei ist. Ich hatte die Zone Based Firewall auf meiner UDM SE bisher noch nicht aktiviert. Nachdem die Hinweise hier alle für die Zone Based Firewall waren, habe ich sie aktiviert. Und seitdem funktioniert es. Ich habe keine Änderung der Regeln vorgenommen oder sonstiges. Daher weiß ich jetzt immer noch nicht genau was das Problem war.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!