Über VPN Client entferntes VPN Netz erreichen

[Avenger84]

@Bob

unnötig groß ja, aber nicht falsch.

hab mal AVM angeschrieben

 

[Avenger84]

Ich habe noch mal drüber nachgedacht: es kann m.E. nach gar nicht ohne MASQUERADE mit IPv6 funktionieren.
Denn die FritzBox macht ja kein NAT für IPv6 vom Wireguard und die fd08:: (interne IPv6 vom Wireguard) kann nicht ins Internet geroutet werden.

Mit MASQUERADE habe ich auf dem Roadwarrior die IPv6 vom Raspberry (wo Wireguard & PiHole drauf läuft) beim IP-Test.

Ich könnte nur für IPv4 MASQUERADE deaktivieren und für IPv6 lasse ich es aktiviert.

 

[riversource]

Denn die FritzBox macht ja kein NAT für IPv6 vom Wireguard

Ist das so? ich arbeite nicht mit privaten Adressen hinter der Fritzbox, sondern hab ein öffentliches Subnetz auch für VPN, deshalb weiß ich das nicht sicher. Aber wenn es so ist, dann hast du recht.

 

[Avenger84]

Wie kriegst du denn das öffentliche IPv6 Netz Ins Wireguard?

 

[riversource]

Bei mir ist es ein zusätzliches IPv6 /64 Netz auf einem VPS. Hinter einer Fritzbox würde ich es mir per Prefix Delegation holen, wenn der Provider mehr bietet, als /64.

 

[Avenger84]

der Provider bietet ::/56
aber wie willst du praktisch den Prävix dem wg0 hinzufügen ?
bei Unterbrechnung der Internetverbindung muss ja wg sofort neu gestartet werden und die neue IPv6 dort eingepflegt werden.

 

[Bob.Dig]

@Avenger84 Er hat wohl was festes. Ich sehe das genauso, mit dem dynamischen Kram geht das nicht. Mach also weiterhin eine Form von NAT für IPv6.

 

[riversource]

Ja, NAT ist in diesem Fall natürlich erheblich einfacher. Mit dynamischen IPs wird es schwierig, da man bei Wireguard dann auch immer die Client Konfig anpassen muss. Das ist einer der Vorteile von OpenVPN, wo das Adressmanagement komplett auf Serverseite stattfinden kann. Da könnte man den Prozess komplett automatisieren.

 

[Avenger84]

ok, danke euch

 

[Avenger84]

ich brauche noch mal eure Hilfe.

Bin lediglich vom RPi auf eine VM umgezogen, so dass beide Netzwerke nun von VMs mit Wireguard verbunden werden.
eth0 habe ich natürlich korrekt angepasst.

Der Tunnel stand auch sofort zwischen den beiden Netzwerken.

Auch die Roadwarriors funktionieren inkl. Internetzugriff und neuem DNS - alles angepasst.

Nur ich komme nicht mehr vom Roadwarrior -> Zuhause -> Arbeitsnetz

Roadwarrior -> Zuhause kein Problem
Roadwarrior -> Zuhause -> Internet kein Problem

umgekehrt
Roadwarrior -> Arbeit -> Zuhause kein Problem

Die beiden Routen sind unverändert in den FritzBoxen eingetragen. wg.conf exakt gleich bis auf eth0.

Das einzige was mich stutzig machte war, dass der RPi in der FritzBox noch seine alte IP Adresse hatte, obwohl im Pi geändert (von .5 auf .16)
Habe dann seine Portfreigaben gelöscht und dann manuell in der FB seine IP auf die richtige geändert.
Danach die Ubuntu VM ausgwählt und die Portfreigabe angelegt.

Mit "Netzwork Analyzer Pro" auf Android komme ich auch nicht weiter.
Wenn ich hier eine Routenverfolgung mache zeigt er mir beim Arbeitsnetzwerk an:
1 - Wireguard Server IP Arbeit (pihole)
2 - grau (keine Info - FritzBox vermute ich)
3 - Netzwerkgerät Zuhause

Umgekehrt
1 - Wireguard Server IP Zuhause
2 - grau
usw. alles grau

FritzBox auch schon neu gestartet

Wenn ihr noch einen Tipp habt was ich wie testen kann wäre ich dankbar.
@riversource

P.S. die neue VM läuft auf Unraid (die ältere auf Synology).
Muss man hier noch eine zusätzliche Route setzen, die es bei Synology nicht braucht

 

[riversource]

Geh Schritt für Schritt vor und analysiere, wo die Daten noch fließen.

• kann die VPN VM zu Hause aufs Arbeitsnetz zugreifen?
• kann der Host zu Hause, auf dem die VM läuft, aufs Arbeitsnetz zugreifen?
• kann dein Heimnetz aufs Arbeitsnetz zugreifen?
• Analysiere auf der VPN VM zu Hause den Traffic mit tcpdump. Was kommt vom VPN Client, wo geht es hin?
• das gleiche auf der VPN VM bei der Arbeit. Was kommt da an, wo geht es hin, was passiert mit möglichen Antworten?

Durch die Umstellung hast du nun ja ein Netzwerk mehr im Spielt, nämlich das Host-Netzwerk des Servers zu Hause auf dem die VM läuft. Das musst du entsprechend berücksichtigen, wie auch immer du das realisiert hast.

 

[Avenger84]

Habe den Fehler gefunden, ich hatte ein 3. Netzwerk mit eingebunden letzte Woche, war mir aber 100% sicher, den Zugriff danach erfolgreich ausprobiert zu haben. Egal, hab mich geirrt und bin selbst Schuld.

[Interface]
Address = 192.168.99.10/24, fd08::10/64
ListenPort = 51821
PrivateKey = ...
MTU = 1412

PostUp = iptables -A FORWARD -i %i -j ACCEPT
PostUp = iptables -A FORWARD -o %i -j ACCEPT
# PostUp = iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostUp = ip6tables -A FORWARD -i %i -j ACCEPT
PostUp = ip6tables -A FORWARD -o %i -j ACCEPT
PostUp = ip6tables -t nat -A POSTROUTING -o ens3 -j MASQUERADE

PostDown = iptables -D FORWARD -i %i -j ACCEPT
PostDown = iptables -D FORWARD -o %i -j ACCEPT
# PostDown = iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i %i -j ACCEPT
PostDown = ip6tables -D FORWARD -o %i -j ACCEPT
PostDown = ip6tables -t nat -D POSTROUTING -o ens3 -j MASQUERADE

[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.0/24, 192.168.168.0/24, fd08::/64, fd00:aaaa::/64
[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.11/32, fd08::11/128
[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.12/32, fd08::12/128
[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.13/32, fd08::13/128
[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.14/32, fd08::14/128
[Peer]
PublicKey = .
AllowedIPs = 192.168.99.15/32, fd08::15/128
[Peer] #neues Netzwerk C
PublicKey = ...
AllowedIPs = 192.168.99.20/32, 192.168.1.0/24, fd08::20/128 # so klappt es
             192.168.99.0/24, # so klappt es nicht

Der RPi hat die 99.20 / fd08::20 / LAN: 192.168.1.x

Wenn ich den genau so im Netzwerk B route wie nach Hause, klappt die Route nicht.
Wenn ich ihm eine einzelne "AllowedIP" gebe, klappt es wieder vom Roadwarrior -> Netzwerk A -> Netzwerk B.
Fehler liegt beim Routing in Wireguards Netzwerk B.

@riversource hast du ne Idee wie ich das besser routen kann?
Am tollsten wäre, wenn ich von allen Netzwerken auf alle Netzwerke zugreifen könnte.

 

[riversource]

Bei den Allowed IPs für die Clients macht es grundsätzlich keinen Sinn, das Transportnetz mit /24 anzugeben. Denn auf der anderen Seite kann aus dem Transportnetz ja immer nur maximal eine Adresse sein. Wenn es darum geht, der anderen Seite Zugriff auf das ganze Transportnetz zu geben, dann muss das auf der anderen Seite geregelt werden.

Beim Routing in Wireguard gilt generell: Welche IPs sollen über den Tunnel auf der anderen Seite erreicht werden können? Die gehören in die Allowed IPs. Ein Beispiel:

In der Server Konfig gibt es 2 Clients jeweils mit einem eigenen Netz und einen Roadwarrior:

[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.1/32, 192.168.168.0/24

[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.2/32, 192.168.1.0/24

[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.3/32

Client 1 hätte in seiner Konfig:

[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.0/24, 192.168.1.0/24

Er soll ja das Netz von Client 2 und das Transportnetz erreichen können. Man könnte als drittes Netz auch noch das LAN hinter dem VPN Server angeben, wenn es eines gibt.

Folglich muss Client 2 das Netz von Client 1 über VPN erreichen:

[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.0/24, 192.168.168.0/24

Ein Raodwarrior soll beide Client Netze und das Transportnetz erreichen können:

[Peer]
PublicKey = ...
AllowedIPs = 192.168.99.0/24, 192.168.1.0/24, 192.168.168.0/24

So dürfen alle erforderlichen IPs über VPN fließen. Das heißt aber noch nicht, dass sie das auch tun. Denn in den Client Netzen müssen die Geräte ja auch wissen, dass sie das fremde Netz der anderen Clients hinter dem VPN suchen müssen. Am einfachsten geht das durch das Einrichten statischer Routen auf dem jeweiligen Default Gateway. Geht das nicht, dann muss jedes einzelne Endgerät darüber informiert werden, wo die jeweils anderen IPs zu suchen sind.

 

[Avenger84]

Ich habe es so langsam verstanden, denke ich zumindest

Was ich nicht schaffe: von Netz A über Netz B auf Netz C zuzugreifen.

Denn in Netz B muss ich ja dann bei zwei Peers die gleiche Allowed IP eintragen (für die Rückroute).
Sobald in zwei Peers die gleiche Allowed IP eingetragen ist, geht nichts mehr.

Geht sowas nur mit Masquarade ? Wovon mir ja abgeraten wurde.

Bei den Allowed IPs für die Clients macht es grundsätzlich keinen Sinn, das Transportnetz mit /24 anzugeben.

Sehe ich auch so, aber dann erstellt Wireguard beim Starten zig zusätzliche Routen, daher habe ich es bei /64 gelassen. Hatte ich auf S.1 aber schon geschrieben.

 

[Bob.Dig]

/24 ist IPv4, /64 ist IPv6, quasi.

Warum für die Rückroute? Ich meine, es reicht in eine Richtung, also immer der Route nach. Für die Clients empfiehlt sich eh 0.0.0.0/0

Und es gibt so was wie *Sense Router, wenn man nicht so auf die Console steht. 😉

 

[Avenger84]

Nein es reicht nicht eine Richtung.

Hier mal eine Skizze, ist leider etwas unübersichtlich geworden.

Wunschroute, die ich nicht hin kriege wäre von Netzwerk 1 zu Netzwerk 3 (durch Netzwerk 2).

Das Quellpaket hat die 192.168.168.20.
Die geht ohne Probleme zu Netzwerk 2 und auch wieder zurück.
Um nach Netzwerk 3 zu kommen, müsste ich eine Route in Netzwerk 1 hinzufügen = 192.168.1.0/24 -> 192.168.168.5 (WG1), dann geht das Paket zu WG1 von dort durch den Tunnel zu WG2, von dort direkt in den nächsten Tunnel zu WG3.
Aber es kann nicht zurück, da im Peer (orange, WG2) die AllowedIP 192.168.168.0/24 oder 192.168.168.20/32 fehlt. Trage ich die nun dort ein, sind in einer wg0.conf in zwei verschiedenen Peers die gleichen Routen eingetragen, was nicht funktioniert.

Ergänzung (4. Oktober 2023)

Nachtrag:
von Netzwerk 1 per Roadwarrior schaffe ich es auch über Netzwerk 2 zu Netzwerk 3.
(rot neu)

 

[Avenger84]

Bei den Allowed IPs für die Clients macht es grundsätzlich keinen Sinn, das Transportnetz mit /24 anzugeben.

P.S. das habe ich aus einem anderen Forum:

Die wg Adresse deines Roadwarriors ist falsch!! Als eigene Adresse gibt man immer die Maske des verwendeten IP Netzes an also /24! Das gilt auch für die Pi Clients.
Nur in den "Allowed" IP bestimmst du mit der Maske welcher Traffic in den Tunnel geroutet wird. Eine /32 ist eine Hostmaske und lässt dann explizit nur diesen Traffic durch. /24 dann z.B. das gesamte Netz.
Das solltest du also korrigieren.

 

[riversource]

Nachtrag:
von Netzwerk 1 per Roadwarrior schaffe ich es auch über Netzwerk 2 zu Netzwerk 3.
(rot neu)

So, wie du in wg1 neu die 192.168.1.0/24 eingetragen hast, so musst du natürlich auch die 192.168.168.0/24 in wg3 eintragen. Woher soll Netz 3 denn sonst den Rückweg kennen? Und denke ggf. an statische Routen für die Verbindungen. Für den Roadwarrior machst du vermutlich NAT, deshalb geht es da schon. Mach dir deshalb auch noch mal klar, wo du NAT anwendest und wo du das auch wirklich willst.

Die wg Adresse deines Roadwarriors ist falsch!! Als eigene Adresse gibt man immer die Maske des verwendeten IP Netzes an also /24! Das gilt auch für die Pi Clients.

Und warum? Ich bin ja gern bereit, dazuzulernen, aber welchen Grund sollte das haben? Was wird dadurch besser?

 

[Avenger84]

Funktioniert nun, manchmal sieht man den Wald vor lauter Bäumen nicht mehr.
Bei den Roadwarriors verwende ich eben kein NAT mehr, daher ist es so kompliziert geworden mit den ganzen Allowed IPs.
---
Grund keine Ahnung, kann ich dir nicht sagen, hier der Link: https://administrator.de/forum/wire...oadwarrior-3133493086.html#comment-3146491093

---
Weißt du zufällig wie ein Route bei CGNAT funktioniert ?
Dort komme ich ja niemals rein von außen, aber wenn ich die Verbindung aufbaue, geht ja in jedem Fall die Rückroute. Wie funktioniert das rein Interesse halber?

 

[Bob.Dig]

Und warum? Ich bin ja gern bereit, dazuzulernen, aber welchen Grund sollte das haben? Was wird dadurch besser?

Nehmen wir an, Du hast einen Tunnel(Server) mit vielen einzelnen Peers. Nun soll einer der Peers auch einen der anderen Peers erreichen können, ohne, dass eine direkte Verbindung besteht. Dafür muss der aber auch wissen, dass das Netz größer ist als nur die beiden Endpunkte. So stell ich mir das zumindest als Laie vor.

Ergänzung (5. Oktober 2023)

Weißt du zufällig wie ein Route bei CGNAT funktioniert ?

CGNAT ist ja ein Problem, um überhaupt einen Tunnel aufzubauen. Das Routing, was wir hier besprochen haben, war ja immer das in den Tunneln, kann man also nicht vergleichen.
Der Tunnel sollten also über IPv6 aufgebaut werden. Ansonsten muss er bei IPv4 von der Seite aufgebaut werden, die nicht über IPv4 erreichbar ist und dann mittels keepalive aufrecht erhalten werden.