Documentation

Site-to-site VPN: the mesh way, without IPsec

The site-to-site VPN is the great classic of enterprise networking: IPsec tunnels between routers that connect the branch office, the workshop or the remote site to the main network. The model works, but it is aging badly — per-router configuration, fixed IP addresses, all traffic transiting through headquarters. The mesh approach turns the picture around: every machine becomes a peer of the network, paths run directly from site to site, and no concentrator is needed. This page compares the two models honestly and shows how to build the site-to-site equivalent with VIGIL-MESH.

What a classic site-to-site VPN is for

A site-to-site VPN connects entire networks to each other rather than individual users: the branch network is attached to the headquarters network, and machines on both sides reach each other as if they shared the same infrastructure. It is what lets the workshop reach the central ERP, the branch print on the headquarters server, or the remote site push its production data upstream.

The traditional implementation relies on IPsec: an encrypted tunnel established between two routers or firewalls, one at each end. Every pair of sites to connect requires its own tunnel, with configuration on both sides — traffic selectors, address ranges, shared keys or certificates. In practice, most companies do not interconnect every site with every other: they build a star, where each site opens a tunnel to headquarters, which acts as the turntable for all inter-site traffic.

Where classic site-to-site hurts

Anyone who has operated a fleet of IPsec tunnels will recognize these pains. They are not tied to any particular vendor: they follow from the model itself.

One configuration per router

Every tunnel is configured on both sides, on devices that are often heterogeneous. Adding a site, changing an address range or rotating keys is done device by device, with all the mismatch errors that implies.

Fixed IP addresses required

Tunnel endpoints have to find each other: you need stable public addresses, or workarounds for sites on dynamic addresses, on 4G, or behind a carrier's NAT.

Everything transits through headquarters

In a star, traffic between two branches climbs up to headquarters before coming back down: a longer path, doubled latency, and a central link that must be sized for the sum of all flows.

The concentrator, single point of failure

If the headquarters concentrator goes down — hardware failure, botched update, link outage — every site loses interconnection at once, even when each site is working perfectly on its own.

The mesh approach: peers, not tunnels

A mesh VPN starts from a different premise: instead of linking routers with tunnels, every machine becomes a peer of the network. Peers authenticate against a control plane, then establish direct, encrypted connections with one another — machine to machine, site to site, with no mandatory transit point. The topology is no longer drawn by hand in router configurations: it follows from network membership.

Direct point-to-point paths: traffic between two sites goes from one to the other along the shortest path, without a detour through headquarters or a concentrator.
No concentrator to size or to back up: no central device carries inter-site traffic, so none can bring it down.
No fixed address required: connections are established outward, which works behind NAT, on 4G/5G or on dynamic addresses, without opening any inbound port.
Autonomous islands: if a site's Internet access goes down, the machines on that site keep talking to each other locally; the network does not collapse with the link.

Site-to-site IPsec and mesh, face to face

An honest comparison is not about declaring mesh the winner everywhere: the two models do not place the unit of management in the same spot. IPsec thinks in networks linked by routers; mesh thinks in machines that are members of a logical network.

	Site-to-site IPsec	Mesh VPN
Basic unit	The tunnel between two routers	The machine, a peer of the network
Topology	Star around headquarters, or a mesh of hand-configured tunnels	Direct mesh, derived from network membership
Inter-site path	Transits through the central concentrator	Direct from site to site, the shortest
Network prerequisites	Stable public addresses, IPsec ports open	No inbound ports, works behind NAT and dynamic addresses
Adding a site	New tunnel to configure on both sides	Enroll the site's machines into the network
Central point failure	Interconnection lost for every site	No central point; each site remains an autonomous island
Machines without an agent	Covered by default: the router carries the whole subnet	Via a gateway node, host by host, explicit selection
Encryption	IPsec, per the suites configured on each device	End-to-end QUIC/TLS 1.3, hybrid post-quantum key exchange

Building “site-to-site” with VIGIL-MESH

With VIGIL-MESH, the site-to-site equivalent involves neither tunnels nor routers: it is built from the product's building blocks — networks, stable addresses, MagicDNS and access policy. Clients exist for Windows, Linux, Android, Jetson and the browser (WASM).

1
Create a network for the machines that need to see each otherA VIGIL-MESH network is a broadcast domain: group in it the machines from the various sites that actually need to communicate, whether they sit at headquarters, at the branch or in the workshop.
2
Enroll the machines of each siteEach installed machine joins the mesh outward, with no inbound port to open and no public address to reserve on the sites' boxes or routers. It receives a stable address that follows it everywhere.
3
Cover agent-less devices through a gatewayFor the printer, the PLC or the legacy server that cannot run the agent, a node on the same LAN acts as a gateway and publishes the explicitly selected hosts — not the entire subnet.
4
Write the access policy (ACL)Describe who reaches what across sites: the workshop reaches the ERP, the branch reaches the file server, and nothing else. The policy is defined once in the console and distributed to the members.
5
Name services with MagicDNSMachines are reached by a short name resolved locally, rather than through addressing plans to be reconciled between sites. Stable addresses do the rest.

Frequently asked questions

Can you connect two entire networks rather than individual machines?

The VIGIL-MESH approach is deliberately explicit: machines enroll one by one, and agent-less devices are published through a gateway node, host by host, upon explicit selection. An entire subnet is never published implicitly the way an IPsec router would: it is a control choice — every reachable device is reachable because someone decided it.

What happens if the Internet goes down on a site?

The site becomes an autonomous island: local machines keep reaching each other, because there is no central concentrator on which local traffic would depend. When the link comes back, paths to the other sites are re-established.

Do I need fixed IP addresses or open ports on each site?

No. Nodes always establish their connections outward: no inbound port to open, no fixed public address to reserve. A site on 4G, behind a carrier NAT or on a dynamic address takes part in the mesh like any other.

Does inter-site traffic go through a central server?

No, not in steady state. When a direct path is not yet available, traffic temporarily transits through a blind relay — which does not hold the keys and can be self-hosted — then the session migrates to the direct path without interruption. QUIC/TLS 1.3 encryption remains end to end in both cases.

Do I have to replace my existing IPsec tunnels all at once?

No. The mesh operates at the machine level, independently of router tunnels: you can enroll the machines of a pilot site first, verify the flows that matter, then extend site by site and decommission the tunnels at whatever pace suits you.