True Site2Site VPN using Wireguard or GoodCloud

Router VPN, DNS, Leaks
1

Hi all,

I'm looking for some advice on how best to configure a true site-to-site VPN between three offices, all using GL.iNet Flint 2 (MT6000) routers.

Current setup

Site A – Main Office

  • Synology NAS running Synology Active Directory Server

  • Multiple Windows PCs joined to the AD domain

  • Vodafone Gigabite connection connected directly to using PPOE GL.iNet Flint 2 (MT6000)

  • The Flint 2 is currently running as the WireGuard server

  • The Synology NAS, AD, file shares, etc. are all located on the Site A LAN

Site B – Remote Office

  • Vodafone Gigabite connection connected directly to using PPOE to second GL.iNet Flint 2 (MT6000)

  • GL.iNet Flint 2 (MT6000)

  • Flint connects to Site A as a WireGuard client

  • PCs are joined to the AD domain at Site A

  • PCs can log on to the domain, receive Group Policy and access file shares on the Synology NAS over WireGuard

Site C – Remote Office

  • Similar setup to Site B

  • GL.iNet Flint 2 (MT6000)

  • Connects back to Site A using WireGuard

  • PCs access the resources/AD services hosted at Site A

The problem

The WireGuard connections work well for accessing Site A from Sites B and C, but they don't appear to operate as a true routed site-to-site VPN.

For example:

Site B → Site A: Works
Site C → Site A: Works

However:

Site A → Site B: Doesn't work
Site A → Site C: Doesn't work
Site B → Site C: Doesn't work
Site C → Site B: Doesn't work

If I need to access something on the LAN at Site B or C from Site A, I currently have to establish a separate VPN connection directly to that site's GL.iNet router.

What I would ideally like is for all three LANs to be properly routed across WireGuard so that devices can communicate between sites as required.

For example:

Site A LAN ↔ Site B LAN
Site A LAN ↔ Site C LAN
Site B LAN ↔ Site C LAN

Each site has its own separate LAN subnet, so there are no overlapping LAN addresses.

What I've tried

I also tried enabling Site-to-Site VPN through GL.iNet GoodCloud, but I couldn't get this working correctly. In particular, I had problems getting connectivity back to Site A and eventually reverted to my existing WireGuard setup.

Question

What is the recommended way of achieving a proper routed site-to-site configuration with three Flint 2 routers?

Can this be achieved using the existing WireGuard server at Site A by adding the appropriate:

  • Allowed IPs

  • Static routes

  • Firewall/forwarding rules

  • Routes between WireGuard peers

Or would I be better off using GL.iNet's GoodCloud Site-to-Site functionality or another solution entirely?

Ideally, I would like Site A to act as the central/hub site, with Sites B and C connected to it, while still allowing traffic to be routed between all three LANs.

Any advice on the correct GL.iNet/WireGuard configuration would be greatly appreciated.

2

I am in the same situation, and the topic interests me.

4

There are two aspects to this. The first is that all the peers have to be on the same subnet. For sanity sake you want to segment that subnet into smaller pieces, like /26.

Second, for the connections that aren’t working, they probably lack a route back. One way to solve this with setups that mimic a client/server architecture is to run a server and a client on each router, so traffic from B as a client goes to A as a server, and from A as a client to B and C servers. Then carefully assign the allowed ips on both sides to match.

I use this in the opposite way: A goes to B and C, and vice versa. B and C are their own pair.

5

Hi,

Thank you for the detailed information.

GoodCloud Site-to-Site should be the simplest way to achieve communication between the LAN subnets at all three sites.

Before setting it up, could you please confirm whether any of the three sites has a public IP address? At least one router needs to be publicly reachable so that it can be used as the Main Node.
If the GL.iNet router is behind another router/NAT device, you may also need to forward the Site-to-Site UDP port (51830 by default) from the upstream router to the GL.iNet router.

You can refer to the following guide for the requirements and setup steps:

We also recommend temporarily disabling the existing WireGuard Client or other VPN services on the Sub Nodes while testing Site-to-Site, as running them at the same time may introduce routing conflicts.

If you would prefer to continue using the existing WireGuard Server:

The remaining configuration is mainly to expose the LANs at Sites B and C and add the corresponding routes on Site A.

For example, assume the network addresses are as follows.

Site A LAN: 192.168.10.0/24
Site B LAN: 192.168.20.0/24
Site C LAN: 192.168.30.0/24

Site A WireGuard IP: 10.0.0.1
Site B WireGuard IP: 10.0.0.2
Site C WireGuard IP: 10.0.0.3
  1. Allow access to the LANs at Sites B and C
    On the WireGuard Client at both Sites B and C, enable Allow Remote Access to the LAN Subnet.
    image
    image1082×583 34.4 KB
  2. On the WireGuard Server at Site A, open Options and enable Client to Client .
    image
    image1045×587 31.6 KB
  3. Then add the following two Route Rules on the WireGuard Server.
Target Address: 192.168.20.0/24
Gateway:        10.0.0.2

Target Address: 192.168.30.0/24
Gateway:        10.0.0.3

image
image850×465 14.2 KB

If Sites B and C use custom or split-tunnel AllowedIPs, Site B must also include the LAN subnets of Sites A and C, while Site C must include the LAN subnets of Sites A and B.
If the profiles currently use AllowedIPs = 0.0.0.0/0 , those remote LAN subnets are already included, so this part normally does not require an additional change.

After applying the rules, restart the WireGuard Server and test access in both directions.
The addresses above are only examples and should be replaced with the customer’s actual LAN subnets and WireGuard tunnel IPs.

6

Hi Charles,

Thanks for getting back and providing a detailed update. I can confirm all o the sites have public IP’s. I will test the above and report back.

Currently the site establishes but does not appear to be reaching each other. Will complete further testing based on your guide.

7

Hi,

Thanks for the update.

If the sites are still unable to reach each other after following the guide, feel free to share the test results with us and we can continue checking from there.

Thanks again for your testing and feedback.