How to solve routing in wireguard site-to-site network

Question

I have set up a site-to-site network with wireguard:

wg-server <-network A-> router A <--internet--> router B <-network B-> wg-client AND host B1, B2 etc

wg-server is running some network services like http, ssh etc.

The goal is to access services at wg-server from host B1.

The wireguard connection between wg-client and wg-server works: I can access the hosts from each other. Also I can reach router A from wg-client, but not from host B1.

root@wg-client:~# traceroute 192.168.179.1
traceroute to 192.168.179.1 (192.168.179.1), 30 hops max, 60 byte packets
 1  10.8.0.1 (10.8.0.1)  22.939 ms  31.863 ms  32.336 ms
 2  192.168.179.1 (192.168.179.1)  32.235 ms  35.028 ms  34.811 ms

root@wg-client:~# ping -c1 192.168.179.51
PING 192.168.179.51 (192.168.179.51) 56(84) bytes of data.
64 bytes from 192.168.179.51: icmp_seq=1 ttl=64 time=22.3 ms

[host B1]C:\>tracert 192.168.179.1
Routenverfolgung zu 192.168.179.1 über maximal 30 Hops
  1     4 ms     2 ms     2 ms  fritz.box [192.168.76.1]
  2     5 ms     5 ms     4 ms  wg-client [192.168.76.30]
  3     *        *        *     Zeitüberschreitung der Anforderung.

[host B1]C:\>tracert 192.168.179.51
Routenverfolgung zu 192.168.179.51 über maximal 30 Hops
  1    91 ms     2 ms     2 ms  fritz.box [192.168.76.1]
  2     3 ms     4 ms     3 ms  wg-client [192.168.76.30]
  3     *        *        *     Zeitüberschreitung der Anforderung.

[host B1]C:\>ping 192.168.179.51
Ping wird ausgeführt für 192.168.179.51 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.

I also cannot reach router B or host B1 from wg-server.

==> Do you have some hints for analyzing and solving the problem?

Network setup is:

network A = 192.168.179.0/24
network B = 192.168.76.0/24

wg-server:
linux armbian
192.168.179.51 eth0
10.8.0.1 wg0

wg-client:
linux raspbian
192.168.76.30 eth0
10.8.0.3 wg1

router A (fritzbox):
dynamic public ip
internal ip 192.168.179.1
routing 192.168.76.0/24 to 192.168.179.51

router B (fritzbox):
dynamic public ip
internal ip 192.168.76.1
routing 192.168.179.0/24 to 192.168.76.30

host B1:
Windows 11
192.168.76.44

Routing table at wg-client:

root@wg-client:~# ip route
default via 192.168.76.1 dev eth0 src 192.168.76.30 metric 202
10.8.0.0/24 dev wg1 proto kernel scope link src 10.8.0.3
[...]
192.168.76.0/24 dev eth0 proto dhcp scope link src 192.168.76.30 metric 202
192.168.179.0/24 dev wg1 scope link

Routing table at wg-server:

root@wg-server:~# ip route

default via 192.168.179.1 dev eth0 proto dhcp metric 100
10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.1
169.254.0.0/16 dev wg0 scope link metric 1000
[...]
192.168.76.0/24 dev wg0 scope link
192.168.179.0/24 dev eth0 proto kernel scope link src 192.168.179.51 metric 100

[...] are not shown routes to internal docker networks.

Firewall / iptables at wg-client is disabled. Ip forwarding is activated:

root@wg-client:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

wg config at wg-client:

[Interface]
PrivateKey = secret
Address = 10.8.0.3/24
[Peer]
PublicKey = secret
PresharedKey = secret
AllowedIPs = 10.8.0.0/24, 192.168.179.0/24, fd58:8e5e:1d78::0/64
Endpoint = secret.ddnss.de:51820
PersistentKeepalive = 25

wg config at wg-server:

[Interface]
Address = 10.8.0.1/24
Address = fd58:8e5e:1d78::1/64
PostUp = ufw route allow in on wg0 out on eth0
PostUp = iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PostUp = ip6tables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
PreDown = ufw route delete allow in on wg0 out on eth0
PreDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PreDown = ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
ListenPort = 51820
PrivateKey = secret

[Peer]
PublicKey = secret
PresharedKey = secret
AllowedIPs = 10.8.0.0/24, 192.168.76.0/24, fd58:8e5e:1d78::0/64

Edit 1:

[host B1]C:\>tracert 192.168.179.1

root@wg-client:~# tcpdump -n -i wg1 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg1, link-type RAW (Raw IP), snapshot length 262144 bytes

==> no result on wg1

root@wg-client:~# tcpdump -n -i eth0 icmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:45:47.312930 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 239, length 72
15:45:47.313068 IP 192.168.76.30 > 192.168.76.44: ICMP time exceeded in-transit, length 100
15:45:47.319822 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 240, length 72
15:45:47.319906 IP 192.168.76.30 > 192.168.76.44: ICMP time exceeded in-transit, length 100
15:45:47.327341 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 241, length 72
15:45:47.327396 IP 192.168.76.30 > 192.168.76.44: ICMP time exceeded in-transit, length 100
15:45:48.354899 IP 192.168.76.44 > 192.168.179.1: ICMP echo request, id 1, seq 242, length 72

==> icmp packages visible on eth0

==> seems to be no routing between eth0 and wg1

Solved:

I solved my problem by activating nftables on wg-client. Now traffic is routed within wg-client and from network B to netwok A over wireguard.

Actually this wasn´t the final solution. The problem was that docker initiates iptables policy that drops every packet in the forward chain documented in https://docs.docker.com/network/iptables/#docker-on-a-router. So at wg-client I had to set the two rules and persist them:

iptables -I DOCKER-USER -i wg1 -o eth0 -j ACCEPT
iptables -I DOCKER-USER -i eth0 -o wg1 -j ACCEPT

Answer 1

The 192.168.76.44 host and alike need to have route on themselves that route traffics for 10.8.0.0/24 (well or just 10.8.0.1 in your case) via 192.168.76.30. Without such route they will route the traffics via their default gateway (i.e. 192.168.76.1 / router B), which will forward the traffics over to its WAN (its firewall might drop them because the IP belongs to a private block as well).

Alternatives of adding the required route on each the LAN hosts (that wants the connectivity to the WG network / server) are adding the route on router B instead, or set up SNAT (IP masquerade) on the WG client for traffics with source IP within 10.8.0.0/24 / being 10.8.0.1 (that destined at 192.168.76.0/24), which makes the traffics look originated from the client itself (i.e. with the source IP "changed" / "translated" to 192.168.76.30). The "workarounds" might have pitfalls under certain circumstances though.