TP-Link site-to-site VPN with WireGuard, in 2026.

What is site-to-site VPN in networking?

A site-to-site VPN is an encrypted tunnel that routes two local networks together. Devices on either side reach each other as if they were on one LAN. The branch in Mumbai pings the inventory server at head office in Bangalore at 10.10.40.5, and the packet rides the encrypted tunnel without anyone setting up a single public-facing port.

It's not the same as a remote-access VPN, which connects one user on one device to one network — the kind your laptop dials when you work from a café. And it's not host-to-host either, where a single server tunnels to another single server. Site-to-site is the LAN-to-LAN case. Whole subnets on both ends, talking to each other, routed through the tunnel.

Every site-to-site VPN has two parts: a tunnel and a routing decision. The tunnel is the encrypted pipe — IPsec, WireGuard, PPTP, GRE-over-IPsec, take your pick. The routing decision is where you tell each side: "if the destination IP is in the other side's subnet, send the packet down the tunnel." Both parts have to be right.

People get the tunnel up and then forget the routing. Then they wonder why ping doesn't work. Common pattern. Old pattern. The fix is the same every time: AllowedIPs.

Until 2022 most TP-Link site-to-site guides showed IPsec for this. The 2026 default is WireGuard — for reasons I'll walk through in section four. The short version: fewer config knobs, better behaviour through NAT, and a much shorter path to "first ping works."

Can I put a VPN on a TP-Link router?

Short answer: yes, on every TP-Link product line whose current firmware speaks WireGuard or IPsec. That covers more hardware than people assume.

• Archer (consumer, AX-series) — WireGuard server and client support landed in firmware released from late-2022 onward. The Archer AX73 is among the most commonly seen models at small branches that began with home-grade equipment and never had reason to replace it.
• Deco (mesh kits, X-series) — WireGuard server and client were added in 2024 firmware on most X-series mesh nodes. The "satellite" units inherit the configuration from the main node, so you configure once.
• ER SafeStream gateways (ER605, ER7206, ER8411) — these are TP-Link's small-business router line, and they run the most complete VPN stack in the catalogue. Full WireGuard, full IPsec, both at the same time if you want. The ER605 is the de-facto reference branch router for MeshWG deployments — about ₹6,500 retail, dual-WAN, runs WireGuard with no add-on modules.
• Omada controller-managed gear — IPsec via the controller, WireGuard on individual gateways. The controller mode is fine if your whole estate is Omada; for mixed estates, work directly with each gateway's local WireGuard panel.

The one gotcha worth naming honestly: a handful of older Archer C-series boxes from before 2022 don't support WireGuard server mode, even on the latest available firmware. They can still join a MeshWG mesh as a client peer if the firmware ships WireGuard client support at all — but if it doesn't, the move is either a firmware upgrade (if available) or retiring that unit. Before you commit to a particular model across all branches, open Firmware → About in one router's admin UI, and look for the WireGuard module version. If it's there, you're set.

How to setup a VPN server on a router?

Five steps. Most branches complete all five inside two minutes; the slowest part is typically waiting for the router admin interface to load. The numbers cited below reflect representative onboardings on the TP-Link ER605 — typically under two minutes from clicking Add Machine in the MeshWG dashboard to the first successful ping across the tunnel.

1. Pick the central peer

   Choose the router that will act as the central peer — the one most other branches will dial. Typically this is the head-office gateway, or whichever site has the most stable upstream. Any peer can play this role, and MeshWG calls it the hub, but the role is logical, not physical. If the head-office router dies you can re-elect any branch as the new hub in a few clicks.

2. Open the router's WireGuard panel

   In the TP-Link admin UI, the path depends on the product line. On Archer and Deco it's Advanced → VPN Server → WireGuard. On the ER series it's VPN → WireGuard. On Omada-managed gear, log into the controller and go to Settings → VPN → WireGuard. The post on /quickstart has screenshots of all three paths if you'd rather see them side by side.

3. Generate the keypair, then add the machine in MeshWG

   Hit "Generate keypair" on the router — TP-Link's UI does this in one click. The private key stays on the router and never leaves it. Copy the public key the router prints, then go to the MeshWG dashboard and click Add machine. Paste the public key. Name the machine something you'll recognise three months from now — branch-mumbai-er605 or hq-router both work.

   MeshWG returns the rest of the wg-quick configuration in the dashboard: the Endpoint (always vpn.meshwg.com:51820), the Address for this machine on the overlay, the AllowedIPs that point at the other branches, and a PersistentKeepalive = 25 that keeps the NAT mapping alive through any ISP-edge firewall.

4. Paste the wg-quick block back into the router

   Back in the TP-Link UI, paste the configuration block into the WireGuard peer section. Save. No firmware update, no reboot, no separate certificate file to upload. The router applies the change immediately.

5. Verify the tunnel from a LAN client

   The tunnel comes up within about ten seconds. From a laptop on the branch LAN, ping the head-office overlay IP — by default that's 10.100.0.1. If the ping answers, the tunnel is up, the routing is right, and you can move on to the next branch.

The single most common first-time failure is forgetting to put the remote LAN subnet in AllowedIPs. The tunnel comes up, you can ping the overlay address, but you can't reach 10.10.20.0/24 on the other side because the kernel doesn't know to send those packets down the tunnel. MeshWG's Add machine dialog has a field for the LAN subnet behind this router; fill it in, the dashboard builds the AllowedIPs for every peer accordingly, and the routing just works.

WireGuard vs IPsec for TP-Link site-to-site

Both protocols work. The question is which one fits your branches better — and the answer in 2026 is mostly about three things: NAT, vendor mix, and how much config you want to maintain.

Where IPsec on TP-Link is excellent

IPsec on the ER series and Omada is mature, well-documented in TP-Link's own Omada pages, and the right pick when you have two static public IPs at both ends and you need to interoperate with a non-WireGuard endpoint — for example a Cisco ASA at a partner's data centre, or an AWS Site-to-Site VPN gateway. IPsec is the lingua franca of inter-vendor tunnels and that's a real advantage. If those constraints describe your setup, follow TP-Link's own auto-IPsec guides and you're done.

Where WireGuard on TP-Link earns its place

WireGuard is the right pick when:

• One or both branches don't have static public IPs. ISP CGNAT is now the default for most fibre plans in India, including Reliance Jio's residential and small-business tiers. WireGuard with PersistentKeepalive handles this cleanly because every peer dials outbound. IPsec without NAT-T configuration tends to struggle.
• You want fewer config knobs per branch. A WireGuard peer entry is about eight lines. An IPsec peer with full IKEv2 phase 1 and phase 2 policy is around thirty, plus the transform sets and the proposal selection both ends have to agree on.
• Your branches run a mix of router vendors. WireGuard speaks the same dialect on TP-Link, MikroTik RouterOS 7, OpenWrt 19.07+, Ubiquiti UDM, and OPNsense. IPsec is also cross-vendor in theory, but in practice the IKE policy details bite a lot — and they bite worse across firmware upgrades.
• You want fast failover. WireGuard re-handshakes in a few seconds when an upstream IP changes. IPsec's IKE rekey timers are typically longer.

MeshWG picked WireGuard because most branch offices in 2026 look like the first three bullets above. If your setup looks more like the IPsec scenario — two static IPs, partner interop, existing IPsec stack — IPsec is a perfectly good answer, and the IPsec section of TP-Link's documentation covers it well. Pick the protocol by the branches you have, not by the protocol's marketing.

How to add VPN client to TP-Link router?

The distinction between "VPN server" and "VPN client" on a router is mostly a mental model — under the hood, the configuration on both sides looks the same. The router with a static public address (or one acting as the hub) listens on a UDP port; the router behind ISP NAT dials out to it. Both call themselves WireGuard peers and exchange the same handshake.

On TP-Link gear, the path to add a client is:

• On Archer: Advanced → VPN Client → WireGuard. On some firmware revisions it's labelled VPN Client → WireGuard Client; the panel is the same.
• On the ER series: VPN → WireGuard → Peer. There's no separate "client" submenu — a Peer entry is a Peer entry, and the dialling direction is determined by whether the Endpoint field is filled in (client) or left blank (server).
• On Deco: More → Advanced → VPN → WireGuard Client on current firmware. The configuration applies across the whole mesh; you only set it on the main node.

In every case, the wg-quick block MeshWG hands you in the dashboard is the same — you don't generate a separate "client config" versus "server config." Paste it, save, watch the tunnel come up.

One detail that catches first-time users: if you've got existing inbound port-forwarding rules on the router, they don't conflict with WireGuard as long as nothing else is using UDP 51820 (the WireGuard default). MeshWG's clients all dial outbound regardless, so the router never needs an inbound port open at all. That's the part that makes the no-static-IP case in the next section work.

Connecting three or more TP-Link branches

Almost every guide on the public web stops at two routers. You learn how to configure tunnel-A on one end and tunnel-A on the other end, and that's it. The moment you add a third branch, the textbook approach demands a three-router full mesh, which is three separate tunnel pairs. Add a fourth and you're at six pairs. By the time you hit ten branches you have forty-five tunnel pairs to maintain. That math is why most multi-branch shops either spend on SDWAN appliances or accept a single chokepoint hub-and-spoke through a single router.

The mesh-VPN model collapses the math. Every branch's TP-Link router has exactly one WireGuard peer entry — the MeshWG cloud hub. The hub knows about all the other branches because they each registered themselves the same way. When the Mumbai branch wants to talk to the Bangalore branch, packets ride Mumbai-router → hub → Bangalore-router, and the routing and access policy are decided in one place: the hub's rules table.

From the branch router's perspective, none of this is visible. The router has one peer, talks to one endpoint, and routes overlay-IP packets through that single tunnel. Adding the fifth branch to an existing four-branch mesh is a four-minute job at the fifth branch and zero changes at the other four. Representative deployment patterns at this scale — a distributor network bringing twelve godowns online over a single weekend, for example — typically involve one engineer with a laptop at each site, the MeshWG dashboard open on a phone, and around three minutes of interaction per router. No coordinated change windows are required, no all-sites-online prerequisite applies, and no per-pair tunnel configuration is ever authored by hand.

A few practical things that come up at the third and subsequent branch:

• Overlay IP planning. MeshWG hands out addresses from 10.100.0.0/16 by default. Two hundred and fifty-four branches fit in a single /16 with room for laptops and servers. If you have an existing 10.100.x scheme in use, change MeshWG's pool in the dashboard's Network settings before you onboard the first machine.
• Branch-to-branch access policy. By default any peer in your mesh can reach any other peer. If you want to restrict (say, only branch routers can reach the HQ server subnet, not each other), use the Access Rules panel — the change is enforced on the managed hub within about thirty seconds.
• Revoking a compromised branch. Click "Disable peer" in the dashboard; the hub immediately stops forwarding packets to or from that machine. No need to update anything at the other branches. The branch router can stay configured as-is until you're ready to clean it up.

One operational pattern that consistently saves time on larger rollouts: pre-create every branch's machine entry in the MeshWG dashboard before anyone touches the routers. Spend twenty minutes at HQ generating the wg-quick blocks for branches one through twenty, save each to a shared password manager labelled by branch name, and then the on-site step at each location is a single copy-paste. For a Diwali-week rollout where the branches can't afford downtime windows, this lets the actual cutover at each site take under a minute. The branch manager opens the router admin UI, pastes the saved block, hits Save, and the connectivity team at HQ confirms the new peer in the dashboard within seconds. No coordinated change window needed, no all-sites-online requirement, no off-hours maintenance call.

When neither branch has a static public IP

This is the central reality in every branch-networking conversation in India today. Most independent retail chains, franchise pharmacies, and small clinic groups operate on a single Reliance Jio or Airtel Xstream fibre line per store. None of those lines come with a static public IP — they come with CGNAT, and the public IP on the router's WAN interface changes every few hours. The traditional site-to-site approach simply does not work here: an endpoint without a stable address cannot be dialled.

Cloud control planes fix this without anyone at the branch having to upgrade their internet plan. Both branches dial outbound to a stable hostname — vpn.meshwg.com — which is a real DNS entry that doesn't move. The cloud peer forwards encrypted packets between the two branches. From the branch router's perspective, it's just maintaining one outbound WireGuard tunnel; from the other branch's perspective, same thing. Neither branch needs to be reachable from the public internet. Neither branch opens an inbound port. No dynamic-DNS service subscription, no port forwarding on the ISP-issued router (which most ISPs increasingly lock down anyway).

The WireGuard mechanic that makes this work is PersistentKeepalive = 25 in the wg-quick configuration MeshWG hands you. Every twenty-five seconds the router sends a small encrypted heartbeat outbound to the cloud hub, which keeps the NAT mapping alive at the ISP edge. The result: even when the branch's public IP changes (CGNAT pools rotate), the tunnel re-establishes within a second or two without anyone having to touch anything.

This pattern has been validated on Reliance Jio Fiber, Airtel Xstream Fiber, and ACT Fibernet in 2026 — the three major consumer fibre options across metro India. All three work without configuration changes on the ISP side. The behaviour is consistent: branch router dials out, cloud hub forwards, and the tunnel stays up across IP rotations the carrier performs in the background. The same applies to the double-NAT case where the ISP-issued router sits in front of the TP-Link — the keepalive holds through both NAT layers.

What 20 branches actually cost

The reason we built MeshWG the way we did is that the economics of small-fleet branch networking have been broken for a long time. The choice has historically been: spend ₹30 lakhs on SDWAN hardware to deploy across twenty branches, plus another ₹30,000 per month in licensing — or accept that your branches will run on a patchwork of per-pair IPsec tunnels that some senior engineer maintains on the side. There hasn't been a comfortable middle.

Here's what twenty branches looks like when the routers you already own do the work:

• Hardware — ₹0 new spend. The TP-Link routers already at each branch handle the WireGuard endpoint role. If a branch happens to have an eight-year-old Archer that doesn't speak WireGuard, the replacement is a ₹6,500 ER605, not a ₹2,50,000 SDWAN appliance.
• Software — ₹349 per machine per month. A "machine" is anything in the mesh — the branch router, plus any servers or laptops you want directly on the mesh. Most branches need one machine (the router) on the mesh, occasionally two if they have a local POS server you want HQ to reach directly.
• Monthly total for twenty branches — around ₹7,000 for the typical pattern of "router at each branch plus a couple of HQ machines." That's about ₹4.2 lakhs over five years, against the ₹66 lakhs five- year TCO of a traditional twenty-branch SDWAN rollout. The delta is roughly the cost of a senior engineer's salary for those five years.
• Setup labour — about two minutes per branch on average, plus the time it takes for someone at each branch to log into their router's admin UI. For a twenty-branch rollout I'd budget a single weekend with one engineer coordinating from HQ.

The first two machines are free, forever. That means a pilot — a headquarters router plus one branch — costs nothing and reveals within an hour whether the model fits the environment. Most organisations evaluating this approach run the pilot for two to four weeks, verify the tunnels remain stable under real traffic, then onboard the remainder at the pace the business allows. The meter only begins when the third machine is added.

One honest disclosure for the procurement-minded reader: this cost picture favours MeshWG because we're optimising for the branch-connectivity case on existing routers. If your requirement is WAN optimisation — packet deduplication, application-aware QoS, MPLS replacement at scale, or built-in 4G/5G failover with carrier-managed throughput SLAs — SDWAN vendors do work we don't. Pick by your actual use case, not by the cost number alone.