You could have the firewall blocking this if you have configured it to do so. For example to block everything by default unless access is granted. And you could check to ping from one side to the other one to at least reach the firewall.
I tried today with the following routing parameters:
IPFire A:
local subnets: 192.168.1.0/24,192.168.3.0/24
remote subnets: 192.168.0.0/16
IPFire B:
local subnets: 192.168.0.0/16
remote subnets: 192.168.1.0/24,192.168.3.0/24
Like this, I could reach (ping & ssh) from devices on IPFire B (blue) the IPFire A itself, but not any device on IPFire A’s green network (and vice versa).
Do I need to configure a FW rule for incoming connections from red to (orange, green, blue) the local and/or remote VPN port ?
I thought this is automatically done when Wireguard n2n is enabled/configured …
Eh … to be honest I can’t check on IPFire A, because currently I cannot reach it at all due to mistake from my side. Have to go to site A physically tomorrow and fix it first.
the host on the local subnets (orange, green, blue) should accept connections; I did not block anything on the hosts.
and I believe that ping -R xxx.xxx.xxx.xxx should work anyway - or I’m wrong ?
I’ll try these commands tommorrow when I can reach IPFire A again
BTW, I had a working Wireguard Roadwarrier connection from a host behind IPFire B to all hosts behind IPFire A (with ssh, access to my mail server to read emails and to the NAS box) while experimenting with the n2n setup and with ‘ping -R’, I was able to track the route the ping pakets did take…
from the roadwarrier host the the VPN tunnel (client pool ip) to a host behind IPFire A
from the hosts on the n2n VPN tunnel I could only reach the IPFire on the other site.
IPFire A:
local subnets: 192.168.1.0/24,192.168.3.0/24
remote subnets: 192.168.0.0/16
IPFire B:
local subnets: 192.168.0.0/16
remote subnets: 192.168.1.0/24,192.168.3.0/24
and I can ping from IPFire B a host in green subnet of IPFire A
[root@ipfire ~]# ping -R 192.168.3.220
PING 192.168.3.220 (192.168.3.220) 56(124) bytes of data.
64 bytes from 192.168.3.220: icmp_seq=1 ttl=63 time=58.4 ms
RR: 192.168.130.1
192.168.3.1
192.168.3.220
192.168.3.220
192.168.3.1
192.168.130.1
64 bytes from 192.168.3.220: icmp_seq=2 ttl=63 time=57.9 ms (same route)
64 bytes from 192.168.3.220: icmp_seq=3 ttl=63 time=58.9 ms (same route)
^C
— 192.168.3.220 ping statistics —
4 packets transmitted, 3 received, 25% packet loss, time 3005ms
rtt min/avg/max/mdev = 57.856/58.383/58.891/0.422 ms
but it does not work from a host on the green or blue subnet on IPFire B although i connected to IPFire B via ssh from the blue subnet
in my understanding:
IPFire B does not route the traffic from blue subnet into the tunnel to IPFire A (for whatever reason), although the tunnel is existing as the above ping command shows .. but I far away from beeing an expert …
Normally, for net-net VPN’s the local and remote subnets should not overlap. In your case they do as 192.168.0.0/16 covers both 192.168.1.0/24 and 192.168.3.0/24.
As I understood the help, the subnets from the different VPN types (OpenVPN, IPSec and/or Wireguard) shall not overlap only if mutiple types are in use. As I use only WG, this was not an issue for me (I might be wrong)
However, my first configuration was like this (no subnet overlapping):
Unfortunately I had no network access anymore to IPFire A’s site after my last change (even not with the roadwarrier client) and a friend had to drive to site A and reboot the IPFire A.
I don’t know really if this was a coincidence or not but now I don’t dare to change anything on IPFire A as I need access at least via the roadwarrier client to my hosts on site A. (I’m currently abroad)
I’ll continue to troubleshot and change configuration (to no overlapping subnets) back for sure when I’m home again, but for now I will just try to analyze and understand with the information given under this topic, especially also the last post seems quite interesting to me (tips for configuring WireGuard N2N with tree zones), as it is saying that:
e.g: blueA → greenB requires Blue access setup and a FW rule
I guess this is might be the reason for the follwing output:
[root@ipfire ~]# tcpdump -v -i blue0 -n icmp | grep 98
tcpdump: listening on blue0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:55:14.318039 IP (tos 0x0, ttl 64, id 7798, offset 0, flags [none], proto ICMP (1), length 84)
192.168.140.98 > Public IP ISP router(IPFireA): ICMP 192.168.140.98 udp port 40447 unreachable, length 132
Public IP ISP router(IPFireA).51820 > 192.168.140.98.40447: UDP, length 96
