Frage zu Wireguard

Hallo an alle,

der Wiregurad Server läuft auf Debian 11.

Konfiguration:
[Interface]
Address = 15.15.0.1/24
ListenPort = 62820
PrivateKey = xx
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = xx
AllowedIPs = 15.15.0.2/32
PersistentKeepalive = 25

Client:
Allowed Ips: 192.168.188.0/24, 0.0.0.0/24

Mit dieser Konfiguration steht die Verbindung auf das entfernte LAN die Internetverbindung des Clienten wird nicht getunnelt.

Mein Ziel ist, das der gesamte Verkehr vom Client über den Tunnel läuft.

Der Eintrag 0.0.0.0 bei den Zulässigen IP des Clienten führt dazu, dass überhaupt keine Internetverbindung mehr zustande kommt.

Wo liegt der Fehler?

Vielen Dank für die Hilfe !

Marcus.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 3158332483

Url: https://administrator.de/forum/frage-zu-wireguard-3158332483.html

Ausgedruckt am: 26.03.2025 um 10:03 Uhr

10 Kommentare

Neuester Kommentar

Moin,
Fehler Nr.1: Du verwendest keine RFC1918-IP für deinen Tunnel. 15.15.0.1 gehört HP Inc. und das bist wahrscheinlich nicht du…
Fehler Nr.2: Wenn du schon 0.0.0.0 angibst, dann bitte auch mit der Netzmaske 0. Also 0.0.0.0/0.
Ausserdem ist der Eintrag für die 192.168.188.0/24 dann überflüssig.

VG

Moin,

ich habe umgestellt auf:

[Interface]
Address = 192.168.195.1/32
ListenPort = 62820
PrivateKey = x
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = x
AllowedIPs = 192.168.195.2/24
PersistentKeepalive = 25

Den Eintrag am Peer habe ich auf 0.0.0.0/0 geändert.

Mit dieser Konfiguration hat der Client Zugriff keine Verbindung zum Internet.

Ich bin am verzweifeln!

IP-Forwarding am Server aktiviert?
https://linuxhint.com/enable_ip_forwarding_ipv4_debian_linux/

Wo liegt der Fehler?

Wie immer im fehlerhaften und überflüssigen NAT im Tunnel bzw. auf den Tunnelinterfaces. Wird immer und immer wieder falsch gemacht.

Allerdings ist das Interface dort immer wg0 und nicht eth0. Fragt sich also warum der TO gerade auf seinem lokalen LAN Interfece (geraten) NAT macht was sogar noch kontraproduktiver ist.

Wireguard Site2Site mit Roadwarrior
VPN Wireguard Seite-zu-Seite-Verbindung mit ein paar iOS-Clients
Alle Details dazu stehen, wie immer, im Wireguard Tutorial.

Zitat von @aqui:
Wie immer im fehlerhaften und überflüssigen NAT im Tunnel bzw. auf den Tunnelinterfaces. Wird immer und immer wieder falsch gemacht.

@marcus552: Denke nur daran, dass du auf deinem Router dann noch die statischen Routen setzen musst.

BTW: Heißt dein Netzwerkinterface auf deinem Debian-Server eigentlich eth0?

Das Interface heißt ens3, ich habe es geändert - gleiches Phänomen.
Das IP-Forwarding ist aktiv, die statische Route ist gesetzt.

Zuletzt habe ich PostUp und PostDown gelöscht.

Der Client kommt mit dem Eintrag 0.0.0.0/0 in das entfernte Netzwerk, aber
nicht ins Internet.

Gibt es eine Firewall, die den Internet-Traffic aus dem fremden Netz blockiert?

Nein, es gibt keine Firewall.

aber nicht ins Internet.

Was ist denn für dich genau "nicht ins Internet"?? Generell ja eine wenig fundierte Aussage wenn man nicht weiss ob direkt die Internet Connectivity gemeint ist oder z.B. nur ein DNS Problem vorliegt.
Um DNS Probleme aus dem Wege zu gehen sollte man einmal einen Ping auf eine nackte IP wie z.B. 8.8.8.8 machen.
Klappt das hat man zumindestens Internet Connectivity.
Wenn ein DNS Auflösungstest mit nslookup oder dig scheitert hast du "nur" ein DNS Problem.
Dreh- und Angelpunkt ist der Wireguard Server UND welchen DNS Server dieser definiert hat.
Bei einem Client Gateway Redirect, wie du es mit der 0.0.0.0/0 betreibst, MUSS auf dem Server sowohl ein Ping auf eine nackte IP klappen also auch eine DNS Auflösung sicher klappen.
Wichtig wäre es dann noch wenn man dem WG Client einen dedizierten DNS Server mitgibt der im Zielnetz erreichbar ist. Z.B. der dortige Internet Router.

[Interface]
Address = 100.64.64.101/24
PrivateKey = OMjSCv6e/iXECZwq0ZVL5Ywf/KzZvdsGpYKv1512345=
DNS = 192.168.178.1

So ist sichergestellt das der WG Client einen DNS Server erreichen kann im WG Servernetz nach dem Redirect.
Da deine Client Absender IP immer eine IP aus dem internen WG VPN Netz ist ist es zwingend erforderlich das auf dem Internet Router im Server Netz eine statische Route ins WG Netz definiert ist wie im Tutorial beschrieben.
Zu all diesen Troubleshooting Tests machst du leider keinerlei hilfreiche Aussagen so das hier wiedermal nur kristallkugeln hilft.