21
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):
Client (LXC):
Client (Laptop):
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/128Client (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,::/0Client (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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 43440658944
Url: https://administrator.de/contentid/43440658944
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
21 Kommentare
Neuester Kommentar
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.
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 ...
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“. 😉
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“. 😉
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.
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.
Beim Homelab Client habe ich auch die config angepasst. (ipv4 forwarding ist bereits aktiviert)
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?
@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/24Beim 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 = 25Verbindung 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
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:
Mobiler Client:
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).
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/32Mobiler 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- 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.
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:
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.
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.
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: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.
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 sentZitat 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.Alternativ geht das auch indem man erst ein wg-quick down wg0 und danach ein wg-quick up wg0 ausführt.
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.
Zitat von @mrsna5:
Beim Homelab Client habe ich auch die config angepasst. (ipv4 forwarding ist bereits aktiviert)
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?
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 = 25Verbindung 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?
Die AllowedIPs am Homelab Client sind unvollständig, diese sollten so lauten damit auch der iPhone Client durch kommt!!
AllowedIPs = 10.1.1.0/24AllowedIPs = 10.1.1.1/32,10.1.1.3/32Mit 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.
2
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ß
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.
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>
👍 Na dann fehlt ja nur noch der Haken am Beirag.
1
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:
Config für den Server:
Config Homelab:
Hier unbedingt
Auch die statische Route im Router setzen.
Config Mobiler Client:
Hinweis für die Linux Systeme: Nach jeder Änderung der Config mit
Bei abweichenden Vorhaben hilft die große Anleitung von @aqui oder sein Site-2-Site Tutorial.
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.
- 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 ACCEPTConfig 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/32Config 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 = 25Config 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)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! 😉
