29.04.2022, aktualisiert um 22:44:53 Uhr

3693

Wireguard Site-2-Site (Ping)

Hallo,

ich habe folgendes "Ping"-Problem, aber erstmal zur Infrastruktur:

Seite 1:

Netzwerk 192.168.10.0/24 Wireguard Netzwerk 10.8.0.0/24

Wireguard Server (Proxmox LXC, Ubuntu 22.04 LTS) Netzwerk-IP:192.168.10.64, Wireguard IP: 10.8.0.1)

Routing auf alle Client im Netzwerk Seite 2 (192.168.20.0/24)

Wireguard wg0.conf:

[Interface]
Address = 10.8.0.1/24
#SaveConfig = true
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
ListenPort = 51820


[Peer]
PublicKey = 4Fx/qFCPP907D4TTcRe6EkJAULc3ZR6ypD+MRt3ybB8=
AllowedIPs = 10.8.0.0/24, 192.168.20.0/24
Endpoint = xxx.xxx.xxx.xxx:51820

Seite 2:

Netzwerk 192.168.20.0/24 Wireguard Netzwerk 10.8.0.0/24

Wireguard Server (Raspbery Pi4) Netzwerk-IP:192.168.20.29, WireguardIP: 10.8.0.2)

Routing auf alle Client im Netzwerk Seite 2 (192.168.10.0/24, 192.168.14.0/24, 192.168.14.0/24)

Wireguard wg0.conf:

[Interface]
Address = 10.8.0.2/24
#SaveConfig = true
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
ListenPort = 51820
DNS = 192.168.20.29


[Peer]
PublicKey = EusVmMu4uSdTHrLdoNcCQFkYSrjbgkWKQgB7ScNB8W8=
AllowedIPs = 10.8.0.0/24, 192.168.10.0/24, 192.168.14.0/24, 192.168.16.0/24
PersistentKeepalive = 25
Endpoint = yyy.yyy.yyy.yyy:51820

VPN Site-2-Site Verbindung steht wie eine Eins, kein Problem, aber:

Ich kann von jedem Client auf Seite 2 jeden Client auf Seite 1 pingen. Ich kann von fast jedem Client auf Seite 1 jeden Client auf Seite 2 pingen, außer dem Client auf dem Wireguard läuft, sprich dem LXC Container (192.168.10.64)

Vom LXC Container kann ich jeden Client auf Seite 1 pingen und das Wireguard Interface 10.8.0.1, aber weiter zu 10.8.0.2 oder ins andere Netz geht es nicht mehr.

Jemand Rat?

Gruß und Danke

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

Content-ID: 2643799222

Url: https://administrator.de/forum/wireguard-site-2-site-ping-2643799222.html

Ausgedruckt am: 06.05.2025 um 22:05 Uhr

9 Kommentare

Neuester Kommentar

Deine Subnetzmasken in den Allowed IPs für das interne WG Netz sind falsch. Das müssen /32er Masken sein.
Merkzettel: VPN Installation mit Wireguard
oder auch original Doku lesen hilft:
https://www.wireguard.com/#cryptokey-routing

Hallo,

ich habe die Netzwerkmasken auf /32 umgestellt.Leider löst das mein Problem nicht.

Gruss

Was sagen Traceroute und der Check ggf. vorhandener lokaler Firewalls die ICMP (Ping) filtern?
Bei Win z.B. ist ICMP per Default deaktiviert in der FW. Siehe hier.

außer dem Client auf dem Wireguard läuft, sprich dem LXC Container (192.168.10.64)

Wie sieht dort die Routing Tabelle aus? (Win: route print, Linux: ip r) Gehen die Pings ggf. an falsche Gateways?

aber weiter zu 10.8.0.2 oder ins andere Netz geht es nicht mehr.

Ist das Linux oder Winblows? Und...hast du hier ggf. vergessen IPv4 Forwarding zu aktivieren?
Siehe dazu HIER.

Zitat von @aqui:

Was sagen Traceroute und der Check ggf. vorhandener lokaler Firewalls die ICMP (Ping) filtern?

Traceroute auf die Fritzbox im Netz auf Seite2 sagt:

traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 60 byte packets
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *
* * *

Bei Win z.B. ist ICMP per Default deaktiviert in der FW. Siehe hier.

Es ist ein Linux LXC Container (Ubuntu 22.04)

außer dem Client auf dem Wireguard läuft, sprich dem LXC Container (192.168.10.64)

Wie sieht dort die Routing Tabelle aus? (Win: route print, Linux: ip r) Gehen die Pings ggf. an falsche Gateways?

root@wireguard:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0         192.168.10.1    0.0.0.0         UG        0 0          0 eth0
8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 wg0
168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
168.10.1    0.0.0.0         255.255.255.255 UH        0 0          0 eth0
168.10.29   0.0.0.0         255.255.255.255 UH        0 0          0 eth0
168.10.67   0.0.0.0         255.255.255.255 UH        0 0          0 eth0
168.20.0    0.0.0.0         255.255.255.0   U         0 0          0 wg0

Ist das Linux oder Winblows? Und...hast du hier ggf. vergessen IPv4 Forwarding zu aktivieren?

Linux

Siehe dazu HIER.

Das "verwunderlich" ist halt, dass ich von jedem anderen LXC Container, bzw. von jedem PC, Raspi etc. auf den Wireguard Client oder auf auch die Fritzbox pingen kann. Nur eben nicht vom LXC Container, der als Wireguard Server dient.

Traceroute auf die Fritzbox im Netz auf Seite2 sagt:

besagt schon das das Routing auf der FB nicht funktioniert...

Kann auch daran liegen das das next Hop Gateway einer statischen Route auf der FB schlicht nicht erreichbar ist. Kommt ggf. nicht durch den Containerhost zum Host im Container?!
Könnte man aber durch einen simplen Ping checken mit einem Clien t im FB LAN der den Container Host pingt. Schlägt das auch fehl ist es die Container Connectivity an sich.
Klappt das wider Erwarten doch, dann ist es möglich das der Containerhost ein fehlendes oder falsches Gateway eingetragen hat.
Wieso hat der Wireguard Host 3 unterschiedliche Host IPs ?

Nur eben nicht vom LXC Container, der als Wireguard Server dient.

Genau das wird der Knackpunkt sein! Das Netz selber ist es nicht. Dort am LXC fehlt die Connectivity, sei es ggf. durch fehlendes IPv4 Forwarding, Das Traffic nicht auf die Container durchgereicht wird, fehlende oder falsche Gateways usw.

Hier nochmal die ip r vom Wireguard Server 192.168.10.64:

root@wireguard:/etc/wireguard# ip r
default via 192.168.10.1 dev eth0 proto dhcp src 192.168.10.64 metric 1024 
8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.1 
168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.64 metric 1024 
168.10.1 dev eth0 proto dhcp scope link src 192.168.10.64 metric 1024 
168.10.29 dev eth0 proto dhcp scope link src 192.168.10.64 metric 1024 
168.10.67 dev eth0 proto dhcp scope link src 192.168.10.64 metric 1024 
168.20.0/24 dev wg0 scope link

Die .29 und .67 sind die DNS Server im Netz (pihole+unbound)

Hier die ip r vom Wireguard Client auf Seite 2:

ip r
default via 192.168.20.1 dev eth0 src 192.168.20.29 metric 202 
8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 
8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.2 
254.0.0/16 dev veth1a62cbc scope link src 169.254.164.15 metric 214 
254.0.0/16 dev veth9cc1639 scope link src 169.254.120.126 metric 216 
254.0.0/16 dev vethfc39dc7 scope link src 169.254.164.59 metric 989 
17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
18.0.0/16 dev br-01a7270bce4e proto kernel scope link src 172.18.0.1 linkdown 
19.0.0/16 dev br-fce1bf9a25e6 proto kernel scope link src 172.19.0.1 
20.0.0/16 dev br-0b500e6a4c33 proto kernel scope link src 172.20.0.1 
21.0.0/16 dev br-808018f5bd6f proto kernel scope link src 172.21.0.1 linkdown 
168.10.0/24 dev wg0 scope link 
168.14.0/24 dev wg0 scope link 
168.16.0/24 dev wg0 scope link 
168.20.0/24 dev eth0 proto dhcp scope link src 192.168.20.29 metric 202 

Wenn ich mich mit dem Handy via VPN (direkt auf die FritzBox) verbinde kann ich den Wireguard Client 192.168.20.29 pingen

Hier nochmal die ip r vom Wireguard Server 192.168.10.64:

Ist soweit OK. Was verwirrend sind sind dort die Routing Einträge .10.1, .10.29 und .10.67. Die gehören da eigentlich nicht hin und legen den Verdacht nahe das da IP technisch etwas nicht stimmt.
Das mag aber auch etwas mit deiner Containerisierung zu tun haben.
Wichtig ist das aus dem 10er Netz alle diese 10er IPs pingbar sind und auch die 10.8.0.1.
Ist das der Fall ?

Hier die ip r vom Wireguard Client auf Seite 2:

Mmmhhh... WO kommt da das Tunnel Interface tun0 her?? Hast du da ggf. noch ein OpenVPN laufen was da fälschlicherweise das gleiche IP Netz 10.8.0.0 /24 für das interne VPN Netz nutzt?
Das wäre dann natürlich fatal.

Schande über mein Haupt. Ja das OpenVPN Netz war auch 10.8.0.0/24.
Ich habe das Wireguard Netz jetzt geändert auf 10.6.0.1.
Das hat das Problem aber nicht gelöst.

Ich konnte das Problem aber mittlerweile lösen. Es lag an der config.

Ich hatte unter Allowed-IPs immer das ganze Netz 10.6.0.0/32 angegeben. So kann ich den jeweiligen Client und deine IP des Netztes 192.168.20.0/24 nicht pingen.

[Peer]
PublicKey = 4Fx/qFCPP907D4TTcRe6EkJAULc3ZR6ypD+MRt3ybB8=
AllowedIPs = 10.6.0.0/32, 192.168.20.0/24
Endpoint = xxx.xxx.xxx.xxx:51820

Sobald ich das auf die jeweilige IP des Clients ändere, in dem Fall 10.6.02/32 kann ich den Client 192.168.20.29 und dann auch die Wireguard IP des Clients 10.6.0.2 pingen.

Danke für deine Unterstützung!

Ich hatte unter Allowed-IPs immer das ganze Netz 10.6.0.0/32 angegeben

Das ist aber mit Verlaub ziemlicher Quatsch denn ein /32er Prefix wäre ja eine einzelne Hostaddresse. In Zusammenhang mit einer Netzwerkadresse ist das natürlich subnetztechnischer Blödsinn! (da sind alle Hostbits bekanntlich auf 0)
Wenn überhaupt, wäre die Angabe 10.6.0.0 /24 syntaktisch richtig für eine Netzwerkangabe bei einem Netzwerk mit einer 24er Prefix.
Mit einer /32er Maske gibt man bekanntlich immer nur Endgeräte Hostadressen an! Eine Hostadresse kann aber niemals eine Netzwerkadresse sein, das schliesst sich prinzipbedingt aus.
Aber klasse wenns nun rennt wie es soll.
Du solltest ggf. noch einmal dein rudimentäres Wissen zu Subnetzmasken etwas auffrischen!