michsc33
Goto Top

Wireguard für einen Vollnoob

Liebes Forum,
ich habe ein Problem bei der Einrichtung meiner WireGuard-Verbindung und hoffe, dass ihr mir weiterhelfen könnt.

Grundsätzlich habe ich das großartige Tutorial hier gelesen und darauf mein Setup aufgebaut: Merkzettel

Zunächst ein kurzer Überblick über mein Setup:

  • FRITZ!Box 7590: mit dem neuesten Betriebssystem (Version 8.0.0).
  • Raspberry Pi 3B+: läuft mit dem Betriebssystem Raspbian in der aktuellsten Version (neueste Version November 24).
  • Travel-Router GL.iNet AT3000: ebenfalls mit einem aktuellen Betriebssystem (Version 4.7.0).

Netzwerktopologie:

  • Die FRITZ!Box steht bei meinen Eltern und stellt die Verbindung zum Internet her. Portforwarding wurde aktiviert und Port 65500 freigegeben (Ja ich weiß ist nicht zu bevorzugen aber ist die beste Lösung derzeit, weil WireGuard auf der FritzBox meines Erachtens sehr Buggy ist).
  • Der Raspberry Pi ist über den LAN-Port mit der FRITZ!Box verbunden. Auf ihm soll der Wireguard Server laufen.
  • Der Travel-Router dient als Client und soll eine Verbindung zum WireGuard-Server auf dem Raspberry Pi herstellen. Wie der Name schon sagt, soll er überall mitgenommen werden können. Im folgenden sollen noch weitere Travelrouter als Client hinzukommen. Der Einfachheit halber aber ersteinmal nur einer.
  • Ein Computer soll an dem Travelrouter per LAN angeschlossen werden. Nur der Travelrouter soll sich beispielsweise in fremde WLAN Netzwerke einwählen. Nur über den Travelrouter erhält der Computer eine Internetverbindung. Wenn diese gekappt wird soll durch einen Kill Switch der Computer vom Internet abgeschnitten werde. Alle Verbindungen des Computers sollen durch den VPN Tunnel geschickt werden.

Ich habe bereits folgende Schritte durchgeführt: WireGuard wurde erfolgreich auf dem Raspberry Pi installiert, und die entsprechenden Ports wurden in der FRITZ!Box für das Port-Forwarding geöffnet. Die Server config sieht folgendermaßen aus:

[Interface]
Address = 100.64.64.1/24
PrivateKey = XXXX
ListenPort = 65500

[Peer]
PublicKey = QyOyJ1sEdPEsVQ6uNjI4wxhLZPm1vP4GfK0wQFLr0U4=
AllowedIPs = 100.64.64.100/32, 192.168.178.0/24

Während der Client auf dem Travelrouter die folgende Config hat:

[Interface]
PrivateKey = XXXX
Address = 100.64.64.101/24
MTU = 1420

[Peer]
PublicKey = Tu++c41fd/GMrLps9p/1Et6iQ9FS+hPtZs4VKMn9smAM=
Endpoint =XXXX.myfritz.net:65500
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

Der Raspberry Pi hat Zugriff auf das Internet, was ich erfolgreich getestet habe (z. B. über ping www.google.de). Jedoch kann ich keine Verbindung zum Wireguard Server über den Travelrouter aufbauen. Auch der handshake zwischen server und client scheint nicht zu funktionieren. IP routing wurde auf dem Rasperri aktiviert. Folgender Befehl wude auf dem Rasperri ausgeführt:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Ich habe bereits verschiedene Konfigurationen ausprobiert, komme jedoch mit meinem aktuellen Wissen nicht weiter. Ich wäre euch sehr dankbar, wenn ihr mir helfen könntet. Irgendwie bekomme ich das nicht auf die Kette ☹

Vielen Dank für eure Unterstützung!

Beste Grüße

Michael

Content-ID: 670767

Url: https://administrator.de/forum/wireguard-fuer-einen-vollnoob-670767.html

Ausgedruckt am: 22.02.2025 um 04:02 Uhr

Avenga
Avenga 18.01.2025 aktualisiert um 07:49:42 Uhr
Goto Top
Mit deinem Travelrouter kenne ich mich nicht aus / sagt mir nichts aber in der Wireguard Konfig fehlt m.E. nach noch die "Forward" Regeln.
Hier meine Konfig, aber mit nftabels (iptables sind veraltet)
[Interface]
Address = 192.168.99.1/24, fd08::1/64
ListenPort = 51820
PrivateKey = xyz
MTU = 1412
PostUp = nft add table ip filter
PostUp = nft add table ip6 filter
PostUp = nft add chain ip filter FORWARD '{ type filter hook forward priority 0; policy accept; }'  
PostUp = nft add chain ip6 filter FORWARD '{ type filter hook forward priority 0; policy accept; }'  
PostUp = nft add rule ip filter FORWARD iifname "%i" counter accept  
PostUp = nft add rule ip filter FORWARD oifname "%i" counter accept  
PostUp = nft add rule ip6 filter FORWARD iifname "%i" counter accept  
PostUp = nft add rule ip6 filter FORWARD oifname "%i" counter accept  
PostDown = nft flush ruleset
[Peer]
PublicKey = xy
AllowedIPs = 192.168.99.2/32, fd08::2/128
[Peer]
PublicKey = xy
AllowedIPs = 192.168.99.3/32, fd08::3/128
[Peer]
PublicKey = xy
AllowedIPs = 192.168.99.4/32, fd08::4/128
[Peer]
PublicKey = xy
AllowedIPs = 192.168.99.5/32, fd08::5/128
[Peer]
PublicKey = xy
AllowedIPs = 192.168.99.10/32, 192.168.99.20/32, 192.168.74.0/24, 192.168.75.0/24
AllowedIPs = fd08::10/128, fd08::20/128, fd00:bbbb::/64, fd00:cccc::/64
Endpoint = endpoint.dynv6.net:51821
PersistentKeepalive = 25
IPv6 brauchst du natürlich nicht unbedingt.
Hinweis: Mein letzter Peer ist eine dauerhafte Verbindung zu Büro1, von Büro1 gibt es wiederum eine dauerhafte Verbindung zu Büro2. Alle Geräte sind von allen Netzwerken aus erreichbar über IPv4 und IPv6.

NAT habe ich erfolgreich verbannt, dazu musst du in der FB passende Routen eintragen:
clipboard-image
clipboard-image

Finde ich besser so.

IP Forwarding hast du aktiviert in /etc/sysctl.conf ?
aqui
aqui 18.01.2025 aktualisiert um 09:56:33 Uhr
Goto Top
Folgender Befehl wude auf dem Rasperri ausgeführt:
Was leider zeigt das du das o.a. WG Tutorial nicht gelesen hast! 😡
Das Tutorial rät wie viele andere auch dringenst von einem NAT (Adress Translation) innerhalb des internen WG Netzes dringend ab.
Ein NAT / Masquerading ist bei einer Heimnetzanbindung völlig überflüssig und schafft durch die dann bestehende "Routing Einbahnstrasse" erhebliche Folgeprobleme bei transparentem Routing.
Entferne also unbedingt diese NAT iptables Kommandos aus deiner Konfig die sind überflüssig und werden nicht benötigt! Mal ganz davon abgesehen haben sie so oder so keine Auswirkungen weil im aktuellen Raspberry Pi OS "Bookworm" die nftables Default sind.

Eine weiterer grober Kardinalsfehler ist das dein Client die interne Hostadresse .101 hat auf dem Server aber für den Client Peer fälschlicherweise die .100 definiert ist.
Diese beiden Geräte können also niemals zueinander kommen. Solche gravierenden Tippfehler sollten einem eigentlich sofort ins Auge springen! face-sad
Bis auf diesen gravierenden Fehler sind deine WG Konfigs ansonsten soweit richtig. Was das globale Redirect am Client (0.0.0.0/0) angeht hast du das entsprechende Kapitel im Tutorial dazu sicher gelesen?!

WG auf der Fritzbox ist keineswegs buggy, vergiss diesen Unsinn! Millionen Privatkunden würden dann erwartungsgemäß AVM die Hölle heiss machen.
Was aber der Fall ist bei der Fritte ist die nicht Standard konforme WG Implementation von AVM, die eine Anpassung der Konfiguration erfordert. Das o.a. Tutorial hat deshalb ein extra Kapitel was das Thema WG auf der Fritte in Verbindung mit anderen WG Clients anbetrifft.
Mit anderen Worten: Man könnte also auch genausogut das WG der Fritte verwenden als Server.
Deine Lösung mt einem separaten Server ist zwar dadurch eigentlich überflüssig und umständlicher klappt aber natürlich auch.
Das Tutorial hat ein ausführliches Beispiel zu diesem Setup mit extra Server und Port Forwarding in den weiterführenden Links.

Eine wichtige Frage hast du nicht beantwortet nämlich WAS für eine Art Provider Anschluss auf der Server Seite (Eltern) vorhanden ist??
Sollte das ein DS-Lite oder ein CG-NAT Provider Anschluss sein wird dein Projekt zu mindestens mit IPv4 grundsätzlich scheitern weil mit solchen Provider Anschlüssen technisch kein Zugriff mit IPv4 von außen möglich ist!
Hier muss also IPv6 zum Einsatz kommen oder du musst einen externen Jumphost bei IPv4 verwenden. Nur das du das auf deinem Radar hast!
Ein Beispielsetup für einen GL.inet Travel Router findest du HIER.

Ob die Serverseite ein DS-Lite Opfer ist kannst du sehr einfach auf deinem Raspberry checken indem du dir einen einfachen IP Paketsniffer installierst und einmal deinen Wireguard Port 65500 checkst ob dort überhaupt von außen über die Fritte eingehender Wireguard Traffic mit Port UDP 65500 ankommt. Das ist schnell und einfach gemacht mit
  • apt update dann den Sniffer mit apt install tcpdump installieren
  • Den Sniffer mit tcpdump -i eth0 port 65500 starten udn von extern mit einem Client eine WG Verbindung öffnen. Nun solltest du eingehenden Traffic im Sniffer sehen
  • <ctrl> c stoppt den Sniffer wieder.
  • Ob ein Tunnel zustande gekommen ist zeigt dir dann auch ein wg show
Dieser Check hat den Vorteil das damit auch gleich das Port Forwarding an der Fritte geprüft wird.
Kommt wider Erwarten kein Traffic an deinem RasPi WG Server an hat das genau 2 Gründe
  • Deine Port Weiterleitung in der Fritte ist falsch oder fehlerhaft.
  • Deine Serverseite hängt an einem DS-Lite Provider und kann deshalb technisch grundsätzlich keine aus dem Internet eingehenden IPv4 Verbindungen annehmen.
Dieser Check ist sehr wichtig um generell zu prüfen das WG Traffic überhaupt an deinem WG Server ankommt und so grundsätzlich ein VPN zustande kommen kann.
Bedenke auch, sollte sich ein DS-Lite Anschluss herausstellen, du keine interne RFC 6598 Adressierung verwenden darfst. (100.64.0.0/10 Adressen)
Also alles kein Hexenwerk wenn man beim Troubleshooting startegisch und sinnvoll vorgeht... face-wink
Avenga
Avenga 18.01.2025 aktualisiert um 12:22:42 Uhr
Goto Top
Mal ganz davon abgesehen haben sie so oder so keine Auswirkungen weil im aktuellen Raspberry Pi OS "Bookworm" die nftables Default sind.

"Klug###modus an", wenn man iptables installiert, werden die Regeln passend zu nftables übersetzt und umgekehrt. Hatte ich bis gestern auch so am laufen, bis ich es endlich geschafft hatte, sie zu nft zu übersetzen. Siehe mein Thema
aqui
aqui 18.01.2025 aktualisiert um 12:54:59 Uhr
Goto Top
Das ist was die xytables anbetrifft soweit richtig, keine Frage. Dennoch ist ein Masquerading (NAT) im internen WG IP Netz was der TO oben gemacht hat aber völlig unsinnig und auch kontraproduktiv, da er sich damit eine routingtechnische Einbahnstrasse schafft.
Auch das Implementieren der nftables Regeln innerhalb des WG Setups ist ebenso keine gute best practise Lösung. Wenn, dann sollte die immer unabhängig vom Client und separat in den /etc/nftables.conf gesetzt sein wie es z.B. hier beschrieben ist für einen Server mit öffentlichem Zugang.
Wenn man nur eigene, vertrauenswürdige IP Netze und VPN Clients bedient ist ein internes Firewalling bei einem Kaskaden Setup so oder so überflüssig.
Hauptfehler des TOs ist aber die falsche und nicht zueinander passende interne IP Adressierung vom WG Client und dem dazu korrespondierendem Client Peer im Server was im sofort hätte auffallen müssen. face-sad
MichSc33
MichSc33 24.01.2025 um 01:02:04 Uhr
Goto Top
Hallo ihr lieben,

vielen Dank für eure Antworten. War dann wohl doch etwas spät als den Thread eröffnet habe face-smile Nun noch einmal der Reihe nach alle Schritte:

1. Portforwarding an der FritzBox

clipboard-image

Hier der output von sudo tcpdump -i eth0 port 65500:

00:54:00.639697 IP msraspberrypi.fritz.box.65500 > p54b2e6ee.dip0.t-ipconnect.de.53036: UDP, length 148
00:54:05.679673 IP msraspberrypi.fritz.box.65500 > p54b2e6ee.dip0.t-ipconnect.de.53036: UDP, length 148
00:54:10.719748 IP msraspberrypi.fritz.box.65500 > p54b2e6ee.dip0.t-ipconnect.de.53036: UDP, length 148
00:54:16.079655 IP msraspberrypi.fritz.box.65500 > p54b2e6ee.dip0.t-ipconnect.de.53036: UDP, length 148
00:54:21.119715 IP msraspberrypi.fritz.box.65500 > p54b2e6ee.dip0.t-ipconnect.de.53036: UDP, length 148
00:54:26.319694 IP msraspberrypi.fritz.box.65500 > p54b2e6ee.dip0.t-ipconnect.de.53036: UDP, length 148
Müsste ja eigentlich passen so wie ich das sehe.

2. Hier meine statische IP-Routing v4 Tabelle

clipboard-image

3. Packet forwarding für IPv4 ist auf net.ipv4.ip_forward=1gesetzt


4. Anbei meine Server und Client config:

                                                                                        
[Interface]
Address = 100.64.64.1/24
PrivateKey = XXX
ListenPort = 65500

[Peer]
PublicKey = QyOyJlSEdPEsVQ6uNjI4WxhLZPmlvP4GfKOwQFLr0U4=
AllowedIPs = 100.64.64.100/32, 192.168.200.0/24
PersistentKeepAlive = 25
 

und

[Interface]
PrivateKey = XXX
Address = 100.64.64.101/24
DNS = 192.168.200.1
MTU = 1420

[Peer]
PublicKey = Tu++c41fd/GMrLps9p/1Et6iQ9FS+hPtZ4VKMn9smAM=
AllowedIPs = 0.0.0.0/0
Endpoint =MEINROUTER.myfritz.net:65500
PersistentKeepalive = 25 

Hinter einem CGNAT befinde ich mich auch nicht, da ich mittlerweile Wireguard auf der Fritzbox eingerichtet habe und auch bieringer.net grünes Licht gibt.

Ich kann mich auch zum Server auf meinem Rasperri verbinden aber bekomme eben kein internet und auf die FritzBox zugreifen kann ich auch nicht. Der Client zeigt mir auch an, das Traffic in beide Richtungen fließt.

wg show zeigt mir folgendes:

XXX@msraspberrypi:/etc/wireguard $ sudo wg show
interface: wg0
  public key: Tu++c41fd/GMrLps9p/1Et6iQ9FS+hPtZ4VKMn9smAM=
  private key: (hidden)
  listening port: 65500

peer: QyOyJlSEdPEsVQ6uNjI4WxhLZPmlvP4GfKOwQFLr0U4=
  endpoint: 84.178.234.66:64629
  allowed ips: 100.64.64.100/32, 192.168.200.0/24
  latest handshake: 42 seconds ago
  transfer: 360 B received, 563.54 KiB sent
  persistent keepalive: every 25 seconds

Irgendwie bin ich da etwas ratlos bzw. mir fehlt etwas das Hintergrundwissen, an was es noch liegen könnte face-sad
Avenga
Avenga 24.01.2025 um 07:44:54 Uhr
Goto Top
Was ist mit den Postup nft "forward" Regeln, die ich dir nahe gelegt habe? Diese sehe ich nirgends.
MichSc33
MichSc33 24.01.2025 um 11:14:59 Uhr
Goto Top
Hm, ich hatte mich da an aquis Anleitung gehalten, der ja das Masquerading explizit als nicht notwendig deklariert hat. Aber man könnte es ja mal probieren. Ich kann mit meinem Wissen derzeit immer noch nicht richtig abschätzen welche Veränderung, welche Auswirkung hat.
Avenga
Avenga 24.01.2025 um 12:14:57 Uhr
Goto Top
Nein nicht das maskieren, das forwarden erlauben
aqui
aqui 24.01.2025 aktualisiert um 14:41:47 Uhr
Goto Top
Anbei meine Server und Client config:
Dort stimmt irgendwas nicht! face-sad
Das lokale LAN der Fritte in dem auch der WG Server ist doch das .200.0 /24er Netz, oder?
Ein Peer Statement: AllowedIPs = 100.64.64.100/32, 192.168.200.0/24 ist dann dort doch falsch für den remoten Peer!
Die "AllowedIPs" bezeichnen immer die Zieladressen die in den Tunnel geforwardet werden und da ist es dann doch sinnfrei das eigene, lokale IP Netz anzugeben in dem der Server steht! Das "Merkzettel" Tutorial beschreibt dies doch explizit im Abschnitt VPN Server (Responder).
Hier muss also das remote Zielnetz stehen, niemals aber die .200.0 die der Server so oder so kennt weil er in diesem IP Netz doch selber platziert ist.
Außerdem ist die Client IP immer noch falsch wie Kollege @151183 unten richtig bemerkt. Dieser Kardinalsfehler bewirkt eh das nix klappen kann! face-sad
Ein weiterer Fehler ist das sinnfreie Keepalive auf dem Server! Der Server (Responder) macht KEIN Keepalive auf die sich einwählenden Clients. Das macht ausschliessich nur der Client worauf auch der Merkzettel explizit hinweist. face-sad Entferne das Keepalive also vom Server.
Dritter Fehler: Die Default MTU musst du am Client nicht konfigurieren. Lasse solchen überflüssigen Firlefanz weg.
Solche banalen Tippfehler sollte man eigentlich nach 10maligem Bearbeiten der Konfig Dateien beim Troubleshooting nun endlich auch selber einmal erkennen. 🙄
Wenn an den Client kein lokales Netz geforwardet werden soll, dann steht dort in der Peer Definition des Clients auf dem Server einzig nur dessen interne /32er IP und mehr nicht!
nft Rules in der WG Konfig benötigst du de facto nicht, das ist richtig.
Hier hast du also noch mehrere Konfig Fehler zu bereinigen! Du musst auch das was man dir postet einmal gewissenhaft umsetzen. Auch an einem Freitag... 🐟

Server:
[Interface]
Address = 100.64.64.1/24
PrivateKey = XXX
ListenPort = 65500

[Peer]
PublicKey = QyOyJlSEdPEsVQ6uNjI4WxhLZPmlvP4GfKOwQFLr0U4=
AllowedIPs = 100.64.64.100/32
<-- Client

Client:
[Interface]
PrivateKey = XXX
Address = 100.64.64.100/24
DNS = 192.168.200.1

[Peer]
PublicKey = Tu++c41fd/GMrLps9p/1Et6iQ9FS+hPtZ4VKMn9smAM=
AllowedIPs = 0.0.0.0/0
Endpoint =MEINROUTER.myfritz.net:65500
PersistentKeepalive = 25


So wird ein Wireguard Schuh draus...!
Eigentlich ist bei einer modernen Fritte der zusätzliche RasPi Server überflüssig, denn das WG direkt auf der Fritte kann das auch mit links und ist keineswegs "buggy" wenn man die Eigenarten der nicht Standard konformen WG Implementation bei AVM Fritten beachtet. Wie das geht steht im Detail HIER.
151183
151183 24.01.2025 aktualisiert um 14:17:42 Uhr
Goto Top
Btw. ist die IP des Clients im letzten Post auch immer noch falsch

Beim Client steht im Interface bei dir
Address = 100.64.64.101/24
Und am Server für den Peer
AllowedIPs = 100.64.64.100/32,

Das kann ja nicht lüppen ...
Avenga
Avenga 24.01.2025 aktualisiert um 16:38:51 Uhr
Goto Top
Hab´s mir auch noch mal in Ruhe durchgelesen.
ich versteh die Route nicht: 192.168.0.0 -> 192.168.200.254
für wen/was ist die? andere Baustelle?

Server:
[Interface]
Address = 100.64.64.1/24
PrivateKey = XXX
ListenPort = 65500
MTU = wenn nur hier
PostUp = nft add table ip filter
#PostUp = nft add table ip6 filter
PostUp = nft add chain ip filter FORWARD '{ type filter hook forward priority 0; policy accept; }'  
#PostUp = nft add chain ip6 filter FORWARD '{ type filter hook forward priority 0; policy accept; }' 
PostUp = nft add rule ip filter FORWARD iifname "%i" counter accept  
PostUp = nft add rule ip filter FORWARD oifname "%i" counter accept  
#PostUp = nft add rule ip6 filter FORWARD iifname "%i" counter accept 
#PostUp = nft add rule ip6 filter FORWARD oifname "%i" counter accept 
PostDown = nft flush ruleset
[Peer]
PublicKey = QyOyJlSEdPEsVQ6uNjI4WxhLZPmlvP4GfKOwQFLr0U4=
AllowedIPs = 100.64.64.100/32


Client:
[Interface]
PrivateKey = XXX
Address = 100.64.64.100/24
DNS = 192.168.200.1 

[Peer]
PublicKey = Tu++c41fd/GMrLps9p/1Et6iQ9FS+hPtZ4VKMn9smAM=
AllowedIPs = 0.0.0.0/0
Endpoint =MEINROUTER.myfritz.net:65500

192.168.200.1 -> FritzBox
192.168.200.254 -> RPi

Bin kein Firewall Experte, aber bei mir lief noch kein Wireguard ohne die Forward Regeln.

Oder gleich für Dual Stack:
Server:
[Interface]
Address = 100.64.64.1/24, fd08:64::1/64
PrivateKey = XXX
ListenPort = 65500
MTU = wenn nur hier
PostUp = nft add table ip filter
PostUp = nft add table ip6 filter
PostUp = nft add chain ip filter FORWARD '{ type filter hook forward priority 0; policy accept; }'  
PostUp = nft add chain ip6 filter FORWARD '{ type filter hook forward priority 0; policy accept; }'  
PostUp = nft add rule ip filter FORWARD iifname "%i" counter accept  
PostUp = nft add rule ip filter FORWARD oifname "%i" counter accept  
PostUp = nft add rule ip6 filter FORWARD iifname "%i" counter accept  
PostUp = nft add rule ip6 filter FORWARD oifname "%i" counter accept  
PostUp = nft add rule ip6 nat POSTROUTING ip6 saddr { fd08:64::100 } oifname "eth0" counter masquerade  
PostDown = nft flush ruleset
[Peer]
PublicKey = QyOyJlSEdPEsVQ6uNjI4WxhLZPmlvP4GfKOwQFLr0U4=
AllowedIPs = 100.64.64.100/32, fd08:64::100/128

Client:
[Interface]
PrivateKey = XXX
Address = 100.64.64.100/24, fd08:64::100/64
DNS = 192.168.200.1

[Peer]
PublicKey = Tu++c41fd/GMrLps9p/1Et6iQ9FS+hPtZ4VKMn9smAM=
AllowedIPs =  0.0.0.0/0, ::/0
Endpoint =MEINROUTER.myfritz.net:65500
aqui
aqui 24.01.2025 aktualisiert um 17:57:29 Uhr
Goto Top
ich versteh die Route nicht: 192.168.0.0 -> 192.168.200.254
Was genau ist da für dich unverständlich?? 🤔
Diese Route besagt: "Route alles was eine Zieladresse von 192.168.0.0 bis 192.168.63.255 hat an die Router Adresse 192.168.200.254". Dieser Router an 192.168.200.254 wird schon wissen wo diese Zielnetze sind!

Die Range der Zieladressen 192.168.0.0 bis 192.168.63.255 kommt deshalb zustande weil oben eine Subnetz Maske 255.255.292.0 angegeben worden ist und so das die Fritte alle /24er Netze von .0.0 bis .63.0 bzw. Zieladressen die bei ihr ankommen dahin geroutet werden. Der Wireguard Server agiert ja als Router der die remoten Peer IP Netze bedient per Crypto Routing.
Hätte man beispielsweise 255.255.0.0 mitgegeben (was ebenso korrekt wäre) würden alle 192.168.x.y Zieladressen an den Router .200.254 gesendet.
Hätte die Fritte diese statische Route NICHT, dann würde sie alle IP Adressen dieser dort angegebenen Zielnetze über ihre Default Route, also den Internet Provider, ins IP Nirwana gesendet. Nirwana deshalb, weil private RFC1918 Netze im Internet bekanntlich nicht geroutet werden.

Diese statischen Routen sind zwingend wenn man nicht mit diesem sinnfreien und Performance fressenden NAT/Masquerading innerhalb des Tunnels arbeiten will und muss. Ein NAT/Masquerading innerhalb des Tunnels verhindert durch das damit einhergehende NAT Firewalling ein transparentes Routing so das ein Session Aufbau lokal in Richtung Client technisch unmöglich wird. Siehe auch IP Routing Grundlagen.

Firewall Rules und auch NAT haben im VPN Client nichts oder nur in sehr seltenen Ausnahmefällen etwas zu suchen. Wenn will man ja immer transparent routen ohne überflüssige NAT Frickelei.
Wenn man meint das man das unbedingt benötigt konfiguriert man das immer statisch im nftables Regelwerk unter /etc/nftables.conf.
Avenga
Avenga 24.01.2025 um 21:43:14 Uhr
Goto Top
Was genau ist da für dich unverständlich?

Was der TE mit diesem weiten IP Bereich vor hat erschließt sich mir nicht (kein Fritz Netz, kein Wireguard Netz).

add rule ip filter FORWARD iifname "%i" counter accept
add rule ip filter FORWARD oifname "%i" counter accept

Die beiden Regeln sorgen dafür, dass sowohl eingehender als auch ausgehender Verkehr für das WireGuard-Interface durch die Firewall zugelassen wird. Das ist notwendig, damit WireGuard ordnungsgemäß funktioniert, da es sowohl Pakete empfangen als auch senden muss. Wenn diese Regeln nicht vorhanden sind, könnte der Verkehr blockiert werden, was die VPN-Verbindung unterbrechen würde.
Ohne die Regeln geht bei mir nichts, warum weiß ich nicht, so wie die KI sagt wird die Verbindung unterbrochen.

Source NAT IPv6 brauche ich nur für die Mobilgeräte mit Volltunnel, damit diese über meinen VPN Server (Zuhause) ins Internet kommen, da eine fd08::2 nicht vom Internet zurück geroutet werden kann. Bei IPv4 nicht nötig, da die FritzBox NAT macht. Eine Möglichkeit meinen dynamischen Prävix (ändert sich alle 24h) ins interne WG Netz zu kriegen sehe ich nicht.

Für den Rest habe ich die statischen Routen eingerichtet (dank Aqui vor langer Zeit face-smile
aqui
aqui 24.01.2025 um 22:00:44 Uhr
Goto Top
Quelle KI sagt ja wieder alles und muss man sicher nicht weiter kommentieren. Da bekommt man von Frau oder Freundin bessere Antworten!
Das Argument mit der Firewall ist völliger Unsinn, denn die kann ja nicht in den verschlüsselten Datenstrom im VPN Tunnel "sehen". Genau deswegen nutzt man ja ein VPN. Das kommt raus wenn sich eine halluzinierende KI an Netzwerk Design und Setup versucht. 🤣
Ohne die Regeln geht bei mir nichts
Ist auch kein Wunder weil bei dir dann vermutlich die statischen Routen auf den WG Server fehlen. face-wink
MichSc33
MichSc33 27.01.2025 um 10:44:15 Uhr
Goto Top
Hi ihr Lieben,

vielen Dank nochmals für eure Hilfe. Interessant ist ja schon, auch bei mir hat es auch erst funktioniert nach dem ich

PostUp = nft add table ip filter
PostUp = nft add chain ip filter FORWARD '{ type filter hook forward priority 0; policy accept; }'    
PostUp = nft add rule ip filter FORWARD iifname "%i" counter accept    
PostUp = nft add rule ip filter FORWARD oifname "%i" counter accept    
PostDown = nft flush ruleset

hinzugefügt habe.

Vielen Dank nochmal und viele Grüße
aqui
Lösung aqui 27.01.2025 aktualisiert um 11:58:42 Uhr
Goto Top
hinzugefügt habe.
Das ist Unsinn, denn wie oben schon mehrfach gesagt haben Firewall Regelwerke in der VPN Konfig bekanntlich nichts zu suchen.
Es zeigt vielmehr das dein Server schon grundsätzlich eine aktive Firewall hat und die auf Whitelisting geschaltet ist. Sprich also ALLES auf jedem Interface verbietet. Das o.a. Ruleset egalisiert diese Einstellung dann in dem es mit einer recht fahrlässigen "Scheunentorregel" alles erlaubt.

Du hast es schlicht versäumt einmal mit einem nft list ruleset dir deine aktiven nftables Regeln unter /etc/nfttables.conf anzusehen diese DORT wo sie auch hingehören zentral anzupassen und diesen Firewall Unsinn im VPN Client zu löschen. face-sad
Das Gleiche erreichst du mit folgender Standard nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
	chain input {
		type filter hook input priority filter;
	}
	chain forward {
		type filter hook forward priority filter;
	}
	chain output {
		type filter hook output priority filter;
	}
} 
Das ist übrigens der Standard Inhalt der nftables.conf Datei auf dem aktuellen RaspberryOS Bookworm!!
Mal ganz abgesehen davon das in der RaspberryOS Lite Version (die für deinen Server völlig reicht und die Performance schont) die nftables Firewall per Default gar nicht aktiv ist, was dir ein systemctl status nftables auch anzeigen sollte.
Bei einem internen Server im lokalen LAN benötigst du in der Regel auch gar keine Firewall und kannst diese mit systemctl disable nftables abschalten. So benötigst du die unsinnige Regelfrickelei im VPN Client auch nicht. Wie gesagt: Eine deaktivierte Firewall ist in der OS-Lite Version so oder so per Default der Fall!

Aus all dem folgt das du irgendwie an deinen nftables Firewall Einstellungen rumgefrickelt hast wenn du diese Konfig Zeilen wirklich benötigst! face-sad
Testweise hättest du die FW auch mit einem systemctl stop nftables einmal außer Betrieb nehmen können, auch dann hättest du gesehen das die obigen Regeln im VPN Client überflüssig sind.

Aber nundenn...warum einfach machen wenn es umständlich und mit Frickeln auch geht?!

Case closed und damit nicht vergessen deinen Thread dann auch als erledigt zu schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
MichSc33
MichSc33 29.01.2025 um 09:56:14 Uhr
Goto Top
Alles klar, jetzt funktioniert es. Danke dafür!
aqui
aqui 29.01.2025 um 10:33:41 Uhr
Goto Top
Alles klar, jetzt funktioniert es.
Glückwunsch! 👏👍 Immer gerne!
Avenga
Avenga 01.02.2025 um 11:13:55 Uhr
Goto Top
@MichSc33 d.h. wie funktioniert es nun bei dir genau?
ohne die "rule ip filter FORWARD iifname "%i" counter accept und rule ip filter FORWARD oifname "%i" counter accept

oder nur mit ?

ich werde mich auch noch mal dabei setzen und es ohne die Regeln probieren, was laut Aqui funktionieren muss.
151434
151434 01.02.2025 aktualisiert um 12:48:10 Uhr
Goto Top
Zitat von @Avenga:

@MichSc33 d.h. wie funktioniert es nun bei dir genau?
ohne die "rule ip filter FORWARD iifname "%i" counter accept und rule ip filter FORWARD oifname "%i" counter accept

oder nur mit ?

ich werde mich auch noch mal dabei setzen und es ohne die Regeln probieren, was laut Aqui funktionieren muss.

Ganz einfach: Wenn man eine Firewall nutzt bei der in der FORWARD Chain die Default-Policy auf "block" , "drop" oder "reject" steht muss man mit einer Firewall-Regel den transienten Traffic von und zum Wireguard-Interface in der FORWARD Chain zulassen ansonsten wird dieser verständlicherweise geblockt. Ob man diese Regel nun schon vorher direkt in das Firewall-Regelwrtk einträgt oder erst mit einem Befehl in der Wireguard Config ist egal, es kommt em Ende das selbe bei raus.
Bei der Default-Config von nftables stehen alle Policies auf "accept" ergo ist auch keine Forward-Regel nötig. Wobei ich bei Servern die direkt im Internet stehen die Forward Chain immer auf "drop" stellen würde, denn sonst öffnet man Angreifern Tür und Tor zu seinem Netz!

Aber, die Firewall-Tables selbst gänzlich in der Wireguard Config zu erstellen ist ehrlich gesagt Bullshit und Fehleranfällig, Tables und Chains sollten schon vorher existieren. Ich mach ja ne Firewall nicht erst dann an wenn der WG Peer sich einwählt...

Ebenso das getrennte handhaben von IPv4 und IPv6 kann man sich mit nftables sparen indem man stattdessen die inet table nutzt die beides auf einmal abfackelt.
aqui
aqui 01.02.2025 aktualisiert um 13:44:49 Uhr
Goto Top
was laut Aqui funktionieren muss.
Natürlich nur wenn die Firewall entsprechend customized ist! face-wink
Ein nft list ruleset sagt ob dem so ist.

Übliche Klassiker der nftables.conf bei öffentlichen Servern könnte z.B. so aussehen:
#!/usr/sbin/nft -f

flush ruleset

# Interface name
define pub_iface = "eth0"  
# Wireguard port
define wg_port = 51820

table inet drop-bad-ct-states {
	chain prerouting {
		type filter hook prerouting priority -150; policy accept;
		# drop packets in "invalid" connection-tracking state 
		ct state invalid drop
		# drop tcp packets for new connections that aren't syn packets 
		tcp flags & (fin|syn|rst|ack) != syn ct state new counter drop
		# drop XMAS packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == fin|syn|rst|psh|ack|urg counter drop
		# drop NULL packets.
		tcp flags & (fin|syn|rst|psh|ack|urg) == 0x0 counter drop
		# drop new connections over rate limit
		ct state new limit rate over 1/second burst 20 packets drop
		}
}

table inet filter {
	chain input {
		type filter hook input priority 0; policy drop;
		# accept any localhost traffic
		iif lo accept

		# accept any Wireguard traffic
		iifname "wg0" accept  

		# accept traffic originated from us
		ct state established,related accept

		# accepted ICMP types		
		ip protocol icmp icmp type { time-exceeded, parameter-problem, destination-unreachable } accept

		# accept common local TCP services on public interface
		iif $pub_iface tcp dport { ssh, https } ct state new accept

		# accepted UDP ports on public interface 
		iif $pub_iface udp dport { $wg_port } accept 

		# accept neighbour discovery otherwise IPv6 connectivity breaks.
		ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

		# Log and count dropped traffic
		# log prefix "[nftables]Denied: " counter drop 
		# Only count dropped traffic
		counter drop
	}
	chain forward {
		type filter hook forward priority filter; policy drop;
		# accept Wireguard traffic
		ip saddr { 100.64.64.0/24 } ip daddr { 192.168.178.0/24 } accept
	}
	chain output {
		type filter hook output priority filter;
	}
} 
Den Abschnitt der Forwarding Chain könnte man testweise auch in type filter hook forward priority filter; temporär ändern was dann allen Forwarding Traffic erlauben würde. Der "accept" Eintrag Allow Wireguard forwarding kann dann natürlich entfallen oder auskommentiert werden.
Bei einem öffentlichen vServer aber, wie oben schon gesagt, nicht empfehlenswert.
Jedenfals erfordert das dann keine Firewall Frickelei mehr im VPN Server. face-wink
Avenga
Avenga 01.02.2025 um 18:10:19 Uhr
Goto Top
ich hab´s nun endlich noch mal ausprobiert und die "Forwards" gelöscht und es läuft, lediglich NAT6 brauche ich für die Mobilgeräte:
nft list ruleset
table ip filter {
}
table ip6 nat {
        chain POSTROUTING {
                type nat hook postrouting priority srcnat; policy accept;
                ip6 saddr { fd08::2, fd08::3, fd08::4, fd08::5 } oifname "enp1s0" counter packets 68 bytes 7836 masquerade  

k.A. warum das früher nicht ohne Forward lief und warum das alle in ihren Tutorials schreiben, ich habe niemals was an den Iptables oder nftables verändert, also niemals eingestellt:
FORWARD Chain die Default-Policy auf "block" , "drop" oder "reject"

Der einzige Sinn der Forward Regel wäre dann dass man die Pakete / Bytes angezeigt kriegt.

Wenn ich die o.g. Regel direkt in nftables schreibe mit wg0, gibt es dann keine Fehlermeldung wenn wg0 noch nicht exisitiert ?
Das ist der einzige Grund warum man die vielleicht in die wg0.conf schreibt.
151434
151434 01.02.2025 aktualisiert um 18:49:41 Uhr
Goto Top
Der einzige Sinn der Forward Regel wäre dann dass man die Pakete / Bytes angezeigt kriegt
Nur wenn die Chain nicht blockiert ist, dann ja ansonsten nein, aber auch nur wenn man die "counter" Direktive setzt.
Wenn ich die o.g. Regel direkt in nftables schreibe mit wg0, gibt es dann keine Fehlermeldung wenn wg0 noch nicht exisitiert ?
Kommt drauf an von welcher Seite du sprichst. Wenn du den Client meinst dann macht die Regel natürlich auch nur Sinn wenn das Interface auch existiert, also dann macht die Regel in der WG Config Sinn, aber auch nur dann wenn man eingehenden Traffic in das Heimnetz des Clients erwartet, denn nur für Traffic des Clients selbst braucht es keine Forward-Chain Regel weil diese ja gar nicht zum Einsatz kommt da vom Client selbst nur die Output-Chain zum Einsatz kommt. Auf Serverseite ist das Interface ja schon beim Boot da ergo macht dort eine Regel im festen Ruleset am meisten Sinn.

Am besten nochmal die Grundlagen der Chains anlesen dann ist auch klar warum und wieso

clipboard-image
aqui
aqui 01.02.2025 aktualisiert um 18:43:41 Uhr
Goto Top
Das klappt (getestet) fehlerfrei und da kommt auch keine Fehlermeldung. Auch wenn kein Peer aktiv ist hast du, solange der WG Daemon rennt (systemctl status wg-quick@wg0.service), immer ein wg0 Interface. Ein wg show und auch ein ip a zeigt dir das. face-wink