Jul 13, 2022

18647

DS-Lite Glasfaseranschluss - Wireguard VPN via IPv6 möglich ?

Hallo zusammen,

mich konfrontiert gerade zum ersten Mal das Thema "DS-Lite Anschluss", und dem damit verbundenen Problem mit den nicht vorhandenen (öffentlichen) IPv4 Adressen. Aber der Reihe nach ... ich habe die Aufgabe vor der Brust einen VPN Zugang für einen Kollegen bereitzustellen.

Gesagt getan schnurrt ein frisch aufgesetzter Wireguard Server auf einem Raspi. DynDNS ist auch eingerichtet.
Dann habe ich mir natürlich die Nase angerannt und musste feststellen das ich die 4er Adresse nicht erreichen kann, Stichwort Carrier Grade NAT usw.

Was ich nicht verstehe; ich bin dann davon ausgegangen das zumindest die IPv6 Adresse eine "echte" Adresse ist welche im Internet geroutet wird (also kein CGNAT).
Also habe ich in der Fritz!Box mal testweise eine IPv6-Portfreigabe eingerichtet auf den SSH Port vom Raspi. Keine Chance.

Seltsam ist meines Erachtens das die IPv6 Adresse (welche mir die Fritz!Box anzeigt bzw. DynDNS "auflöst") eine andere ist wie mir zum Beispiel die Seite
https://ipv6-test.com/ anzeigt (die IPv4 Adresse ist auch eine andere, aber das ist mir logisch durch das CGNAT). Hab ich einen Denkfehler oder wird in meinem Fall eben auch die 6er Adresse via CGNAT versteckt ? Der Provider selbst (Stiegeler) möchte das für mich klären bzw. hatte darauf jetzt auch keine konkrete Antwort.

Ich will es einfach am Ende verstehen und ob ich mich gleich einer Lösung zuwenden muss in welcher ein VPS zwischen drinsteht.

thx!

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

Content-Key: 3327519249

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

Printed on: April 29, 2024 at 01:04 o'clock

39 Comments

Latest comment

Hallo!

Bei IPv6 (nicht generell, aber bei deinem Setup gehe ich davon aus) besitzen alle Endgeräte eine eigene, öffentliche IPv6-Adresse. Das heißt, dass du mit jedem Endgerät eine eigene IPv6-Adresse im Internet hast und auch auf deiner Testseite jeweils eine andere angezeigt bekommst.

Du musst die IPv6-Adresse des Raspberry Pis benutzen, um den Pi zu erreichen, nicht die IPv6-Adresse deiner FRITZ!Box. Normalerweise ändern sich nur die Prefixe der IPv6, das könnte dir noch weitere Probleme bereiten wenn dein DynDNS-Anbieter kein IPv6 unterstützt.

LG, runthegaunz

Hi runthegaunz,

danke für die fixe Antwort ... glaub da gehen mir - dem Hobby IT-ler - die IPv6 Grundlagen etwas ab. Den ersten Part habe ich verstanden bzw. muss ich umdenken wenn jedes Endgerät seine quasi eigene öffentliche IPv6 Adresse hat. Also rantasten .. was ich noch nicht geschluckt habe.:

Du meinst ich kann den Pi im lokalen direkt "von außen" über die IPv6 Adresse ansprechen, weil in der Adresse die ersten 64Bit das Netzwerk kennzeichnen, korrekt ?. Wenn ich die IPv6 Adresse der Fritz!box mit der Adresse vom Raspi vergleiche, sind aber nur die ersten 32Bit die selben. Der Raspi hat die Adresse vom DHCP der Fritz!Box.

Portfreigaben sind nach wie vor erforderlich !?! Also zum Beispiel den Wireguard Port explizit freigeben bzw. weiterleiten, obwohl eine Weiterleitung (wie bei IPv4) gar nicht nötig wäre da der Endpunkt über die IPv6 Adresse ja klar ist.

thx!

https://nocksoft.de/tutorials/dyndns-fuer-ipv6-server-hinter-fritzbox-ko ...

das zumindest die IPv6 Adresse eine "echte" Adresse ist welche im Internet geroutet wird (also kein CGNAT).

Das ist sie auch immer! Es gibt ja bekanntlich gar kein NAT bei IPv6.
Hier ein Raspberry Pi Interface in einem lokalen LAN

/home/pi# ip a
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:50:b6:4f:92:05 brd ff:ff:ff:ff:ff:ff
    inet 192.168.28.7/26 brd 192.168.28.63 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 2003:cb:73a:6383:759e:78b5:c2f4:ae18/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 40750sec preferred_lft 36430sec
    inet6 fe80::3e61:d1af:32e5:a205/64 scope link 
       valid_lft forever preferred_lft forever 

:/home/pi# ping -6 www.heise.de
PING www.heise.de(www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85)) 56 data bytes
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=1 ttl=55 time=17.4 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=2 ttl=55 time=15.0 ms
64 bytes from www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85): icmp_seq=3 ttl=55 time=15.1 ms
64 bytes from 2a02:2e0:3fe:1001:7777:772e:2:85: icmp_seq=5 ttl=55 time=14.9 ms

Works as designed... 😉

Seltsam ist meines Erachtens das die IPv6 Adresse

Seltsam ist das nicht. Ein v6 Device kann mehrere v6 Adressen haben. Oft hat es die EUI-64 Adresse und eine mit Privacy Extensions und immer die Link Local Adresse, also 3.

Du meinst ich kann den Pi im lokalen direkt "von außen" über die IPv6 Adresse ansprechen

Ja natürlich. Allerdings erfordert das 2 Voraussetzungen:

Dein remoter Client muss natürlich auch in einem öffentlichen v6 Netz sein.
Deine lokale Firewall muss z.B. TCP Port 22 auf die lokale v6 IP des RasPis freigebene haben. (Macht man in der FritzBox unter Freigaben) Normal blockt die Router Firewall alle eingehenden IPv6 Sesssions von außen wie es sich gehört. Du willst ja nicht das dein lokales LAN von jedermann weltweit erreichbar ist, oder ?!

weil in der Adresse die ersten 64Bit das Netzwerk kennzeichnen, korrekt ?

Bei einem /64er Prefix ja. Es gibt aber auch noch andere Subnetzmasken.

Portfreigaben sind nach wie vor erforderlich !?! Also zum Beispiel den Wireguard Port explizit freigeben

Das ist richtig! Wohlgemerkt freigeben.
Weiterleiten gibt es nicht, da es kein NAT gibt bei IPv6.

sind aber nur die ersten 32Bit die selben.

Das ist die Provider Prefix Delegation, also das Subnetz was du vom Provider bekommst für deinenj lokalen LANs (meist ein /56er). Die FB ergänzt das dann und macht daraus im lokalen LAN /64er Netze.

Noch viel lernen du noch musst...

Vielleicht hilft es wenn du dein IPv6 Wissen mit etwas kostenloser Literatur auf die Sprünge hilfst:
https://danrl.com/ipv6/

Wie man das lokale v4 IP Netz dann via VPN mit einem Jumphost, vServer usw. erreichbar macht erklären dir diverse Tutorials hier im Forum:
Zwei Mobilfunkrouter (TP-Link MR200) per VPN verbinden, ev. per externen VPN-Gateway (VPS-Server)
Feste IPs zuhause in pfsense via WireGuard Tunnel
Feste IPs zuhause in pfsense via GRE Tunnel
IKEv2 VPN Server für Windows und Apple Clients mit Raspberry Pi
Wie Portforwarding über 2 miteinander verbundenen pfSense realisieren

Servus @aqui

Zitat von @aqui:

das zumindest die IPv6 Adresse eine "echte" Adresse ist welche im Internet geroutet wird (also kein CGNAT).

Das ist sie auch immer! Es gibt ja bekanntlich gar kein NAT bei IPv6.

NaNaNa, geben tut es das schon, iptables, nftables, Mikrotik usw. können es out of the box, und das wird sogar auch bei einigen LTE-Carriern bei IPv6 genutzt (vornehmlich USA und auch einige Billigheimer hier). Man stelle sich nur mal vor das jemand ein DDOS auf eine IPv6 eines Mobilfunkteilnehmers fährt und der wundert sich das sein Datenvolumen nach der hälfte des Monats aufgebraucht ist obwohl er selbst keine Hand angelegt hat.
Das man NAT bei IPv6 natürlich meist nie haben will außer in Ausnahmefällen steht natürlich außer Frage

.

Grüße Uwe

Hallo,

Also habe ich in der Fritz!Box mal testweise eine IPv6-Portfreigabe eingerichtet auf den SSH Port vom Raspi.
Keine Chance.

Und dürfen wir erfahren welche AVM FB das denn nun genau ist? Eine 5530 oder 5590?

Ok kurz um nimm doch bitte einfach den My!Fritz Account und dann mach es darüber. Ist nicht so cool und neu
aber es funktioniert und kann auch mit den AVM APPs benutzt werde.

> Ich will es einfach am Ende verstehen und ob ich mich gleich einer Lösung zuwenden muss in welcher ein

VPS zwischen drinsteht.

Nimm My!Fritz von AVM und alles wird gut. In einer der nächsten FritzOS Versionen sollte dann auch ein
WireGuard Server mit an Board sein (in der AVM FB) somit fällt dann auch die RaspBerry PI Sache fast unter den Tisch.

Dobby

NaNaNa, geben tut es das schon, iptables, nftables, Mikrotik usw. können es out of the box

Du hast natürlich Recht, keine Frage!! 😉
Ich wollte das Steuer nur gleich in die richtige Richtung bringen das NAT bei v6 eher, wie du richtig sagst, die Ausnahme ist und kein best Practise.

sorry für die späte Antwort.
Neuland, aber ich bin vom Wissen her schon mal einen großen Schritt weiter ... danke für den Input an alle.

Das die IPv6 Clients im lokalen Netz "direkt" aus dem Internet ohne Weiterleitungen erreichbar sind (sofern die Freigaben entsprechend gesetzt sind) erfordert ein Umdenken, für jemanden der bis dato nur mit 4er Adressen rumhantierte.

@aqui Mir ist jetzt klar(er) warum das nicht funktionieren kann - mein Remote Client befindet sich nicht in einem öffentlichen v6 Netz. Ergebnis via http://www.test-ipv6.com/

Es scheint, als hätten Sie nur eine IPv4-fähige Internetverbindung. Sie werden nicht in der Lage sein, Webseiten, welche nur via IPv6 verfügbar sind, zu erreichen.

Ich hab ein UniFi Security Gateway als Router, Draytek Vigor als Modem und als Provider 1&1. Zuerst muss ich meine IPv6 Anbindung auf die Reihe bekommen bzw. entsprechend konfiguriert.
Alternative wäre ein Portmapper als Übersetzer (IPv4 <=> IPv6) quasi als Übersetzer dazwischenschalten (?)

@108012 es handelt sich um eine Fritz!Box 7390. Diese wird wohl das On-Board Wireguard Feature nicht mehr bekommen. My!Fritz Fernzugang meinst du ? Aber auch das funktioniert laut AVM nur wenn beide Netze eine IPv6 Anbindung haben.

Hallo,

UniFi Security Gateway als Router, Draytek Vigor als Modem

Und dort ist dann auf der anderen Seite (VPN Gegenseite) WireGuard drauf?

es handelt sich um eine Fritz!Box 7390

Müssen da nur Ports geöffnet (weitergeleitet) werden oder auch Protokolle angegeben werden?

Dobby

Zitat von @108012:

Und dort ist dann auf der anderen Seite (VPN Gegenseite) WireGuard drauf?

VPN Client (mein Netz)

normaler VDSL Anschluss (bis jetzt kein IPv6, nur IPv4)
UniFi Security Gateway als Router, Draytek Vigor als Modem
Wireguard Client unter Windows

VPN Server (Netz vom Kollegen)

DSL-Lite Anschluss (IPv6, IPv4 = CGNAT)
Fritz!Box 7490
Wireguard Server als docker Container auf einem 4er Raspi

es handelt sich um eine Fritz!Box 7390

Müssen da nur Ports geöffnet (weitergeleitet) werden oder auch Protokolle angegeben werden?

sorry, oben fälschlicherweise 7390 angegeben bzw. handelt es sich um eine 7490.
Es müssen lediglich die Ports für einen bestimmten Client freigegeben werden (inkl. Protokoll).

Miete dir einfach einen kleinen vServer für 1-2 Euro /Monat, und benutze diesen als Jumphost (kleine Linux Instanz mit Wireguard/Strongswan/etc.). Du baust dann mit dem Raspi eine VPN-Verbindung auf den Jumphost auf und mit deinen Clients verbindest du dich mit dem Jumphost und kommst so von jedem Standort auf dein Netz egal ob IPv6 oder nur IPv4 verfügbar ist. Der Jumphost kann dann bei Bedarf auch noch andere Aufgaben erledigen.

Grüße Uwe

Alternativ, wenn Du Dir die 1-2 EUR/Monat (und die Bastelei) sparen möchtest, könntest auf dem lokalen Zielgerät auch Zerotier installieren. Das ist bis 50 Clients kostenlos. ist allerdings vermutlcih nicht das richtige, wenn Du von extern ins komplette Netz möchtest. Zumindest habe ich das Routing noch nicht hinbekommen.

ok, verstanden ... danke.
Aber nur um es auch richtig einzuordnen - diese Lösungen mit einem Jumphost usw. sind doch quasi nur in Betracht zu ziehen wenn ich es "klassisch" nicht lösen kann, oder ? Und so wie ich es sehe (vielleicht hab ich da den Denkfehler) bekomme ich das Ganze doch zum fliegen, wenn:

- mein öffentliches Netz auch eine IPv6 Anbindung hat (wie erwähnt liegt es da eher an meiner Konfiguration bzw. der Provider "liefert" mir ja eigentlich IPv6)

Und dann eben noch das Wireguard entsprechend IPv6 konform konfiguriert ist. DynDNS entsprechend eingerichtet usw.

Zitat von @Kollisionskurs:

ok, verstanden ... danke.
Aber nur um es auch richtig einzuordnen - diese Lösungen mit einem Jumphost usw. sind doch quasi nur in Betracht zu ziehen wenn ich es "klassisch" nicht lösen kann, oder ? Und so wie ich es sehe (vielleicht hab ich da den Denkfehler) bekomme ich das Ganze doch zum fliegen, wenn:

So lange du unterwegs über keine öffentliche IPv6 Anbindung verfügst bringt dir die IPv6-Anbindung daheim nichts.

- mein öffentliches Netz auch eine IPv6 Anbindung hat (wie erwähnt liegt es da eher an meiner Konfiguration bzw. der Provider "liefert" mir ja eigentlich IPv6)

Dein Provider ja, aber wenn du dich unterwegs bspw. in einem Hotspot befindest der dir nur IPv4 bietet hast du wieder das selbe Problem du kommst nicht auf "direktem" Wege auf deine IPv6 Adresse...
Du brauchst also zwingend eine Zwischenstation die per IPv4 erreichbar ist sei es ein Jumphost oder Zerotier etc. damit du wirklich von überall in dein Netz kommst.

Hallo nochmal,

Aber nur um es auch richtig einzuordnen - diese Lösungen mit einem Jumphost usw. sind doch
quasi nur in Betracht zu ziehen wenn ich es "klassisch" nicht lösen kann, oder?

Darum geht es ja bei DSlight und CGNAT!

Und so wie ich es sehe (vielleicht hab ich da den Denkfehler) bekomme ich das Ganze doch zum fliegen, wenn:

DynDNS, My!Fritz und der Jumphost erfüllen mehr oder weniger alle den gleichen Zweck. Verirr Dich
da nicht, die ermöglichen Dir quasi alle nur das man von außen auf eine andere Gegenstelle per VPN
verbinden kann.

- mein öffentliches Netz auch eine IPv6 Anbindung hat (wie erwähnt liegt es da eher an meiner
Konfiguration bzw. der Provider "liefert" mir ja eigentlich IPv6)

Es geht hier in der Regel immer um zwei Sachen;
- Eine dynamische und keine statische (feste) IP Adresse
- IPvx Mix und ein GCNAT dazwischen.

Und dann eben noch das Wireguard entsprechend IPv6 konform konfiguriert ist. DynDNS
entsprechend eingerichtet usw.

Ob Du nun DynDNS, My!Fritz oder den Jumphost benutzt ist eigentlich nur Nebensache.

Dobby

Zitat von @colinardo:
Du brauchst also zwingend eine Zwischenstation die per IPv4 erreichbar ist sei es ein Jumphost oder Zerotier etc.

Ok, klar ... verstanden. Im ersten Moment ging es mir nur mal um eine Verbindung von meinem in sein Netz. Aber wenn der Kollege dann später von außerhalb drauf möchte, bin ich wieder am selben Punkt. Stimmt.

Zuerst muss ich meine IPv6 Anbindung auf die Reihe bekommen bzw. entsprechend konfiguriert.

Das wäre der erste wichtige Schritt!

So hast du erstmal die Option das alles wasserdicht zu testen und deine v6 Kenntnisse etwas aufzupolieren. 😉

Wenn's das denn nun war bitte deinen Thread dann auch als erledigt schliessen!

Ich muss den Thread nochmal öffnen - ich konnte mich die Tage wieder mal um meine angestrebte VPN Lösung kümmern. Allerdings habe ich noch ein Routing Problem und bitte euch mal ein Auge auf meine Konfiguration zu werfen. Ziel ist es ja das ich zwei entfernte Netzwerke über einen Wireguard Server "in der Mitte" miteinander verbinden kann.

[Client A] <--> [Jumpserver] <--> [Client B]

In einer Azure VM (Ubuntu Server) läuft Wireguard im Server Modus - aka Jumpserver. IP Forwarding ist aktiviert.
Die beiden Clients laufen derzeit (noch) auf einem Windows Notebook.

Was geht ...

von beiden Clients aus kann ich den Tunnel sauber aktivieren und auch die interne IP-Adresse des Servers anpingen (10.0.0.4).

Was nicht geht ...
Client A kommt nicht in das Netzwerk von Client B (192.168.178.0 /24)
Client B kommt nicht in das Netzwerk von Client A (10.10.10.0 /24)

## Server Konfig.

[Interface]
PrivateKey = ##
Address = 10.66.66.1/24
ListenPort = 45703
# Allow routing between clients
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT
SaveConfig = false

[Peer]
PublicKey = ##
AllowedIPs = 10.66.66.2/32, 192.168.178.0/24
PresharedKey = ##

[Peer]
PublicKey = ##
AllowedIPs = 10.66.66.3/32, 10.10.10.0/24
PresharedKey = ##

## Client A
- Windows PC - LAN: 10.10.10.0/24

[Interface]
PrivateKey = ##
Address = 10.66.66.2/32
DNS = 10.10.10.2

[Peer]
PublicKey = ##
PresharedKey = ##
AllowedIPs = 10.66.66.3/32, 10.0.0.0/24, 192.168.178.0/24
Endpoint = myGateway:45703

## Client B
- Windows PC - LAN: 192.168.178.0/24

[Interface]
PrivateKey = ##
Address = 10.66.66.3/32
DNS = 192.168.178.1

[Peer]
PublicKey = ##
PresharedKey = ##
AllowedIPs = 10.66.66.2/32, 10.0.0.0/24, 10.10.10.0/24
Endpoint = myGateway:45703

Wo liegt mein Denkfehler ?
thx !

IPv4 Forwarding mit Entkommentieren der Zeile net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf mit einem anschliessenden Reboot oder systemctl restart networking hast du gemacht? Andernfalls kann der Server nicht routen.
Wo kommt das 10.0.0.0/24 Netz her? Existiert laut deiner Beschreibung nirgendwo!
Zusätzlich sind deine Subnetzmasken im Client Setup falsch was das interne Netz anbetrifft, damit scheitert das Crypto Routing!

Siehe hier:
Merkzettel: VPN Installation mit Wireguard
und auch hier:
Wireguard Site2Site mit Roadwarrior

Zitat von @aqui:

IPv4 Forwarding mit Entkommentieren der Zeile net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf mit einem anschliessenden Reboot oder systemctl restart networking hast du gemacht? Andernfalls kann der Server nicht routen.

net.ipv4.ip_forward=1 ist gesetzt.

* Wo kommt das 10.0.0.0/24 Netz her. Existiert laut deiner Beschreibung nirgendwo?!

Das ist das interne Netz der Azure VM. Das ist nur zu Testzwecken eingestellt um den Server selbst pingen zu können.

* Zusätzlich sind deine Subnetzmasken im Client Setup falsch was das interne Netz anbetrifft, damit scheitert das Crypto Routing!
Siehe hier:
Merkzettel: VPN Installation mit Wireguard

Hab ich im Post DS-Lite Glasfaseranschluss - Wireguard VPN via IPv6 möglich ? entsprechend korrigiert - hab ich das richtig verstanden ?

entsprechend korrigiert -

Dennoch hast du aber falsche Masken sowohl der VPN Adapter wie auch der AllowedIPs gepostet!

Beim Server hast du es ja komischerweise richtig gemacht?! (Siehe das Beispiel oben)
Richtig wäre für...
Client A:
[Interface]
PrivateKey = xyz
Address = 10.66.66.2/24
DNS = 10.10.10.2

[Peer]
PublicKey = xyz
PresharedKey = xyz
AllowedIPs = 10.66.66.1/32, 10.0.0.0/24, 192.168.178.0/24
Endpoint = myGateway:45703

Client B:
[Interface]
PrivateKey = xyz
Address = 10.66.66.3/24
DNS = 192.168.178.1

[Peer]
PublicKey = xyz
PresharedKey = xyz
AllowedIPs = 10.66.66.1/32, 10.0.0.0/24, 10.10.10.0/24
Endpoint = myGateway:45703

Sehr wahrscheinlich sind auch die PostUP und Down Kommandos überflüssig und auch kontraproduktiv wenn dort gar keine iptables Firewall aktiv ist!

Des weiteren, je nachdem wie Wireguard auf dem Server eingerichtet wurde fehlen evt. noch die Routen in die Client-Netze am Server

ip route add 192.168.178.0/24 via 10.66.66.2
ip route add 10.10.10.0/24 via 10.66.66.3

Des weiteren wenn das ein S2S werden soll, müssen die Windows-Clients ebenfalls als Router agieren, auf diesen muss das IP-Forwarding dort ebenfalls aktiviert werden wenn man nicht nur den Wireguard-Client selbst erreichen können will.
Des weiteren muss auf dem Default-Gateway in den Client-Netzen ebenfalls eine statische Route in das fremde Netz mit dem Wireguard-Client als GW hinterlegt werden (Gilt auch nur wenn man dort andere Clients erreichen können will und nicht nur den Wireguard-Client).
Des weiteren sollte man ein KeepAlive in der Wireguard-Client-Config setzen (z.B. 25 Sekunden) wenn das ein Site2Site werden soll, denn sonst schließt dein NAT Router den UDP-Session-State nach einem Leerlauf wenn da von einer Seite kein Traffic mehr kommt.

Übrigens, "Bääh" warum machst du mit Winblows-Wireguard-Clients ein Site2Site?? Sowas lässt man sinnvollerweise einen Router/Firewall/Linux-Device im Netz erledigen.

Cheers
certguy

fehlen evt. noch die Routen in die Client-Netze am Server

Nein, das macht Wireguard mit seinem Crypto Routing ganz automatisch und ist nicht erforderlich.
Da wo statische Routen erforderlich sind, sind das die jeweils lokalen Router in den Client Netzen. Dort müssen die Zielnetze und das internen WG Netz eingetragen sein mit Next Hop auf die WG Client IP im lokalen Netz. (Siehe Wireguard Tutorial)

erstmal danke für die (schon gewohnt) schnelle Hilfe !!

Zitat von @aqui:

entsprechend korrigiert -

Dennoch hast du aber falsche Masken sowohl der VPN Adapter wie auch der AllowedIPs gepostet!

Beim Server hast du es ja komischerweise richtig gemacht?! (Siehe das Beispiel oben)
Richtig wäre für...

OK, das ich bei den AllowedIPs bei beiden Clients explizit die Server-IP (10.66.66.1/32) angeben muss war mir nicht bewusst. Aber auch nach Deiner Vorgabe fliegt das Ding leider noch nicht bzw. bleibt der ping auf die andere Seite unbeantwortet

Sehr wahrscheinlich sind auch die PostUP und Down Kommandos überflüssig und auch kontraproduktiv wenn dort gar keine iptables Firewall aktiv ist!

die Commands hab ich gelöscht, keine Änderung.

Zitat von @3803037559:

* Des weiteren wenn das ein S2S werden soll, müssen die Windows-Clients ebenfalls als Router agieren, auf diesen muss das IP-Forwarding dort ebenfalls aktiviert werden wenn man nicht nur den Wireguard-Client selbst erreichen können will.

* Des weiteren sollte man ein KeepAlive in der Wireguard-Client-Config setzen (z.B. 25 Sekunden) wenn das ein Site2Site werden soll, denn sonst schließt dein NAT Router den UDP-Session-State nach einem Leerlauf wenn da von einer Seite kein Traffic mehr kommt.

Übrigens, "Bääh" warum machst du mit Winblows-Wireguard-Clients ein Site2Site?? Sowas lässt man sinnvollerweise einen Router/Firewall/Linux-Device im Netz erledigen.

das ist aus der Not geboren bzw. ist die Anforderung eigentlich das ich von meinem Windows Notebook ausgehend in das Netz meines Kollegen eintauchen darf um dann seine KNX Anlage in Betrieb nehmen zu können. Auf seiner Seite war ein Wireguard Server via docker angedacht. Wird aber nichts durch die DSL-Lite (CGNAT) Problematik bzw. deshalb der Jumpserver. Allerdings bekomme ich es nicht hin den Wireguard-docker-Client mit dem Jumpserver zu verbinden, mit dem Wireguard Windows Client geht es problemlos. So ist der Test-Aufbau via Windows entstanden, in der Hoffnung das zum fliegen zu kriegen.

Zitat von @aqui:

fehlen evt. noch die Routen in die Client-Netze am Server

Nein, das macht Wireguard mit seinem Crypto Routing ganz automatisch und ist nicht erforderlich.

Stimmt leider nicht ganz. Setze mal mit systemd-networkd den Wireguard Tunnel auf Server-Seite auf und du wirst sehen das das auf der Server-Seite nicht der Fall ist 😉. Ist übrigens bei einer pFSense und dem Wireguard Package genauso, dort muss man zu Zeit die zusätzlichen Routen auch noch von Hand eintragen! Bei systemd-networkd kann man das halt auch leicht mal vergessen.

Es gibt unterschiedliche Methoden Wireguard aufzusetzen, und nicht bei allen werden die Routen in andere Netze als dem von WG selbst von Geisterhand angelegt, deswegen einfach der Hinweis an den TO das zu prüfen.
Bei wg-quick & co. ja, die nehmen einem das natürlich ab, Prüfen sollte man es aber im Fehlerfall natürlich.

Zitat von @3803037559:
Stimmt leider nicht ganz. Setze mal mit systemd-networkd den Wireguard Tunnel auf Server-Seite auf und du wirst sehen das das auf der Server-Seite nicht der Fall ist 😉. Es gibt unterschiedliche Methoden Wireguard aufzusetzen, und nicht bei allen werden die Routen in andere Netze als dem von WG selbst von selbst angelegt.

Wenn ich von Client A einen tracert absetze, sehe ich das die Anfrage an einen Client im gegenüberliegenden Netz am Server mittendrin endet.

C:\Windows>tracert 192.168.178.1

Routenverfolgung zu 192.168.178.1 über maximal 30 Hops

1 46 ms 44 ms 45 ms 10.66.66.1
2 * * * Zeitüberschreitung der Anforderung.
3 * * * Zeitüberschreitung der Anforderung.

Nur zur Info Windows Blockt ICMP aus anderen Subnetzen per Default in der Firewall, das musst du erst freischalten!

Lies dir unsere Hinweise oben nochmal ganz in Ruhe durch und setze sie korrekt um dann kommt das sofort zum Fliegen! Du hast nur noch nicht alle umgesetzt.

Siehe auch: https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Das muss man customizen.
Was sagt denn die Routing Tabelle bei Server und Clients bei aktivem WG Tunnel?
Windows: route print
Linux: ip r

Guten Morgen zusammen,
ich bin nicht weitergekommen bzw. hab mir weiterhin die Nase angerannt und auch soviel ver-konfiguriert das ich alles nochmal frisch aufziehen will. Sorry, ich weiß ... müssig. Aber am Schluss muss das funktionieren, lässt mir keine Ruhe. Deshalb bitte nochmal um Schützenhilfe.

Ich hab mir die Tutorials durchgelesen und daraufhin auch die Konfigs hoffentlich richtig angepasst.
Ziel ist es das ich mit meinem Windows-Wireguard-Client in das lokale Netzwerk des Kollegen komme:

[Client A "Windows" # 10.66.66.2] ==> [Wireguard Server @ Azure # 10.66.66.1] ==> [Client B "Raspi" # 10.66.66.3]

Beim Kollegen steht jetzt ein frisch aufgesetzter Raspberry mit frisch installiertem Wireguard.

Server

[Interface]
PrivateKey = ##
Address = 10.66.66.1/24
ListenPort = 45703
SaveConfig = false

[Peer]
PublicKey = ##
AllowedIPs = 10.66.66.2/32
PresharedKey = ##

[Peer]
PublicKey = ##
AllowedIPs = 10.66.66.3/32, 192.168.178.0/24
PresharedKey = ##

Client A

[Interface]
PrivateKey = ##
Address = 10.66.66.2/24
DNS = 10.10.10.2

[Peer]
PublicKey = ##
Endpoint = myGateway:45703
AllowedIPs = 10.66.66.1/32, 192.168.178.0/24, 10.0.0.0/24
PresharedKey = ##

Client B

[Interface]
PrivateKey = ##
Address = 10.66.66.3/24
DNS = 192.168.178.1

[Peer]
PublicKey = ##
Endpoint = myGateway:45703
AllowedIPs = 10.66.66.1/32, 10.66.66.2/32, 10.0.0.0/24
PresharedKey = ##

Selbes Ergebnis. Beide Clients verbinden sich einwandfrei zum Server. Aber aus meinem Netz kann ich nichts im entfernten 192.168.178.0 Netz ansprechen.

Wie bereits beschrieben ... wenn ich vom Windows ein Tracert absetze auf die 192.168.178.1, sehe ich das der erste Hop auf den Wireguard Server verweist (10.66.66.1).
Also funktioniert doch das Routing auf dem Windows Rechner und meine Anfrage wird in den Tunnel geschickt. Die Frage ist ob das Routing auf dem Wireguard-Server nicht stattfindet oder auf dem Raspi.

Tja, da fehlt ja auch wieder die Hälfte und die Subnetzmasken und Subnets sind erneut falsch eingetragen 🙈. Lies dir meinen und aquis Post oben nochmal in Ruhe durch dann siehst du was du vergessen und falsch gemacht hast!!!! Erste Devise richtig und gründlich LESEN, dann VERSTEHEN und erst dann NACHMACHEN!!!
Dir fehlen offensichtlich die einfachsten Routing-Grundlagen, also Dengel dir die erst mal rein dann verstehst du auch warum da keine Antwort kommen kann.

Die Client Adressen waren falsch eingetragen, sollten jetzt passen. Ansonsten ist es meines Erachtens analog zur Lösung von aqui (Wireguard Site2Site mit Roadwarrior).

Statische Route im Zielnetz auf dem Default GW angelegt? Forwarding auf dem Windows-Client im Zielnetz aktiviert? Firewall im Ziel customized?
Routingtabelle auf dem Wireguard Server überprüft.
Das alles fehlt hier nämlich in deinen uns präsentierten Daten für dein Setup. Sie sind aber Essentiell für das Funktionieren!
Leider gingst du darauf in keinster Weise ein und das sagt uns entweder hast du es nicht verstanden oder einfach ignoriert. Nur Wireguard einzurichten reicht dazu nämlich nicht.
Deswegen nochmal mein Post dazu oben LESEN.

Zitat von @3803037559:

Das alles fehlt hier nämlich in deinen uns präsentierten Daten für dein Setup. Sie sind aber Essentiell für das Funktionieren!

Deshalb bin ich ja hier ... um nicht dumm zu sterben

Ich hab nicht täglich mit solchen Dingen zu tun und seh vielleicht gerade vor lauter Bäumen ...

Statische Route im Zielnetz auf dem Default GW angelegt?

Ich hab auf dem Gateway (Fritz!Box) im Zielnetz eine statische Route angelegt:

Netz 10.66.66.0/24 hat als Gateway den Wireguard Client auf dem Raspi.

Und siehe da ... ich kann nun aus meinem Netz Teilnehmer im Zielnetz anpingen. Somit einen Schritt weiter
... allerdings geht auch nur der Ping bzw. keine anderen Zugriffe (https, SSH)

Forwarding auf dem Windows-Client im Zielnetz aktiviert?

im Zielnetz hängt ein Raspberry mit aktiviertem IPv4 Forwarding.

Firewall im Ziel customized?

was fehlt mir noch bzw. warum kommt nur die Antwort via ping zurück ?

Lass den Zugriff auf die Services auf den Clients aus den fremden Subnetzen in deren Firewall zu. Firewalls wie die von Windows blockieren Zugriffe aus fremden Subnetzen per Default, haben wir oben aber schon x mla geschrieben, das zum Thema unsere Beiträge "gründlich" Lesen.

Zitat von @3803037559:

was fehlt mir noch bzw. warum kommt nur die Antwort via ping zurück ?

Ich hab es so langsam verstanden das ich alles GRÜNDLICH durchlesen soll. Die Firewall auf meiner Windows Büchse ist entsprechend konfiguriert bzw. das Zielnetz auch als vertrauenswürdig eingestuft.

Zitat von @Kollisionskurs:
Ich hab es so langsam verstanden das ich alles GRÜNDLICH durchlesen soll. Die Firewall auf meiner Windows Büchse ist entsprechend konfiguriert bzw. das Zielnetz auch als vertrauenswürdig eingestuft.

Offensichtlich hast du das noch nicht ... denn nicht die Firewall von deinem Rechner, sondern die vom Zielrechner natürlich!!! Au möhr never ending story mit dir hier ...

Beim Kollegen steht jetzt ein frisch aufgesetzter Raspberry mit frisch installiertem Wireguard.

Wie Kollege @3803037559 schon gesagt hat wieder kompletten Schrott konfiguriert. Du musst auch mal lesen und wirklich umsetzen was man dir hier postet!

Letzter Versuch...

Server:
[Interface]
PrivateKey = ...
Address = 10.66.66.1/24
ListenPort = 45703

[Peer]
PublicKey = ...
AllowedIPs = 10.66.66.2/32, 10.10.10.0/24
PresharedKey = ...

[Peer]
PublicKey = ...
AllowedIPs = 10.66.66.3/32, 192.168.178.0/24
PresharedKey = ...

Peer 1 (Client A) Allowed IPs sorgt dafür das interner Client A Traffic und Traffic mit Destination IPs fürs lokale Client A Netz in den Tunnel A geroutet wird.
Peer 2 (Client B) Allowed IPs sorgt dafür das interner Client B Traffic und Traffic mit Destination IPs fürs lokale Client B Netz in den Tunnel B geroutet wird.

Client A:
[Interface]
PrivateKey = ...
Address = 10.66.66.2/24

[Peer]
PublicKey = ...
Endpoint = myGateway:45703
AllowedIPs = 10.66.66.1/32, 192.168.178.0/24, 10.0.0.0/24
PresharedKey = ...

Peer Allowed IPs sorgt dafür das Traffic mit den dort aufgeführten Destination Netz IPs in den Tunnel A via Server geroutet wird, sprich also Traffic für den Server und die lokalen LANs an Server und Client B.

Client B:
[Interface]
PrivateKey = ...
Address = 10.66.66.3/24

[Peer]
PublicKey = ...
Endpoint = myGateway:45703
AllowedIPs = 10.66.66.1/32, 10.10.10.0/24, 10.0.0.0/24
PresharedKey = ...

Peer Allowed IPs sorgt dafür das Traffic mit den dort aufgeführten Destination Netz IPs in den Tunnel B via Server geroutet wird, sprich also Traffic für den Server und die lokalen LANs an Server und Client A.

Hoffentliche erkennst du jetzt selber mal welchen Blödsinn du dort in der Server Konfig und der Client B Konfig verzapft hast! 🧐
Client A stimmt ausnahmsweise mal.

Au möhr never ending story mit dir hier ...

Wahre Worte... Tutorial lesen und verstehen hilft wirklich!!

German solved Question Internet VPN Networks

Hotly discussed

End of availability for classic Teams clientDani - 1 Comment

Developer diary: Release 6.1admtech