Question Regarding the Allowed IPs Setting of Wireguard Site-to-Multisite VPN
-
According to the Netgate Doc or WG Site-to-Multisite VPN, in the peer configuration, the AllowedIPs of each remote office contains the LAN of other remote office as well as the entire WG tunnel network However, for the HQ, the AllowedIPs settings only contain the WG tunnel interface of each remote office.
My question is, since all traffics are routed via the HQ why does each remote office needs the entire tunnel network (plus LAN of other remote office) in the AllowedIPs instead just the tunnel interface of the HQ (plus the LAN of other remote office)?
-
@algo7 And why does HQ have no LAN.
-
@Bob-Dig in the doc HQ doesn't have any LAN (https://docs.netgate.com/pfsense/en/latest/recipes/wireguard-s2ms.html#peer-configuration). Seems like HQ is only being used to route traffic but not to be accessed remotely. Assuming if there are tons of other remote sites instead of just 2 in the doc example it will make sense to use HQ as a "router".
However, even if HQ's LAN is also to be accessed by the remote offices, things that will change are
- In each remote office's AllowedIPs settings, add HQ's LAN
- Modify the static route of each remote office to also route the HQ's LAN to via the WG Gateway which is HQ's WG tunnel interface
It still doesn't explain why we need the entire tunnel network in the AllowedIPs settings of each remote office.
-
@algo7 said in Question Regarding the Allowed IPs Setting of Wireguard Site-to-Multisite VPN:
it still doesn't explain why we need the entire tunnel network in the AllowedIPs settings of each remote office.
Let's say, you want to ping the WireGuard IP of the other remote office for reasons, you have to have it in there. So I can see that being useful, even if it will be used rarely.
-
I found other configuration examples on GitHub: https://github.com/a4649/wireguard-multi-site
In this example, site A is the "hub". In each "spoke" site, the AllowedIPs contains the remote LAN of all other sites and the tunnel interface of the hub instead of the entire tunnel network. So it seems to me that it is not a "requirement" to have the entire tunnel network specified in the AllowedIPs in all the "spoke" sites.
The use case you mentioned is indeed very rare, but I couldn't really think of other reasons why the entire tunnel network is specified in each remote office's AllowedIPs setting.
