VPN Wireguard, Routing konfigurieren

[polyphase]

Moin,
ich musste meinen Wireguard VPN neu aufsetzen, bekomme aber das Routing nicht mehr hin.
Ich hatte glücklicherweise die Config des Tunnels selbst gesichert, aber nicht das Routing.

Hintergrund:
VPN Site to Site (1x Firewall und 1x Raspberry Pi hinter Fritzbox)
Beide Netzwerke sollen jeweils bestimmte IP Bereiche des anderen sehen,
bzw. ich muss das komplette Fritzbox Netzwerk sehen.

Der Tunnel steht und auch bei einem Neustart meiner Firewall bzw. des Raspberrys wird der Tunnel automatisch wieder aufgebaut.
Auf den Pi komme ich auch per SSH problemlos drauf (durch den Tunnel), nur die Geräte (IPs) dahinter sind nicht erreichbar.

Ich hatte mir das mit dem Routing irgendwo mal notiert, nur finde ich es nicht mehr. Ich weiß noch das ich etwas in die wg.conf eintragen musste. Das Problem ist das ich, wenn ich mir den Tunnel zerschieße, mehrere 100km zur Gegenstelle fahren muss, daher würde ich hier gerne nicht unbedingt experimentieren.

Die statischen Routen auf der Firewall bzw. FritzBox sind noch vorhanden, da ich nur den Raspberry neu aufsetzen musste.
Als System wird auf dem Pi Ubuntu Server verwendet.

Soweit ich weiß, war es eines der folgenden Einträge, oder liege ich falsch?

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

ODER

PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE

 

[WulfmanGER]

Das Problem ist das ich, wenn ich mir den Tunnel zerschieße, mehrere 100km zur Gegenstelle fahren muss, daher würde ich hier gerne nicht unbedingt experimentieren.

Du könntest dir ein Fallback-Option für die Gegenseite basteln:

Würde das so machen:
Entsprechende Konfigdateien sichern. Im Script kopierst du backup zu live (überschreiben y nicht vergessen). Dann per Cronjob die Datei nach x Minuten aufrufen lassen. WICHTIG - Entweder sehr großzügig die Zeit wählen (120min) oder immer wieder den Cronjob reseten - nicht das dir mitten im Testen alles zurückgeschrieben wird. Ist alles gut - Cronjob wieder löschen usw. (ggf. sollte der Cronjob auch nach, ungeplanten, reboot wieder gestartet werden)

Kenne das Thema von Ciscoroutern mit dem Abschießen (und da gibt es auch so eine Fallbackgeschichte)

 

[polyphase]

Danke für den Tipp 👍

Jetzt müsste ich nur noch wissen, welcher Eintrag der richtige ist 😅

Edit:
So ich habe jetzt nochmal nachgedacht:
Der Tunnel hat den IP Bereich 10.20.20.2/24
und der Netzwerk dahinter den Bereich 192.168.100.1/24.

Wenn ich jetzt nicht ganz auf dem Schlauch stehe, müsste doch in die wg.conf ein NAT rein, oder?

 

[Avenger84]

Hier meine wg config:

[Interface]
Address = 192.168.99.1/24, fd08::1/64
ListenPort = 51820
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 eth0 -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 eth0 -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 eth0 -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 eth0 -j MASQUERADE


[Peer]
PublicKey = ***=
AllowedIPs = 192.168.99.2/32, fd08::2/128
[Peer]
PublicKey = ***=
AllowedIPs = 192.168.99.3/32, fd08::3/128
[Peer]
PublicKey = ***=
AllowedIPs = 192.168.99.4/32, fd08::4/128
[Peer]
PublicKey = ***=
AllowedIPs = 192.168.99.5/32, fd08::5/128
[Peer]
PublicKey = ***=
AllowedIPs = 192.168.99.6/32, 192.168.74.0/24, fd08::6/128, fd00:bbbb::/32
Endpoint = myurl.dynv6.net:51821
PersistentKeepalive = 25

der letzte Eintrag stellt die dauerhafte Verbindung zwischen 2 Netzwerken her.
die Gegenstelle hat nur eine IPv6.
192.168.99.x und fd08: ist Wireguard

Zuhause habe ich 192.168.168.x und fd00:aaaa:
Gegenstelle hat 192.168.74.x und fd00:bbbb:

Der Tunnel läuft stabil mit 35-50 MB/s über zwei RPi4.
Ich kann von beiden Seiten alle Geräte über IPv4 und IPv6 erreichen, der Tunnel läuft über IPv6 (daher MTU).

Die ersten 4 sind "roadwarrior", also mobile Geräte die sich einwählen.

 

[polyphase]

Oha, das ist Mal ne Config 😅

Ich selbst habe aktuell nur IPv4.
Statische Routen gibt es schon, diese sind direkt in den Router konfiguriert.

Soweit ich das verstehe, hast du die NAT Einträge um in die unterschiedlichen Netze zu kommen und die anderen Einträge fürs Routen, oder?

 

[Raijin]

NAT hat in der Form (masquerade) nichts damit zu tun, "in die unterschiedlichen Netze zu kommen". An diesen Stellen maskiert das VPN-Gateway alle ausgehenden Pakete an eth0 mit seiner eigenen lokalen IP-Adresse. Im Prinzip dasselbe was der Internetrouter am WAN tut. Dadurch denken alle Geräte, die im lokalen Netzwerk sind, dass eingehende Verbindungen vom VPN-Gateway initiiert wurden (Quell-IP= lokale IP des VPN-Gateways). Das Zielgerät weiß also gar nichts davon, dass die Verbindung aus dem VPN kommt.

Ja, das kann man so machen. Problematisch wird es dann, wenn man am Zielgerät in irgendeiner Form zwischen lokalen Clients und Clients im VPN unterscheiden möchte. Das geht damn nämlich nicht. Der Nachteil von NAT/masquerade ist daher ein gewisser Kontrollverlust.

Andererseits sind ohne NAT/masquerade weitere Handgriffe notwendig. Zum einen muss das Routing stimmen, weil das Ziel im lokalen Netzwerk ohne NAT tatsächlich direkt vom Gerät in bzw. hinter dem VPN angesprochen wird (Quell-IP= VPN-IP des Clients oder ggfs lokale IP des Clients im Netzwerk hinter dem VPN bzw am anderen Standort). Einerseits braucht das Ziel dadurch von der eigenen Firewall eine Erlaubnis für die Verbindung von der "fremden" IP. Andererseits muss das Ziel eine Rückroute für die Antwort kennen, sei es durch die Standardroute (=> Internetrouter, der dann seinerseits eine Route ins VPN benötigt) oder aber durch eine Route direkt auf dem Gerät.


Der Weg via NAT ist insbesondere bei überschaubaren Kenntnissen die häufigstee Lösung, weil eine NAT-Regel am VPN-Gateway ausreicht. Der Weg ohne NAT ist komplexer, bietet aber die meiste Flexibilität. NAT ist an dieser Stelle ein wenig verpönt, weil es ein bischen Quick and Dirty ist. Manchmal geht es aber nicht anders, zB wenn der Internetrouter gar keine benutzerdefinierten Routen zulässt.

 

[Avenger84]

In den beiden FritzBoxen sind natürlich auch noch jeweils eine statische IPv4 & 6 Routen eingetragen.

Ergänzung (11. November 2021)

Der Weg ohne NAT ist komplexer, bietet aber die meiste Flexibilität. NAT ist an dieser Stelle ein wenig verpönt, weil es ein bischen Quick and Dirty ist.

that 👍

 

[polyphase]

Oh mann ich hab den Fehler! 🤦‍♂️

Diese Seite hier hatte die Lösung unter Punkt 4.1:
https://tech.serhatteker.com/post/2021-01/how-to-set-up-wireguard-vpn-server-on-ubuntu/

Es muss unter Ubuntu Server noch das IP Forwarding aktiviert werden, in der Datei:

/etc/sysctl.conf

Folgender Eintrag muss einkommentiert werden:

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

Jetzt erreiche ich auch die Geräte dahinter 👍


EDIT:
Jetzt brauche ich auch keinerlei iptables Regeln mehr in der wg.conf, deshalb war da auch in meinem Backup nix drin 😅