Jan 11, 2024, updated at Jan 12, 2024 (UTC)

2827

Wireguard über vServer ins Heimnetz will nicht

Moin,
ich verzweifle seit Tagen an einer Wireguard Verbindung ins Heimnetz.
Verzeiht Fehler auch wenn er noch so doof ist, ich bin was Wireguard und iptables angeht Anfänger.

Zur Situation:
Wie es mittlerweile vielen geht habe ich einen Anschluss mit CGNAT (Deutsche Glasfaser). Nun hatte ich den Plan mit einem meiner vServer (öffentliche ipv4) ein Wireguard Server zu bauen um so auf mein Homelab per VPN zugreifen zu können. Ich habe bereits viele der hier und woanders zur Verfügung stehenden Anleitungen gelesen aber komme trotzdem nicht weiter.
Hier mal eine Skizze meines Plans:

Mit einem Client (Laptop) möchte ich auf mein Heimnetz zugreifen. Der vServer ist der Wireguard Server zu dem sich der Laptop und ein Proxmox LXC verbindet. Die Verbindung klappt soweit. Der LXC und mein Laptop verbinden sich zum vServer und bekommen ihre wg0 ip. Die Geräte können sich auch untereinander anpingen (mit den wg0-Adressen). Nur komme ich vom Laptop nicht in mein Heimnetz. Muss ich hier bestimmte iptables rules erstellen, dass Anfragen auf dem LXC vom wg0 Interface auf das eth0 Interface weitergeleitet werden? Wenn ja welche? Bei AllowedIps habe ich 0.0.0.0/0 eingetragen und bei der Serverkonfiguration schon viel rumprobiert.

vServer-config (die PostUp/PostDown Routen wurden von dem wireguard-script erstellt):

[Interface]
Address = 10.1.1.1/24,fd42:42:42::1/64
ListenPort = 51820
PrivateKey = QP46Y8Q2uqS8fxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PostUp = iptables -I INPUT -p udp --dport 51820 -j ACCEPT
PostUp = iptables -I FORWARD -i ens3 -o wg0 -j ACCEPT
PostUp = iptables -I FORWARD -i wg0 -j ACCEPT
PostUp = iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostUp = ip6tables -I FORWARD -i wg0 -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D INPUT -p udp --dport 51820 -j ACCEPT
PostDown = iptables -D FORWARD -i ens3 -o wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o ens3 -j MASQUERADE

### Client homelab
[Peer]
PublicKey = EzUOCtkaUxJd5PASwMKxxxxxxxxxxxxxxxxxxxx
PresharedKey = GH6Mp7uFF7QtyEOgQxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.1.1.2/32,fd42:42:42::2/128,192.168.1.0/24

### Client laptop-test
[Peer]
PublicKey = +lqJHvzEv3FrTKYxCQAYUxxxxxxxxxxxxxxxxxxxxxxxx
PresharedKey = WOzyqFWhcwBADBWxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.1.1.3/32,fd42:42:42::3/128

Client (LXC):

[Interface]
PrivateKey = 8BbifMX2rdovhQER2xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.1.1.2/32,fd42:42:42::2/128
DNS = 8.8.8.8,1.1.1.1

[Peer]
PublicKey = FrbmW5zOarWkLaxxxxxxxxxxxxxxxxxxxxxxxx
PresharedKey = GH6Mp7uFFxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Endpoint = vserver.example.com:51820
AllowedIPs = 0.0.0.0/0,::/0

Client (Laptop):

[Interface]
PrivateKey = gHk5c8s+6xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Address = 10.1.1.3/32,fd42:42:42::3/128
DNS = 8.8.8.8,1.1.1.1

[Peer]
PublicKey = FrbmW5zOarWkLaBxxxxxxxxxxxxxxxxxxxxxx
PresharedKey = WOzyqFWhcwBADBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Endpoint = vserver.example.com:51820
AllowedIPs = 0.0.0.0/0,::/0

Please also mark the comments that contributed to the solution of the article

Content-Key: 43440658944

Url: https://administrator.de/contentid/43440658944

Printed on: April 27, 2024 at 19:04 o'clock

21 Comments

Latest comment

Das Wireguard Tutorial hast du gelesen und deine Konfig entsprechend angepasst?! 🤔
Merkzettel: VPN Installation mit Wireguard

Statt der in dieJahre gekommenen iptables solltest du besser nftables verwenden auf dem vServer und das idealerweise in einer statischen Firewall Konfig über /etc/nftables.conf und niemals über die Wireguard Konfig Datei selber.
Ein Preshred Key ist sinnfrei bei der Verwendung von Keys denn man benötigt zum Gürtel nicht noch einen überflüssigen Hosenträger. Siehe Tutorial…
0.0.0.0\0 ist ein Gateway Redirect und nur dann sinnvoll wenn man es wirklich benötigt. Split Tunneling ist in den meisten Fällen immer die intelligentere Wahl.
Bei dir wie üblich leider auch der Kardinalsfehler NAT im Tunnel zu machen was kein transparentes Routing erlaubt.
Eine Beispielkonfig für nftables findest du in einem identischen Jumphost Tutorial was statt Wireguard die bordeigenen VPN Clients benutzt anstatt mit externen VPN Clients zu frickeln:
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Die nftables Konfig ist aber identisch zu Wireguard.

Ob es besonders intelligent ist Google DNS Server zu verwenden die dein Internetverhalten ausspäht und an Dritte vermarktet musst du selber entscheiden. Intelligent und Datensicherheit geht bekanntlich anders…
Die interne VPN IP Adressierung ist ebenso nicht gut gewählt und kann dir früher oder später auf die Füße fallen. Siehe dazu auch hier.

Ich hänge moch mal da ran, weil auch mein Heimnetz mit CGNAT im Internet steht ...

Ich eerde aber noch nicht ganz klar, wo dein VServer steht - die öffentliche IP.

Weil du dem zugleich 2 Schnittstellen ...
- eth0
- wg0

zuordnest.

Wenn der an deinem Glasfaseranschluss hängt, ist er CGNAT-betroffen mit seiner "öffentlichen IP" und somit aus dem Internet nicht erreichbar ...

Mein VServer, der dafür geplant ist steht bei strato (1€/Monat)
Geplant ist netmaker.io (Community) als Wireguard-Vermittler ...

Bin da aber aus privaten Gründen noch nicht weiter gekommen als im

FritzBox als VPN-Client (Wireguard)

Der VServer ist gebucht, geplant ist Ubuntu aps Server mit netmaker.io als Verbindungsmanager ...

Just for Info… Für die FRITZ!box gelten wegen ihrer nicht Standard konformen WG Konfig auch ein paar besondere Bedingungen wenn man sie mit klassischen Wireguard Endgeräten koppeln möchte.
Beachtet man diese klappt es auf mit der FB fehlerlos auf Anhieb:
S2S-Wireguard: AVM zu Mikrotik

Nur das du das auf dem Radar hast?! 😉
Und… ein vServer ist in Regel ja bei einem Hoster positioniert und niemals in einem heimischen Netzwerk. Dann wäre es ein simpler Server ohne „v“. 😉

Zitat von @aqui:

Just for Info…

Richtig.
Die Idee, die FritzBox mit dem Verbindungsserver (netmaker.io auf Ubuntu auf VServer bei strato)...
... ist ja eine Idee um keine zusätzliche Hardware einzusetzen ...

Ob ich die FB dann überzeugen kann mit dem netmaker.io zusammen zu arbeiten, steht noch auf einem anderen Blatt ...

Und wenn der WG-Server hinter einem CGNAT hängt, dürfte das m.W genauso wenig mit einer Direktanwahl funktionieren wie andere VPN ...🤔

Der TO irritiert mich eben bei "VServer" und den genannten Schnittstellen ...

... ein VServer hat ja in der Basis nur eine nutzbare öffentliche IP (es sei denn man gibt mehr Geld für mehrere aus) - daher meine Vermutung, das der VServer, eine VM im Intranet ist - hinter CGNAT

Meine Recherche brachte mich zu netmaker.io als Verbindungsserver, der z.B. mehrere auch CGNAT-betroffene Clients mit dem WG-Server - meine Idee: die FritzBox - vermittelt ...

Ich zab aber noch'n PI3 als Alternative für einen WG-Server im Heimnetz ...
... aber auch der bräuchte m.W. einen Broker um aus dem Internet hinter CGNAT erreichbar zu sein ... 🤔

Ob ich die FB dann überzeugen kann mit dem netmaker.io zusammen zu arbeiten, steht noch auf einem anderen Blatt ...

Funktioniert fehlerlos wie du am o.a. Tutorial ja sehen kannst. 😉

Und wenn der WG-Server hinter einem CGNAT hängt, dürfte das m.W genauso wenig mit einer Direktanwahl funktionieren wie andere VPN

Zweifelsohne richtig, nur das du dann von einem privaten Server im Heimnetz redest und nicht von einem vServer der in der Regel mit öffentlichen IPs beim Hoster arbeitet. Äpfel und Birnen…😉

ein VServer hat ja in der Basis nur eine nutzbare öffentliche IP

Auch das ist absolut richtig. Nur…was hat das mit einer Wireguard Jumphost Konfig zu tun? Die VPN Kommunikation geschieht ja ausnahmslos nur über das interne, virtuelle wg0 Interface und das hat ja jeder Server egal ob vServer oder privater Server im Heimnetz. Wo ist hier also der Punkt? 🤔
CGNAT kannst du nur mit einem vServer beim Hoster bedienen oder einem kostenpflichtigen v4 Tunnelbroker sofern du über IPv4 redest.
Wireguard bietet dir aber auch immer die IPv6 Option mit einer IPv4 Adressierung im Tunnel welche ja auch bei einem DS-Lite Anschluss rennt.
Wir wollen aber jetzt den Thread des TOs hier nicht mit fremden Themen kapern… 🏴‍☠️ 😉

Danke, @aqui.
Hatte das bisher nicht realisiert, das das Tutorial auch diese Konstellation berücksichtigt.

Werde mir das nochmal zu Gemüte führen.

Moin, bin das ganze heute nochmal von vorne angegangen.
@aqui Der vServer bei Oracle hat quasi ein einen virtuellen Router. Dieser hat die öffentliche ip und hat den wireguard Port auf die ip des Servers (10.0.0.23) weitergeleitet. Deswegen die eth0 Adresse.

WG-Server hat jetzt die neue config. Die automatisch erstellten Regeln habe ich rausgenommen. NAT ist weg und die benötigten iptables Regeln fest eingetragen.

[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = QP46Y8Q2uqS8fLowhhyuYxxxxxxxxxxxxxxxxxx

### Client homelab-lxc
[Peer]
PublicKey = EzUOCtkaUxJd5PASwMKkCxxxxxxxxxxxxxxxxx
AllowedIPs = 10.1.1.2/32, 192.168.1.0/24

Beim Homelab Client habe ich auch die config angepasst. (ipv4 forwarding ist bereits aktiviert)

[Interface]
PrivateKey = 8BbifMX2rdovhQERxxxxxxxxxxxxxxxxxxxx
Address = 10.1.1.2/24

[Peer]
PublicKey = FrbmW5zOarWkLaBhQ6xxxxxxxxxxxxxxxxxxxxxxxx
Endpoint = 130.162.xxx.xxx:51820
AllowedIPs = 10.1.1.1/32
PersistentkeepAlive = 25

Verbindung baut auch auf. Beide Geräte erreichen sich gegenseitig. Die 192.168.1.17 (LXC) lässt sich vom Server anpingen; alles andere nicht. Hier müsste ja ein forwarding passieren, was die Anfrage aus dem Wireguard-netz an mein Heimnetz weiterleitet. Das funktioniert aber nicht. Beim Versuch meinen Router (192.168.1.1) vom Server zu erreichen schlägt der Ping fehl. Wo ist hier mein Denkfehler?

Der vServer bei Oracle hat quasi ein einen virtuellen Router.

Aber NUR dann, wenn man auf dem Server auch IPv4 Forwarding (Routing) in der Datei /etc/sysctl.conf aktiviert!! Im Default ist das deaktiviert und es wird NICHT geroutet! 🧐
Merkzettel: VPN Installation mit Wireguard

Dieser hat die öffentliche ip an eth0 und hat den wireguard Port wg0

...eine Binsenweisheit die seit Jahrhunderten jedem Netzwerker bekannt ist!

Die automatisch erstellten Regeln habe ich rausgenommen. NAT ist weg und die benötigten iptables Regeln fest eingetragen.

Grundsätzlich erstmal alles richtig gemacht! 👍

Die 192.168.1.17 (LXC) lässt sich vom Server anpingen; alles andere nicht.

Das sieht verdächtig danach aus das du das Tutorial nicht richtig gelesen oder verstanden hast! ☹️
Fehler ist sehr wahschreinlich eine fehlende statische Route auf das interne Wireguard IP Netz.
Sie dazu auch den Routing Abschnitt im Tutorial!

Nur so viel zum erwartbaren Verhalten:
Die "alles andere" Endgeräte haben sehr wahrscheinlich den lokalen Internet Router als Default Gateway. Pingst du also nun vom WG Server, kommst du an den "alles andere" Endgeräten logischerweise mit einer 10.1.1.x /24 Absender IP Adresse aus dem internen Wireguard Netz an.
Das "alles andere" Endgerät erkennt das dies ein externes IP Netz ist und nicht das lokale und forwardet die Antwort wie zu erwarten an den Internet Router der ja sein Default Gateway ist.
Ohne statische Route ins Wireguard Netz die ihm explizit sagt wo dieser Traffic hin muss, forwardet der Router die Antwort dann an den Internet Provider der ja seinerseits sein Default Gateway ist.
Was dieser dann mit privaten RFC1918 IP Netzen macht weisst du als Netzwerk Profi sicher auch selber ohne extra Erklärung!
Andernfalls hilft es sicher diese simplen Basics noch einmal genau im Routing Grundlagentutorial nachzulesen. 😉

Fazit:
Statische Route nachtragen dann klappt das auch alles sofort und beim nächsten Mal das Tutorial bitte gewissenhaft durchlesen und umsetzen! 🧐

Ah Ok. Dann war ich auf dem Holzweg. Ich dachte die ganze Zeit, dass ich keine statischen Routen bräuchte weil die anderen Geräte im Heimnetz dann quasi von der 192.168.1.17 angefragt werden. Das wäre ja dann aber wieder NAT und würde keinen Sinn machen. Ich werde das ganze ausprobieren.
Vielen Dank schon einmal, ich bin Schüler und mache das ganze zum ersten mal. Wurde da von den vielen Tutorials im Internet etwas erschlagen. Danke für die Geduld mit mir

OK, statische Route war wie erwartet das Problem. Komme vom Server jetzt ins Heimnetz. Nur geht das ganze vom zweiten Client noch nicht. Habe die Config für meinen Laptop testweise auf mein Telefon kopiert (Um über Mobilfunk zu testen). Das hat dann die 10.1.1.3 im VPN-Netz. Bei AllowedIps hab ich dann 10.1.1.1/32, 10.1.1.2/32, 192.168.1.0/24 eingetragen. Allerdings kann ich so nur den Server (10.1.1.1) anpingen. Sowohl 10.1.1.2 als auch das Heimnetz ist nicht erreichbar. Muss ich da noch was am Server konfigurieren? Von diesem geht ja aber alles.

OK, statische Route war wie erwartet das Problem.

Wie erwartet. Tutorials lesen hilft!

als auch das Heimnetz ist nicht erreichbar.

Wenn der Laptop eine Winblows Maschine ist, ist das auch klar und erwartbar. Grund ist die lokale Winblows Firewall weil...

diese generell das ICMP Protokoll blockt. Siehe dazu auch hier.
diese generell Traffic von fremden IP Adressen blockt und nur Traffic aus dem eigenen Netz zulässt. Siehe zu der Thematik hier.

Konfig des Telefons und das Pendant auf dem Server wären hilfreich. Beispiel zum Vergleich u.a. hier

Habe mich eigentlich an deinem Post orientiert. Komisch dass es noch nicht geht.
Server config:

root@wireguard:/home/ubuntu# cat /etc/wireguard/wg0.conf
[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = QP46Y8Q2uqS8fLxxxxxxxxxxxxx

### Client homelab
[Peer]
PublicKey = EzUOCtkaUxJd5PASwMKkxxxxxxxxxxxxxxxxx
AllowedIPs = 10.1.1.2/32, 192.168.1.0/24

### Client iphone-test
[Peer]
PublicKey = +lqJHvzEv3FrTKYxCQxxxxxxxxxxxxxxxxxxxxxxxxxx
AllowedIPs = 10.1.1.3/32

Mobiler Client:

[Interface]
PrivateKey = gHk5c8s+6DgEn2nxYIFB9xxxxxxxxxxxxxxxx
Address = 10.1.1.3/24

[Peer]
PublicKey = FrbmW5zOarWkLaBhQ6j716xxxxxxxxxxxxxxxxxx
Endpoint = 130.162.xxx.xxx:51820
AllowedIPs = 10.1.1.1/32, 192.168.1.0/24

Wie gesagt:
- Ping an die 10.1.1.1 (Server) geht
- Ping an die 10.1.1.2 (Client Zuhause) geht nicht (macht ja auch Sinn die 10.1.1.2 ist nicht in den allowedips; geht aber auch nicht wenn ich die mit reinnehme oder testweise 0.0.0.0/0 eintrage. Daran kann es also nicht liegen.)
- Ping an 192.168.1.1 (Router) geht auch nicht

Vom Server geht ja alles. ipv4 forwarding habe ich am Server an und aus probiert (spielt ja aber auch keine rolle da nicht zwischen interfaces geroutet werden muss). Entweder ich habe jetzt wieder irgendeinen doofen Fehler drin oder es liegt an dem iPhone (Apple blockt ja gerne mal dinge; pings im Heimnetz oder an Cloudflare gehen ja aber).

Deine WG Konfiguration sieht erstmal gut aus. Homelab Konfig muss auch die iPhone IP haben.
Pingst du vom iPhone aus?? Hier ist es hilfreich mit den bekannten HE.NET Tools zu arbeiten!
https://apps.apple.com/de/app/he-net-network-tools/id858241710

Was auffällig ist, ist die Tatsache das in deiner Client Konfig ein PersistentKeepalive = 25 fehlt! (Siehe dazu auch den Client Konfig Abschnitt im Tutorial)
Die Clients (VPN Initiators, und nur die) sollten immer einen Keepalive senden weil es sonst passieren kann das eine NAT Firewall im Pfad den UDP Port per Timeout schliesst was dann zu einem Tunnelabbruch führt.

Das du den Server 10.1.1.1 selber nicht pingen kannst zeigt eigentlich das da vermutlich etwas mit den Keys nicht stimmt und das iPhone erst gar keinen Tunnel aufbaut.
Was sagt ein wg show auf dem Server wenn das iPhone einen (vermeintlich) aktiven Tunnel hat? Da sollte dann sowas wie das hier zu sehen sein:

Das zeigt dir ob der Tunnel überhaupt "established" ist oder nicht.

Hast du daran gedacht den Wireguard Prozess nach Einrichten des iPhone Peers mit
systemctl enable wg-quick@wg0.service
neu zu starten damit dieser die Peer Konfig neu einlesen kann??
Alternativ geht das auch indem man erst ein wg-quick down wg0 und danach ein wg-quick up wg0 ausführt.

Ja pinge vom iPhone aus. Hab es mit der App Ping und jetzt auch nochmal mit den HE.NET Tools probiert.
PersistentKeepalive = 25 habe ich im iPhone manuell nachgetragen. Das hatte ich vergessen mit zu kopieren. Ist aber drin.

Zitat von @aqui:
Das du den Server 10.1.1.1 selber nicht pingen kannst zeigt eigentlich das da vermutlich etwas mit den Keys nicht stimmt und das iPhone erst gar keinen Tunnel aufbaut.

Falsch. Wie ich geschrieben habe, kann ich (auch mit beiden Apps) den Server erreichen. Nur die Verbindung zu dem anderen Client (bei mir Zuhause) geht nicht. Das wg show bestätigt auch, dass die Verbindung steht:

root@wireguard:/etc/wireguard# wg show
interface: wg0
  public key: FrbmW5zOarWkLaBhQ6j7xxxxxxxxxxxxxxxxxx
  private key: (hidden)
  listening port: 51820

peer: +lqJHvzEv3FrTKYxCQAYU5Msxxxxxxxxxxxxxxxxx
  endpoint: 46.114.182.85:26582
  allowed ips: 10.1.1.3/32
  latest handshake: 1 minute, 6 seconds ago
  transfer: 13.50 KiB received, 4.23 KiB sent

peer: EzUOCtkaUxJd5PASwMKkxxxxxxxxxxxxxxxx
  endpoint: 94.31.99.151:33859
  allowed ips: 10.1.1.2/32, 192.168.1.0/24
  latest handshake: 1 minute, 13 seconds ago
  transfer: 161.47 KiB received, 46.11 KiB sent

Zitat von @aqui:
Alternativ geht das auch indem man erst ein wg-quick down wg0 und danach ein wg-quick up wg0 ausführt.

Genauso mache ich das immer nach Veränderungen.
Wie gesagt Ping an den Server geht und von dem Server geht der Ping ins Heimnetz. Nur der Ping vom iPhone über den Server nach Hause funktioniert nicht. Habe auch nochmal iptables Regeln gecheckt. Da ist alles zugelassen.
Statische Route dürfe es auch nicht sein, wenn vom Server alles geht.

Irgendwo bleibt der Ping stecken. Ist auch nicht so, dass der rejected wird. Der ist einfach timed out.

Zitat von @mrsna5:
Beim Homelab Client habe ich auch die config angepasst. (ipv4 forwarding ist bereits aktiviert)

[Interface]
PrivateKey = 8BbifMX2rdovhQERxxxxxxxxxxxxxxxxxxxx
Address = 10.1.1.2/24

[Peer]
PublicKey = FrbmW5zOarWkLaBhQ6xxxxxxxxxxxxxxxxxxxxxxxx
Endpoint = 130.162.xxx.xxx:51820
AllowedIPs = 10.1.1.1/32
PersistentkeepAlive = 25

Die AllowedIPs am Homelab Client sind unvollständig, diese sollten so lauten damit auch der iPhone Client durch kommt!!

AllowedIPs = 10.1.1.0/24

oder wenn du nicht das ganze Subnetz rein lassen willst restriktiver so

AllowedIPs = 10.1.1.1/32,10.1.1.3/32

Je nachdem wie restriktiv du das ganze gestalten willst.
Mit deiner aktuellen Config (10.1.1.1/32) erlaubst du ja nur dem Server selbst in dein Heimnetz zu kommen, ergo kann so nix vom Eierfön mit der IP 10.1.1.3 durch kommen 😉

AllowedIPs und das Kryptokey Routing auf Client wie auf Server-Seite verstehen lernen lautet die Devise, dann klappt's auch mit dem Nachbarn. 🖖👍

PJ.

Moin PJ,
habe es gerade selber bemerkt und wollte es schreiben. Das "Timed out" hat mir den Tipp gegeben, dass es nicht zurück kommen kann. Vielen Dank.

Ich werde bis heute Abend nochmal einen größeren Kommentar mit der Zusammenfassung und den Configs zum Copy/Pasten veröffentlichen.

Gruß

Die statische Route auf dem Default GW des
Heimnetzes für das WG Netz auch nicht vergessen sonst erreichst du nur den WG Container und sonst nix im Heimnetz.
Netz 10.1.1.0/24 Gateway = <IP des WG-Containers im Heimnetz>

Zitat von @mrsna5:
Statische Route dürfe es auch nicht sein, wenn vom Server alles geht.

Statische Route hatte ich ja schon seitdem @aqui mein Missverständnis gelöst hatte. Ist auch alles erreichbar jetzt.

👍 Na dann fehlt ja nur noch der Haken am Beirag.

Mit Wireguard über vServer nach Hause für Noobs

Ok hier nochmal alles zusammengefasst. Ziel ist es das eigene Heimnetz über einen VPN Tunnel zu erreichen, auch wenn der Anbieter Zuhause CGNAT verwendet. Die Lösung orientiert sich natürlich sehr an @aqui 's Site-2-Site Tutorial. Nur das hier der Server außen sitzt und als Jump-Host benutzt wird. Die IPs sollten natürlich nach eigenem Belieben angepasst werden.

Server vorbereiten:
- Updates machen und wenn noch nicht vorhanden Wireguard installieren.
- Wireguard Port udp freigeben (Es kann auch ein anderer benutzt werden)
Folgende iptables Regeln habe ich benutzt; besser kann man dies mit nftables machen:

iptables -I INPUT -p udp --dport 51820 -j ACCEPT
iptables -I FORWARD -i eth0 -o wg0 -j ACCEPT ###Interface ggf. anpassen
iptables -I FORWARD -i wg0 -j ACCEPT

Config für den Server:

[Interface]
Address = 10.1.1.1/24
ListenPort = 51820
PrivateKey = UGaBTnib26Kxav8kMIUSWqDESpd1wJ5HtZP0BooWQ3s=

### Client homelab
[Peer]
PublicKey = 4Q9DeL8a/Q+FtCNOWtaNcix9+9T5vSogW865M5PVsFw=
AllowedIPs = 10.1.1.2/32, 192.168.1.0/24

### Client mobil
[Peer]
PublicKey = 5n7MR2eZuzj7PTlXJzUEFAEonp61h0w1/vmlClu4k00=
AllowedIPs = 10.1.1.3/32

Config Homelab:
Hier unbedingt net.ipv4.ip_forward=1 in der etc/sysctl.conf auskommentieren und rebooten!
Auch die statische Route im Router setzen.

[Interface]
PrivateKey = KKpnyM05xdIoZjGIYEUCOzcyXDbZCsU4oNo6f8BN13U=
Address = 10.1.1.2/24

[Peer]
PublicKey = J+t5+bg4ztiMXUiqC6a4HCu06pKFASdAXt6sIsA6dCE=
Endpoint = 123.232.121.54:51820 ###alternativ Domain die auf den Server zeigt
AllowedIPs = 10.1.1.1/32, 10.1.1.3/32 ###hier weitere mobile Clients nach bedarf eintragen
PersistentkeepAlive = 25

Config Mobiler Client:

[Interface]
PrivateKey = KKpnyM05xdIoZjGIYEUCOzcyXDbZCsU4oNo6f8BN13U=
Address = 10.1.1.3/24

[Peer]
PublicKey = J+t5+bg4ztiMXUiqC6a4HCu06pKFASdAXt6sIsA6dCE=
Endpoint = 123.232.121.54:51820 ###alternativ Domain die auf den Server zeigt
AllowedIPs = 10.1.1.1/32, 192.168.1.0/24 ###hier alternativ 0.0.0.0/0 eintragen wenn der gesamte Traffic über den Tunnel gehen soll (in öffentlichen WLANS praktisch)

Hinweis für die Linux Systeme: Nach jeder Änderung der Config mit wg-quick down wg0 && wg-quick up wg0 den Tunnel neustarten.
Bei abweichenden Vorhaben hilft die große Anleitung von @aqui oder sein Site-2-Site Tutorial.

Die Lösung orientiert sich natürlich sehr an....

Eigentlich hilft da eher seine Seite die diese Einrichting mit einem vServer Jumphost beschreibt! 😉
IKEv2 VPN Server und Jumphost Lösung für DS-Lite/CGNAT Anschlüsse

Diese hat nämlich zudem den praktischen Vorteil das man nicht umständlich mit überflüssigen VPN Clients auf allen Endgeräten rumfrickeln muss sondern bequem überall die so oder so vorhandenen Onboard VPN Clients sinnvoll nutzen kann! 😉

German solved Question VPN Virtualization Linux Network Networks

Hotly discussed

End of availability for classic Teams clientDani