[Gelöst] Wireguard Netzwerk mit FB als Client

[eeausli]

Nach dem Vorschlag hier hab ich die Konfiguration meines Wireguard Servers (VPS bei netcup) mal angepasst, aber ich hab da noch ein paar Probleme.
Meine Server Konfiguration sieht jetzt folgendermaßen aus:

# ---------- Server Config ----------
[Interface]
Address = 10.255.255.1/24 # IPV4 CIDR
Address = fd10:2552:2550:0815::0aff:ff01/64 # IPV6 CIDR fd10:2552:2540:0815::/64
PrivateKey = ZZZZZZZZZZZZZZZZZ
ListenPort = 51821

#Android mobile
[Peer]
PublicKey = AAAAAAAAAAAAA
AllowedIPs = 10.255.255.2/32, fd10:2552:2550:0815::0aff:ff02/128

#Work
[Peer]
PublicKey = BBBBBBBBBBBBB
AllowedIPs = 10.255.255.3/32, fd10:2552:2550:0815::0aff:ff03/128

#L Edgerouter X
[Peer]
PublicKey = CCCCCCCCCCCCC # L public key
AllowedIPs = 10.255.255.4/32, 10.8.15.0/24, fd10:2552:2550:0815::0aff:ff04/128

#R FB 7490
[Peer]
PublicKey = DDDDDDDDDDDDD
#Allowed IPs = 10.255.255.5/32, 192.168.0.0/24, fd10:2552:2550:0815::0aff:ff05/128
Allowed IPs = 192.168.0.0/24, fd10:2552:2550:0815::0aff:ff05/128

#B FB 7590
[Peer]
PublicKey = EEEEEEEEEEEEE # B public key
#Allowed IPs = 10.255.255.6/32, 192.168.188.0/24, fd10:2552:2550:0815::0aff:ff06/128
Allowed IPs = 192.168.188.0/24, fd10:2552:2550:0815::0aff:ff06/128

Beispielhaft mal die Client Konfiguration von R, also einer 7490 mit aktueller Labor Firmware:

# ---------- Client Config ----------
[Interface]
Address = 10.255.255.5/24
PrivateKey = PRIVKEY

[Peer]
PublicKey = PUBKEY
Endpoint = öffentliche.ip.v.4:51821
AllowedIPs = 10.255.255.0/24, 10.8.15.0/24, 192.168.188.0/24
PersistentKeepalive = 25

Und die Client Konfiguration von meinem Edgerouter X:

wireguard wg0 {
        address 10.255.255.4/24
        mtu 1420
        peer YYYYYYYYYYYY {
            allowed-ips 10.255.255.0/24
            allowed-ips 192.168.0.0/24
            allowed-ips 192.168.188.0/24
            endpoint öffentliche.ip.v.4:51821
            persistent-keepalive 25
        }
        private-key ABABABABABABABAB
        route-allowed-ips true
    }

Das Problem ist jetzt folgendes:
Ping direkt vom Edgerouter auf die 7490 oder eines anderen Gerätes im zugehörigen Netz funktioniert
Ping von einem mobilen Device (Android) im VPN auf die 7490 oder eines anderen Gerätes im zugehörigen Netz funktioniert
Ping von einem mobilen Device (Android) im VPN auf den Edgerouter oder eines anderen Gerätes im zugehörigen Netz funktioniert
Ping von einem Client hinter dem Edgerouter auf die 7490 oder eines anderen Gerätes im zugehörigen Netz funktioniert nicht
Ping von einem Client hinter der 7490 auf den Edgerouter oder eines anderen Gerätes im zugehörigen Netz funktioniert nicht

Am Edgerouter scheints nicht zu liegen, Firewall Regeln habe ich zwischendurch alle deaktiviert. Ein traceroute zur 7490 von einem Client hinter dem Edgerouter zeigt als letzten erreichbaren hop die Wireguard IP des Servers an.

Es scheint also irgendwo bei der Fritzbox kein routing in die durch AllowedIPs definierten Netze zu funktionieren?

Vielleicht hat hier ja jemand eine Idee, wie ich das in den Griff bekomme.

 

[frank_m24]

Ich würde auf Client Seite die lokalen Adressen mit /32 eintragen, nicht mit /24.

Ein traceroute zur 7490 von einem Client hinter dem Edgerouter zeigt als letzten erreichbaren hop die Wireguard IP des Servers an.

Dann prüfe auf dem Server doch mal, ob alle Routen passend angelegt wurden, vor allem für die lokalen Netze der Fritzboxen/Edgerouter. IP-Forwarding ist an auf dem Server? Irgendwelche NAT Regeln gibt es da ja hoffentlich nicht, oder?

 

[eeausli]

Ob ich auf Client Seite als Interface Adresse /24 oder /32 verwende ist ja eigentlich relativ egal. Hab es auf dem Edgerouter mal versucht, hatte aber wie zu erwarten war keinen Effekt.
Für die Fritzbox kann ich eintragen was ich will, die Fritzbox ignoriert das ja eh gekonnt und verwendet als Wireguard Interface Adresse die Adresse von eth0

user@vpnserver:~$ cat /proc/sys/net/ipv4/ip_forward
1

Also ja, ip forwarding ist aktiviert

user@vpnserver:~$ ip route list
default via gateway.ip.des.servers dev eth0 proto static
10.8.15.0/24 dev wg1 scope link
10.255.254.0/24 dev wg0 proto kernel scope link src 10.255.254.1 <- anderes wireguard interface auf anderem port
10.255.255.0/24 dev wg1 proto kernel scope link src 10.255.255.1
öffentliches.subnet.des.servers/22 dev eth0 proto kernel scope link src öffentliche.ip.v.4
192.168.0.0/24 dev wg1 scope link
192.168.188.0/24 dev wg1 scope link

Und ja, die routen existieren auf dem server auch.

traceroute auf meinem edgerouter zu einem client hinter der 7490

user@erx:~$ traceroute 192.168.0.99
traceroute to 192.168.0.99 (192.168.0.99), 30 hops max, 38 byte packets
 1  10.255.255.1 (10.255.255.1)  18.775 ms  18.438 ms  19.474 ms
 2  *  *  *
 3  192.168.0.99 (192.168.0.99)  39.301 ms  40.446 ms  39.159 ms

aber traceroute auf einem client hinter dem edgerouter zu demselben client hinter der 7490

C:\Program Files\PuTTY>tracert -d 192.168.0.99

Routenverfolgung zu 192.168.0.99 über maximal 30 Hops

  1     1 ms     1 ms    <1 ms  10.8.15.1
  2    20 ms    20 ms    21 ms  10.255.255.1
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.

NAT regeln gibt es hier nicht

Zur vollständigkeit mal die routingtabelle meines Edgerouters

user@erx:~$ show ip route
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
       O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       > - selected route, * - FIB route, p - stale info

IP Route Table for VRF "default"
S    *> 0.0.0.0/0 [210/0] via 100.112.0.1, eth0
C    *> 0.0.0.0/32 is directly connected, wg0
C    *> 10.8.15.0/24 is directly connected, switch0
K    *> 10.255.255.0/24 [0/0] via wg0
K    *> 10.255.255.1/32 [0/0] via wg0
C    *> 10.255.255.4/32 is directly connected, wg0
C    *> 100.112.0.0/16 is directly connected, eth0
C    *> 127.0.0.0/8 is directly connected, lo
K    *> 192.168.0.0/24 [0/0] via wg0
C    *> 192.168.170.0/24 is directly connected, switch0.40
C    *> 192.168.171.0/29 is directly connected, switch0.50
C    *> 192.168.179.0/24 is directly connected, switch0.20
C    *> 192.168.180.0/24 is directly connected, switch0.30
K    *> 192.168.188.0/24 [0/0] via wg0

Oh, gerade bekommen vom Inhaber der 7490

C:\Users\Admin>tracert 10.8.15.45

Routenverfolgung zu 10.8.15.45 über maximal 30 Hops

  1  1142 ms     2 ms   136 ms  fritz.box [192.168.0.1]
  2    15 ms    59 ms    14 ms  loopback1.000.acln,01.dus.de.net.telefonica.de [62.52.201.189]
  3     *        *        *     Zeitüberschreitung der Anforderung.
  4     *        *        *     Zeitüberschreitung der Anforderung.

C:\Users\Admin>tracert 10.255.255.4

Routenverfolgung zu 10.255.255.4 über maximal 30 Hops

  1   179 ms     5 ms     6 ms  fritz.box [192.168.0.1]
  2    37 ms    67 ms   101 ms  10.255.255.1
  3   307 ms   323 ms   281 ms  10.255.255.4

Tante Edit sagt:

Die Fritzbox interessiert zwar eigentlich die vorgegebene Interface Adresse nicht, aber erwartet scheinbar dennoch dass man gefälligst die Adresse von eth0 dort einträgt.
In dem Fall muss also aus

[Interface]
Address = 10.255.255.5/24

[Interface]
Address = 192.168.0.1/24

werden, dann funktioniert alles wie gewünscht