How to Setup a Full Mesh Site-to-Site VPN with Netmaker

“I have three sites: a data center, an office, and an edge location. I want network resources at each site to access network resources at the other sites without having to install a software client on every machine in each location.” – Netmaker User

If you have a similar use case, this guide is for you. While it is sleek to install Netclient or the Remote Access Gateway (RAC) on every machine in your network for seamless end-to-end encrypted traffic, there are cases where that might not be ideal or even possible. Fortunately, Netmaker is fully capable of enabling the interconnection of various network types across different sites via a secure full mesh Virtual Private Network (VPN). This allows encrypted Layer 3 (L3) network communication among different sites.

Guide Overview

In this guide we’re going to create a full mesh site-to-site VPN for a multinational corporation. Our job is to establish a secure and scalable virtual network infrastructure that connects corporate headquarters with regional branches and remote offices to support the distributed nature of its IT system. This infrastructure combines cloud computing with on-premise servers, allowing for both centralized control and localized operations where needed.

Implementation Methods

Netmaker provides flexibility in implementation based on how networks are configured. While uniform deployment across all sites may be ideal, this guide will demonstrate four practical methods of interconnecting sites. For simplicity of this guide, the final result will be a full mesh site-to-site VPN setup across four crucial subsidiary sites of the corporation.

• Site 1 — corporate cloud infrastructure hosted in a Virtual Private Cloud (VPC) network (front-facing servers and backend servers).

• Site 2 — branch behind an OpenWRT router capable of running Netclient (on-premise servers, workstations, network devices).

• Site 3 — remote office behind a NAT router not capable of running Netclient (workstations, on-premise servers).

• Site 4 — another remote office behind a NAT router not capable of running Netclient.

We will begin by interconnecting Site 1 and Site 2 and then expand from there.

Initial Setup

Since we are not installing VPN software on every machine, it is essential to ensure that the sites and the Netmaker network do not have overlapping address ranges. For example, connecting two sites that both use the 192.168.1.0/24 network will not work. Similarly, connecting a site using the 192.168.1.0/24 network to another using the 192.168.0.0/16 network will cause issues. This rule also applies to Virtual LANs (VLANs).

In this guide, we will use the following address spaces:

• Netmaker Network: 100.100.0.0/16

• Site 1 (VPC Network): 10.124.0.0/20

• Site 2 (Behind OpenWRT with Netclient): 172.16.0.0/16

• Site 3 (Behind NAT Router without Netclient): 192.168.123.0/24

• Site 4 (Behind NAT Router without Netclient): 192.168.111.0/24

As you can see, there is no overlap between the network spaces above.

This guide assumes you have access to your Netmaker server. Let's start by creating the Netmaker network that will interconnect all these networks across the sites. We will name it "site-to-site-mesh-vpn". For added functionality, we will create a dual-stack network.

Next, create an enrollment key for the network to allow machines to join. We will call it "mesh-vpn-key".

Now that we have everything set up, we can proceed with interconnecting the first two sites.

Interconnecting Site 1 and Site 2

Site 1 is hosted in a VPC Network without a router. It often contains public-facing web servers and backend servers without public addresses. Because some cloud-hosted servers must initiate connections with other sites, a two-way communication is required.

For Site 1, deploy a virtual machine with Netclient to act as the secure tunnel gateway (tunnel gateway / tunnel router). In Netmaker, the Egress Gateway feature handles encrypted traffic going out from different sites into the VPC network. For outgoing traffic from the VPC to other sites, configure routing either on the initiating devices or via the VPC’s routing capabilities (see “Set Up Routes in Site 1’s VPC Network”).

For Site 2, use the OpenWRT router (capable of running Netclient and with WireGuard in kernel) as the tunnel gateway.

By the end of this section, you should have a VPN setup where hosts in Site 1 and Site 2 can reach one another as if on adjacent LANs.

Steps overview:

1

Install and Setup Netclient

We only need to install Netclient on the VPN tunnel gateway at each site, not on every device in the network.

Notes:

• Netclient uses UDP port 51821 by default — allow inbound/outbound UDP 51821 on cloud firewalls if applicable.

• For Site 1, install Netclient on the public Ubuntu VM that will act as the Egress Gateway.

Procedure:

1. After logging in to Netmaker server, go to the network ("site-to-site-mesh-vpn"), click "Add Nodes", and then "Add New Device".

2. Choose platform and architecture (e.g., Linux AMD64). Copy the installation command and execute it on your machine. After installation, copy and execute the join command on the Ubuntu machine. Click Finish to close the modal.

After a short while the machine should appear in the Netmaker UI under Devices.

For Site 2 (OpenWRT), follow the guide: https://docs.netmaker.io/docs/how-to-guides/how-to-run-netclient-on-openwrt

When configuring the Firewall Zone on OpenWRT, specify “LAN zone” in both “Allow forward to destination zones” and “Allow forward from source zones”.

2

Set the Machines as Egress Gateways

With each site’s gateway joined to "site-to-site-mesh-vpn", configure them as Egress Gateways.

1. Go to the Egress page and click "Add Route".

2. In the modal, give the route a descriptive name. Leave "Enable NAT for egress traffic" enabled initially (you can disable later if you need original source IPs).

3. Select the Egress Gateway machine for Site 1, then click Next.

4. Set an access policy for the egress route: click "Add Resources Policy", enable it, set Source to All Resources, then Finish.

You should see the newly created route in the Egress table and the access policy under Access Control.

You can expose whole networks (e.g., 10.124.0.0/20) or specific ranges and individual IPs (e.g., 10.124.0.1/32, 10.124.0.2/32, 10.124.0.5/32) by creating multiple egress routes.

3

Verify Two-Way Connectivity and Configure Site 2 Egress

At this point:

• Site 2’s machines should be able to reach Site 1’s exposed addresses.

• Site 1’s machines may not be able to reach Site 2 yet because Site 1’s hosts are not using the Site 1 Egress Gateway as their default gateway.

To enable Site 1 → Site 2 traffic:

1. Configure the OpenWRT router (Site 2) as an Egress Gateway in Netmaker and expose Site 2’s network (or subset).

After configuring Site 2 as an Egress Gateway:

• Site 1’s Egress Gateway machine will be able to reach devices in Site 2.

• Other machines in Site 1 still need routes pointing to the Site 1 tunnel gateway in order to reach Site 2 (see next step).

Set Up Routes in Site 1’s VPC Network

Static routes in the VPC must point to the local IP address of the machine functioning as the tunnel gateway. Typical routes to add:

• Routes to each remote site (e.g., Site 2’s 172.16.0.0/16).

• Route to the Netmaker VPN network (optional, 100.100.0.0/16).

• Routes to any other egress external client address ranges (optional).

Where to add the routes depends on your cloud provider:

• VPC-level global routing table (preferred where supported).

• Or add to each VM’s routing table (tedious but viable).

For this demonstration we add a static route on the Site 1 File Server (Ubuntu) using netplan.

Edit the netplan YAML file (typically /etc/netplan/<your-machine-default-config>.yml) and add a routes: entry under the appropriate interface (e.g., eth1), routing 172.16.0.0/16 via the Site 1 Egress Gateway IP (e.g., 10.124.0.6).

Note: Some providers (e.g., Google Cloud) may override VM netplan changes — consult your provider for persistent static route methods.

For Site 2 there’s no need to add static routes to each device because the OpenWRT router is the default gateway for the local network.

Once static routes are in place on Site 1 hosts (or at VPC-level), devices from Site 1 should reach devices from Site 2 and vice versa.

Disabling NAT for Egress Traffic

By default we enabled NAT (Masquerade NAT) for egress traffic. NAT causes the Egress Gateway’s IP to be used as the source IP when traffic reaches its destination, which simplifies connectivity but hides original client IPs.

If you require original source IPs (for IP-based allowlisting or security controls), disable NAT for egress traffic on both Site 1 and Site 2 Egress Gateways.

Trade-offs:

• With NAT disabled, only hosts that have proper routes pointing to the tunnel gateway (or when you configure routes globally at the VPC level) will be reachable from the other site.

• If you do not configure global routes, only the hosts that have static routes will be reachable.

Site-to-Site IPv4 Over IPv6 Tunnel

Netmaker v0.99.0+ supports IPv4-over-IPv6 tunnels (encapsulating IPv4 in IPv6). If you use IPv4-over-IPv6, OpenWRT requires an additional firewall/NAT rule to disable address rewrite:

• Go to Firewall → NAT Rules and add a rule set to ACCEPT - Disable address rewrite.

• Save and Apply changes.

This ensures seamless two-way communication for IPv4-over-IPv6 scenarios.

More to come

Stay tuned for additional methods that interconnect Sites 3 and 4.