Portweiterleitung über VPS mit WireGuard, da Deutsche Glasfaser DS-Light keine öffentliche IP bereitstellt

  • Hallo zusammen,

    ich bekomme von der Deutschen Glasfaser einen Internetanschluss, allerdings nur mit DS-Light, also ohne eigene öffentliche IPv4-Adresse. Dadurch kann ich keine klassischen Portweiterleitungen nutzen, um von außen auf mein Heimnetzwerk bzw. bestimmte Dienste zuzugreifen.

    Um dieses Problem zu umgehen, habe ich mir einen VPS mit öffentlicher IP-Adresse gemietet. Die Idee ist, dass alle Verbindungen, die von außen auf dem VPS ankommen (mit Ausnahme der Ports für SSH und WireGuard, die für den VPS selbst benötigt werden), an meine UDM (UniFi Dream Machine) weitergeleitet werden.

    Die UDM soll als WireGuard-Client eine dauerhafte Verbindung zum VPS aufbauen und den Traffic empfangen. Innerhalb der UDM möchte ich dann über die Firewall/NAT-Regeln die jeweiligen Ports an die entsprechenden Geräte in meinem Heimnetz weiterleiten.

    Kurz gesagt:

    • Deutsche Glasfaser mit DS-Light → keine direkte öffentliche IP.
    • VPS dient als Relay mit öffentlicher IP.
    • UDM baut VPN-Tunnel zum VPS auf.
    • Ports werden über den Tunnel weitergeleitet und im Heimnetz verteilt.

    Hat jemand von euch so ein Setup schon umgesetzt oder kann mir Tipps geben, wie ich das am besten konfiguriere? Besonders spannend wären Beispiele für die Portweiterleitung am VPS (iptables oder ähnliches) sowie die Umsetzung auf der UDM.

    Vielen Dank schon mal!


    P.S.: Ich dachte an diese Wireguard Config auf dem VPS. Das sollte doch so passen oder?

    Ich habe nur Probleme mit den Firewall Regeln.


    Nochmal vielen Dank!

  • Danke aber ist das nicht das selbe in Grün?
    Leider fehlt mir dann noch immer die Konfiguration auf der UDM. Hier habe ich grad die Problem und stehe auf dem Schlauch.

    Hat hier jemand erfahrung bzw kann unterstützen?

  • Ja es würde um unter anderem um Plex, gameserver und websits gehen. Der VPS ist nur ein kleiner 1 Core, 1 GB RAM Server , er soll halt nur als Brücke fungiren.

    Die Dienst und alles sollen weiterhin auf dem Proxmox im Lan bleiben

  • Ach jetzt verstehe ich was du meinst. das die vm die den Proxy hat die verbindung aufbaut. Das ist natürlich eine Möglichkeit.


    Ich würde dennoch gerne tiefer in das thema mit der Firewall einsteigen. Kannst du mir sagen wie es denn umsetzbar wäre? Ich hatte daran gedacht das ich auf der UDM unter VPN Client die Daten zum VPS eintrage und dann diese Firewallregeln setze, hier im bsp. für 80 und 443, aber irgendwie scheint es nicht zu funktionieren, irgendwas muss ich übersehen

  • Also ein RP auf dem VPS brauchst du ja in jedem Fall oder wie willst du die Dienste aufrufen?

    In Unifi könnte ich es mir so vorstellen:

    Source : WG ip oder vps ip

    Dest: IP und Port Gruppen bilden und diese dann in einer Regel alle freigeben.
    Alles andere blocken.

    Wenn du eine lösung findest bitte hier posten , würd mich auch interessieren :)

  • Punkt 1:

    Portweiterleitungen lassen sich bei UniFI nur von einen WAN interface auf eine Lokale IP einrichten. Hast du auch gemacht.
    Dein WAN Interface hat aber die falsche IPv4. Was soll also weitergeleitet werden ? Da kommt ja nichts an...
    Dein Setup auf dem VPS leitet ja irgendwas auf das WG interface des UniFI. Das WG interface ist aber ungleich das WAN Interface.

    Geht also nicht mit einem DNAT (Port Weiterleitung). Jedenfalls nicht aktuell mit einem Unifi Router.

    Punk2:
    Auch wenn Technisch möglich ist das eh alles eher "Dreckig". Von IP X -> über Tunnel -> auf Router Interface -> Weiter
    auf eine IP in einem VLAN. ...Puh...das ist nur der Hinweg..

    Das Original Paket hat hier ggf. noch die Original Source IP, der Rückweg muss zwingend der gleiche sein.
    Sprich spezielle Rückrouten über Policy / Source Routing. Denn der Unifi wird sonst versuchen das
    Paket über den Normalen WAN zu Routen und nicht zurück über den Tunnel.

    Der VPS mag die dann dann nicht die
    Quelle und es hier auch das Rücknat fällig, bzw ein PAT (Maskierung auf die WAN IP des VPN)

    Da hilft es nicht jemanden an die Hand zu nehmen, das muss man alles wissen und damit umgehen können.
    Keiner wird hier in ein paar Zeilen das Wissen vermitteln können damit das dann auch läuft und vor allem
    nach 4 Updates auch immer noch läuft. Du must In der Lage sein das selber zu verstehen und einzurichten.

    Punk3:
    Normales 08/15 Routing funktioniert dagegen Prächtig. Und damit auch typische (Reverse)Proxy Dienste
    NGINX ist dann wohl eine gute Referenz und bringt mit dem stream module auch einen generell Purpose TCP/UDP
    Proxy mit für nicht "Web" Anwendungen...

  • Also ein RP auf dem VPS brauchst du ja in jedem Fall oder wie willst du die Dienste aufrufen?

    In Unifi könnte ich es mir so vorstellen:

    Source : WG ip oder vps ip

    Dest: IP und Port Gruppen bilden und diese dann in einer Regel alle freigeben.
    Alles andere blocken.

    Wenn du eine lösung findest bitte hier posten , würd mich auch interessieren :)

    Ja den RP habe ich ja bereits und alles funktioniert wie ich es mir vorstelle. Der unterschied ist halt nur das ich in der alten Wohnung ein Telekom Anschluss mit öffentlicher IP habe und einfach die Ports weiterleiten kann.

    Schön wäre es wenn man das selbe aus einem Wireguard Tunnel machen könnte, also ja das geht aber leider nicht so simpel wie wenn man die ip direkt anliegen hat und wie es geht habe ich bisher noch nicht rausgefunden


    Zu Punkt 1
    Ja da hast du recht das geht nur mit Wan interfacen aber in der Zone External ist auch das VPN Interface. Der Wireguard server hat die 10.66.66.1 und die udm 10.66.66.2, daher müsste die Regel doch so stimmen oder nicht?

    zu Punkt 2
    Ja das ist nicht schön aber was bleibt anderes übrig wenn man keine ipv4 vom anbieter bekommt? Aber ich glaube das genau hier mein Problem liegt, also das der Rückweg nicht richtig funktioniert. Wenn ich beim Testen vom vps selber ein curl zu meinem RP gemacht habe (zu dem ja auch die Regel zeigt) dann habe ich die Antwort bekommen, habe ich das aber aus dem internet an die ip des vps gemacht, hier sollte der traffic dann ja auch zum RP geleitet werden, bekomme ich ein timeout und ich denke das liegt dann genau hier an der route des rückwegs.

    zu Punkt 3

    Ich nutze aktuell Zoraxy als RP also meinst du auch das ich auf der vm die vpn verbindung aufbauen soll damit die pakete dann direkt am proxy ankommen und ich damit weniger kopfschmerzen haben werde?


    Ich hatte gehofft das ich das über die udm hin bekomme um einen ort zu haben wo alles wirklich verwaltet wird

  • Zu Punkt 1
    Ja da hast du recht das geht nur mit Wan interfacen aber in der Zone External ist auch das VPN Interface. Der Wireguard server hat die 10.66.66.1 und die udm 10.66.66.2, daher müsste die Regel doch so stimmen oder nicht?

    10.0.0.0/8 ist ein Bereich aus RFC1918, das sind reservierte, private Adressen, die nicht im Internet geroutet werden. Am WAN Deiner Firewall kann also niemals die Adresse 10.66.66.1 anklopfen, weswegen Deine Regel, so wie jetzt da steht, für ein ewiges Leben in Arbeitslosigkeit verdammt ist.

  • Ja da hast du recht das geht nur mit Wan interfacen aber in der Zone External ist auch das VPN Interface. Der Wireguard server hat die 10.66.66.1 und die udm 10.66.66.2, daher müsste die Regel doch so stimmen oder nicht?

    Nein. ZONE bedeutet ja nur das das eine oder andere Objekt in einer Gruppe zusammengefast ist und von den "normalen" Iptables gleich behandelt werden.
    die Portweiterleitung bezieht sich explizit aufs WAN interface. Also Technisch auf ETH9X (z.B eth8 für den WAN Port, oder eth9-10 for die SFP)
    Dein Wireguard Server hat aber das interface wgsrvX.

    Ja das ist nicht schön aber was bleibt anderes übrig wenn man keine ipv4 vom anbieter bekommt?

    Mehr bezahlen ? Deutschen Glasfaser wirb bei den small business Tarifen sogar mit ner Festen IP

    Ich nutze aktuell Zoraxy als RP also meinst du auch das ich auf der vm die vpn verbindung aufbauen soll damit die pakete dann direkt am proxy ankommen und ich damit weniger kopfschmerzen haben werde?

    Ja wobei der RP dann auf de VPS gehört.

  • 10.0.0.0/8 ist ein Bereich aus RFC1918, das sind reservierte, private Adressen, die nicht im Internet geroutet werden. Am WAN Deiner Firewall kann also niemals die Adresse 10.66.66.1 anklopfen, weswegen Deine Regel, so wie jetzt da steht, für ein ewiges Leben in Arbeitslosigkeit verdammt ist.

    Ja das ist natürlich richtig das die 10er Adressen nicht im Internet geroutet werden. Aber die VPN Verbindung wird in der UDM in der Zone External zusammen mit den WAN Ports geführt und an dieser Stelle hat der die IP 10.66.66.2. Der VPS geht doch erst mit seiner Öffentlichen IP ins Internet.

    Ich denke das ich irgendwo ein großen Denkfehler habe denn warum sollte das Technisch nicht funktionieren was ich vor habe?

    Code
    +-------------+         +-------------+         +-----------------------------+         +--------------+         +----------------+         +-------------+
    |  Internet   |  <-->   |     VPS     |  <-->   |  WireGuard Tunnel           |  <-->   |      UDM     |  <-->   |       RP       |  <-->   |   Dienst    |
    |             |         |  (öff. IP)  |         | (10.66.66.1 <-> 10.66.66.2) |         |              |         |                |         | (z.B. Web)  |
    |             |         |   1.2.3.4   |         |     verschlüsselt           |         | 192.168.188.1|         | 192.168.188.167|         |             |
    +-------------+         +-------------+         +-----------------------------+         +--------------+         +----------------+         +-------------+

    Ich muss doch der UDM nur beibringen das alle Pakete (bzw. nur die von mir gewünschten Ports die ich dann mit regeln einstelle) die vom Tunnel auf der IP 10.66.66.2 ankommen an den RP mit der IP 192.168.188.167 weitergeleitet werden. Der macht dann wie gehabt sein ding und die Antworten müssten doch den selben weg rückwärts gehen? Oder muss ich das hier auch noch definieren?


    Nein. ZONE bedeutet ja nur das das eine oder andere Objekt in einer Gruppe zusammengefast ist und von den "normalen" Iptables gleich behandelt werden.
    die Portweiterleitung bezieht sich explizit aufs WAN interface. Also Technisch auf ETH9X (z.B eth8 für den WAN Port, oder eth9-10 for die SFP)
    Dein Wireguard Server hat aber das interface wgsrvX.

    Mehr bezahlen ? Deutschen Glasfaser wirb bei den small business Tarifen sogar mit ner Festen IP

    Ja wobei der RP dann auf de VPS gehört.

    Wie kann ich dann expliziert die vpn Verbindung nutzen?

    Die Deutsche Glasfaser ist so schon teuer genug und dazu kommt das man die Business Tarife nur mit einem Gewerbe bekommt?

    Weswegen? Ich möchte den VPS ja nur als Fuß mit IPv4 im Internet haben, daher soll er ja jeglichen eingehenden Traffic über die VPN Verbindung schicken damit dann alles weitere local verarbeitet wird.


    Ich hoffe ihr versteht mein eigentliches Ziel. Am liebsten wär mir ja weiterhin das ich die öffentliche ipv4 am WAN Port anliegen habe aber das ich leider nicht möglich

  • Ich muss doch der UDM nur beibringen das alle Pakete (bzw. nur die von mir gewünschten Ports die ich dann mit regeln einstelle) die vom Tunnel auf der IP 10.66.66.2 ankommen an den RP

    Dann ran an die BUlettem SSH drauf in Lustiges iptables -v -L -t nat && iptables -v -L -t nat und schau dir an was da schon ist und wozu DEIN Kram manuel dazu Fummelln kannst.
    Wie du dic drin kümmerst das diese wieder reinegfumelt werden wenn Unifi ne Congi wieder ausrollt und so weiter und so fort.

    Wie kann ich dann expliziert die vpn Verbindung nutzen?

    Klingt aus dem Kontext Gerissen. Ich meine. RP Auf dem VPS, der leitet die Aufrufe dann über den Tunnel auf die UDM direkt zum ziel host.
    Das ist Basic Routing und erledigt mit den passenden "AllowedIPs" in der WG config. (UDM dabei als EG Server...

  • Dann ran an die BUlettem SSH drauf in Lustiges iptables -v -L -t nat && iptables -v -L -t nat und schau dir an was da schon ist und wozu DEIN Kram manuel dazu Fummelln kannst.
    Wie du dic drin kümmerst das diese wieder reinegfumelt werden wenn Unifi ne Congi wieder ausrollt und so weiter und so fort

    Ich verstehe was du meinst. Ich verstehe nur nicht so recht warum das mit den Firewall regeln in der gui nicht umsetzbar ist. Ich meine theoretisch ist das doch ganz simpel. Was an der Schnittstellen von Wireguard ankommt soll an den RP gehen und die Antwort halt wieder zurück zum Tunnel. In der Theorie ja kein Hexenwerk.


    Klingt aus dem Kontext Gerissen. Ich meine. RP Auf dem VPS, der leitet die Aufrufe dann über den Tunnel auf die UDM direkt zum ziel host.
    Das ist Basic Routing und erledigt mit den passenden "AllowedIPs" in der WG config. (UDM dabei als EG Server...

    Ich verstehe was du meinst aber ich möchte verhindern 2 RP zu nutzen und zu pflegen.
    Das wäre dann ja so:
    Internet --> VPS mit RP --> UDM --> VM mit RP --> Dienst
    Den RP im internen Netz benötige ich ja wenn ich lokal auf die dienste möchte, ich möchte ja nicht den Umweg übers Internet nehmen

    Ich habe mir das so vorgestellt das der VPS als weiterer "WAN Port" fungiert an dem eine öffentliche IP anliegt. Da es aber kein Richtiger WAN Port ist kann ich keine Portweiterleitung machen, daher die Idee mit den Firewallregeln wie diese als bsp (wobei ja hier als Src. die IP des Wireguard Servers steht)
    28733-e5c656cbd78c7aa794f91555a3a2b63d1b91e3cb0b51419834ddd061c7b53594-variant.webp

  • Ich verstehe nur nicht so recht warum das mit den Firewall regeln in der gui nicht umsetzbar ist.

    Weil Unifi das nicht zulässt über die GUI. fertig.

    verhindern 2 RP zu nutzen und zu pflegen.

    Einer Reicht..RP auf dem VPS Leitet dann Port 1234 auf IP 10.11.12.13 Weiter.

    Wierguard Tunnel weis das 10.11.12.13/24 am ende des Tunnels wohnt und legt ne reute dafür an.
    Deine UD kenn das 10.11.12.13/24 ja eh, weil das ist Vlan999 (Alle Nummern nur als beispiell
    Und Zack 1A L3 Routing das klappt sofort und direkt.

Participate now!

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