Thanks for asking me the right questions - the problem is always sitting in front of the screen 
Additonal info: my_PC (windows) is connected to Router_A lan, it's IP is 192.168.21.81
- Router_B ping Router_A on router IP:
root@Router_B:~# ping 192.168.21.1
PING 192.168.21.1 (192.168.21.1): 56 data bytes
64 bytes from 192.168.21.1: seq=0 ttl=64 time=24.855 ms
64 bytes from 192.168.21.1: seq=1 ttl=64 time=29.803 ms
64 bytes from 192.168.21.1: seq=2 ttl=64 time=29.821 ms
64 bytes from 192.168.21.1: seq=3 ttl=64 time=37.651 ms
64 bytes from 192.168.21.1: seq=4 ttl=64 time=37.668 ms
64 bytes from 192.168.21.1: seq=5 ttl=64 time=29.867 ms
64 bytes from 192.168.21.1: seq=6 ttl=64 time=29.876 ms
^C
--- 192.168.21.1 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 24.855/31.363/37.668 ms
tcpdump running on Router_A at the same time:
root@Router_A:~# tcpdump -i wg0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
23:17:17.360622 IP 192.168.1.5 > Router_A.lan: ICMP echo request, id 7416, seq 0, length 64
23:17:17.360673 IP Router_A.lan > 192.168.1.5: ICMP echo reply, id 7416, seq 0, length 64
23:17:18.365638 IP 192.168.1.5 > Router_A.lan: ICMP echo request, id 7416, seq 1, length 64
23:17:18.365694 IP Router_A.lan > 192.168.1.5: ICMP echo reply, id 7416, seq 1, length 64
23:17:19.365716 IP 192.168.1.5 > Router_A.lan: ICMP echo request, id 7416, seq 2, length 64
23:17:19.365752 IP Router_A.lan > 192.168.1.5: ICMP echo reply, id 7416, seq 2, length 64
23:17:20.373643 IP 192.168.1.5 > Router_A.lan: ICMP echo request, id 7416, seq 3, length 64
23:17:20.373703 IP Router_A.lan > 192.168.1.5: ICMP echo reply, id 7416, seq 3, length 64
23:17:21.373607 IP 192.168.1.5 > Router_A.lan: ICMP echo request, id 7416, seq 4, length 64
23:17:21.373656 IP Router_A.lan > 192.168.1.5: ICMP echo reply, id 7416, seq 4, length 64
23:17:22.365642 IP 192.168.1.5 > Router_A.lan: ICMP echo request, id 7416, seq 5, length 64
23:17:22.365692 IP Router_A.lan > 192.168.1.5: ICMP echo reply, id 7416, seq 5, length 64
23:17:23.365591 IP 192.168.1.5 > Router_A.lan: ICMP echo request, id 7416, seq 6, length 64
23:17:23.365634 IP Router_A.lan > 192.168.1.5: ICMP echo reply, id 7416, seq 6, length 64
14 packets captured
14 packets received by filter
0 packets dropped by kernel
So I can access Router_A from Router_B via its lan IP. --> works. The interface it self should then just work fine for the above mentioned PC, so let's see.
(Pinging Router_B from Router_A works just as well, I leave this part out, as it is somewhat identical)
- Ping Router_B from my_PC
C:\Users\user>ping 192.168.22.1
Ping wird ausgeführt für 192.168.22.1 mit 32 Bytes Daten:
Antwort von 192.168.31.1: Zielport nicht erreichbar.
Antwort von 192.168.31.1: Zielport nicht erreichbar.
Antwort von 192.168.31.1: Zielport nicht erreichbar.
Antwort von 192.168.31.1: Zielport nicht erreichbar.
Ping-Statistik für 192.168.22.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
tcpdump running on Router_A at the same time:
root@Router_A:~# tcpdump -i wg0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
This way I found out that the DHCP-server that was asked for the route to 192.168.22.1 was not as expected 192.168.21.1, but 192.168.31.1. I have additional interfaces setup parallel to lan and my PC is connected via SFP+ to a switch with 3 VLAN-IDs activated (one for lan-network 192.168.21.0/24, one for home network 192.168.31.0/24 and one for iot network 192.168.41.0/24). The problem now is, that 192.168.31.1 seems to be the default interface - when setting the metric for the interfaces to automatic metric.
Now when setting the lowest metric to the connection, that is for lan VID and retry I get:
- Ping Router_B from my_PC with adjusted metric
tcpdump on Router_A
root@Router_A:~# tcpdump -i wg0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
23:46:31.523511 IP 192.168.21.81 > 192.168.22.1: ICMP echo request, id 1, seq 30, length 40
23:46:31.544675 IP 192.168.22.1 > 192.168.21.81: ICMP echo reply, id 1, seq 30, length 40
23:46:32.539694 IP 192.168.21.81 > 192.168.22.1: ICMP echo request, id 1, seq 31, length 40
23:46:32.560591 IP 192.168.22.1 > 192.168.21.81: ICMP echo reply, id 1, seq 31, length 40
23:46:33.546860 IP 192.168.21.81 > 192.168.22.1: ICMP echo request, id 1, seq 32, length 40
23:46:33.572644 IP 192.168.22.1 > 192.168.21.81: ICMP echo reply, id 1, seq 32, length 40
23:46:34.562758 IP 192.168.21.81 > 192.168.22.1: ICMP echo request, id 1, seq 33, length 40
23:46:34.593300 IP 192.168.22.1 > 192.168.21.81: ICMP echo reply, id 1, seq 33, length 40
^C
8 packets captured
8 packets received by filter
0 packets dropped by kernel
ping on my_PC
C:\Users\user>ping 192.168.22.1
Ping wird ausgeführt für 192.168.22.1 mit 32 Bytes Daten:
Antwort von 192.168.22.1: Bytes=32 Zeit=21ms TTL=63
Antwort von 192.168.22.1: Bytes=32 Zeit=21ms TTL=63
Antwort von 192.168.22.1: Bytes=32 Zeit=26ms TTL=63
Antwort von 192.168.22.1: Bytes=32 Zeit=30ms TTL=63
Ping-Statistik für 192.168.22.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 21ms, Maximum = 30ms, Mittelwert = 24ms
So no additional firewall rules needed and problem solved 