Seven Ways to Connect a Branch — and Why the Choice Matters
Get this decision wrong and you re-cable the WAN in six months.
Every one of these seven technologies can connect a branch office to headquarters over a WAN. What they don't have in common is encryption, dynamic-IP tolerance, multicast support, or how many branches they scale to before configuration turns into a full-time job. Picking the wrong one usually doesn't fail outright — it just quietly becomes painful at branch number twelve, or the day a regulator asks why the data isn't encrypted.
This note is a planning reference for branch-interconnection technology selection, built from the site-to-site VPN chapter of Huawei's AR router configuration guide. It covers L2TP, GRE, DSVPN, IPSec, BGP/MPLS IP VPN, VLL and PWE3 — one section per technology, each with its real applicable scenario, its actual pros and cons, and a verbatim core configuration skeleton. If you need the details on running IPSec on top of one of these, getting IPSec through NAT, or building a virtual-tunnel-interface IPSec design, those are separate notes: DSVPN over IPSec, IPSec Virtual Tunnel Interface, and IPSec NAT Traversal.
Which One Do You Actually Need
Start with what the traffic needs, not with the technology you already know.
| Technology | Native encryption | Dynamic-IP endpoint support | Multicast / routing over tunnel | Typical scale |
|---|---|---|---|---|
| L2TP | No — pair with IPSec | Yes (dial-up LAC) | No | Per-user tunnels, small-to-medium |
| GRE | No — pair with IPSec | Limited — needs stable source/destination | Yes | Point-to-point, small |
| DSVPN | No — pair with IPSec | Yes (NHRP-registered spokes) | Yes (mGRE + dynamic routing) | Large hub-and-spoke, many branches |
| IPSec | Yes | Yes (aggressive mode) | No (policy-based, native) | Medium-to-large with policy templates |
| BGP/MPLS IP VPN | No | No — fixed carrier PE routers | With MVPN extensions (not covered here) | Very large, carrier-operated |
| VLL | No | No | N/A — Layer 2 point-to-point | Small, point-to-point only |
| PWE3 | No | No | N/A — specialized circuit emulation | Small, point-to-point only |
Configuration Highlights, One Technology at a Time
Scenario, real trade-offs, and the core CLI skeleton — for each of the seven.
L2TP — Remote-Access and Multi-Tenant Dial-Up VPN
L2TP's natural habitat is remote-access and dial-up: a LAC (often the branch's own gateway, or a PPPoE-terminated remote user) tunnels PPP sessions to an LNS at headquarters, which authenticates the user and hands out an address from a local pool. It's the right choice when the branch side is a large, changing population of individual dial-up users rather than a fixed site-to-site link — RADIUS-backed authentication and per-user IP assignment come almost for free. What L2TP does not give you is encryption: the tunnel is a clear PPP-over-UDP encapsulation, so anything sensitive needs L2TP over IPSec layered on top. Pros: user-level authentication, per-user addressing, works over any IP path, RADIUS support. Cons: no native encryption, tunnel authentication password must match exactly on both ends, not a full-mesh branch technology.
-- LAC side -- l2tp enable # interface Virtual-Template1 ppp authentication-mode chap # l2tp-group 1 tunnel password cipher %@%@AbCd1234%@%@ tunnel name lac1 start l2tp ip 202.1.1.1 domain aaa.com -- LNS side -- l2tp enable # ip pool 1 gateway-list 10.1.1.1 network 10.1.1.0 mask 255.255.255.0 # interface Virtual-Template1 ppp authentication-mode chap remote address pool 1 ip address 10.1.1.1 255.255.255.0 # l2tp-group 1 allow l2tp virtual-template 1 remote lac1 tunnel password cipher %@%@AbCd1234%@%@ tunnel name lns
GRE — the Simplest Tunnel, With the Fewest Guarantees
GRE is the plainest of the seven: it wraps one IP packet inside another IP packet between two fixed tunnel endpoints, and that's essentially the whole feature set. Its real value is that it turns two remote LANs into what looks like a directly-connected link, which means a dynamic routing protocol like OSPF can run straight over it — useful when branch and HQ routing tables need to stay in sync automatically rather than through static routes. GRE carries no encryption or authentication of its own; on the public internet it is normally paired with IPSec (IPSec over GRE), and GRE's own source/destination addresses have to be reachable and, in most designs, static. Pros: dead simple, supports multicast and dynamic routing over the tunnel, works across almost any IP network. Cons: no encryption or authentication, best suited to point-to-point, source/destination addressing needs to be stable.
interface Tunnel0/0/1 ip address 10.3.1.1 255.255.255.0 tunnel-protocol gre source 20.1.1.1 destination 30.1.1.2 # ip route-static 10.2.1.0 255.255.255.0 Tunnel0/0/1
DSVPN — Hub-and-Spoke That Grows Into Spoke-to-Spoke
DSVPN (Dynamic Smart VPN) is what GRE becomes once a hub needs to talk to dozens of spokes whose public IP addresses change: an mGRE tunnel interface at the hub accepts registrations from spokes via NHRP, so each spoke can appear and re-appear at a new IP address without anyone touching the hub's configuration. With nhrp shortcut and nhrp redirect, spoke-to-spoke traffic can even build a direct tunnel between two branches instead of hairpinning through the hub every time. A second hub can be added purely for resilience, differentiated by OSPF cost so spokes prefer the primary and fail over automatically. Like plain GRE, DSVPN carries no encryption by itself; production designs almost always run IPSec over DSVPN — see the dedicated DSVPN over IPSec note for that binding. Pros: scales to large branch counts with a single hub configuration, tolerates dynamic spoke addressing, dual-hub resilience, spoke-to-spoke shortcut avoids hub bottleneck. Cons: still no native encryption, requires every device to have public-network reachability, dual-hub designs must not share a subnet.
-- Hub -- interface Tunnel0/0/0 ip address 172.16.1.1 255.255.255.0 tunnel-protocol gre p2mp source Ethernet1/0/0 nhrp entry multicast dynamic ospf network-type broadcast -- Spoke -- interface Tunnel0/0/0 ip address 172.16.1.101 255.255.255.0 tunnel-protocol gre p2mp source Ethernet1/0/0 nhrp entry 172.16.1.1 1.1.1.1 register ospf network-type broadcast
IPSec — the One With Actual Encryption
IPSec is the technology on this list that's actually built for confidentiality and integrity: an IKE negotiation establishes a shared key, and the resulting IPSec SA encrypts and authenticates the traffic that matches a defined ACL. It works over static or dynamic (aggressive-mode) peer addresses, tolerates NAT with NAT-T, and can protect either a policy-based ACL match or a full virtual-tunnel-interface's worth of traffic. It's the default answer whenever the two ends cross a public network and the data actually matters — but it isn't a routing technology by itself: without a tunnel interface, dynamic routing protocols can't run over an IPSec policy the way they can over GRE or DSVPN, which is exactly why IPSec is so often paired with one of those two instead of used alone. Pros: real encryption and authentication, NAT traversal, works with dynamic peer addresses, policy templates let one hub gateway accept many branch peers without per-branch config. Cons: policy-based IPSec alone doesn't carry a routing protocol, ACL definitions on both ends must mirror each other exactly, DPD and cipher-suite mismatches are the most common interoperability failures.
acl number 3101 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 # ipsec proposal tran1 esp authentication-algorithm sha2-256 # ike proposal 1 encryption-algorithm aes-cbc-128 dh group14 authentication-algorithm sha2-256 # ike peer spub v1 exchange-mode aggressive pre-shared-key cipher %^%#AbCd1234%^%# ike-proposal 1 local-id-type name remote-name huawei02 local-address 1.1.1.1 remote-address 2.1.1.1 # ipsec policy map1 10 isakmp security acl 3101 ike-peer spub proposal tran1
BGP/MPLS IP VPN — What the Carrier Runs, Not What You Run
This is the odd one out on this list: BGP/MPLS IP VPN is what a carrier's backbone runs to keep hundreds of customers' VPNs logically separate over one shared MPLS network, using route-distinguishers and route-targets to keep each customer's routes private while a single physical infrastructure carries them all. A branch office doesn't deploy BGP/MPLS IP VPN on its own; it becomes a CE (customer edge) router handing routes to the carrier's PE (provider edge) router, typically over BGP, OSPF, static routes or ISIS. It shows up on this list because a lot of "what should we use to connect our branches" conversations are actually asking whether to build IPSec/DSVPN over the public internet, or subscribe to a carrier's MPLS L3VPN service — and the honest answer is that those solve different budgets and different trust models, not the same problem with different syntax. Pros: carrier-grade separation and scale, doesn't require the customer to manage encryption or tunnel state, PE-CE routing options are flexible. Cons: requires a carrier relationship and MPLS backbone access, is a service you buy rather than infrastructure you build, cross-domain designs get complex fast when multiple carrier ASes are involved.
ip vpn-instance vpna ipv4-family route-distinguisher 100:1 vpn-target 111:1 export-extcommunity vpn-target 111:1 import-extcommunity # mpls lsr-id 1.1.1.9 mpls mpls ldp # interface Ethernet1/0/0 ip binding vpn-instance vpna ip address 10.1.1.2 255.255.255.0 # bgp 100 peer 3.3.3.9 as-number 100 peer 3.3.3.9 connect-interface LoopBack1 ipv4-family vpnv4 policy vpn-target peer 3.3.3.9 enable ipv4-family vpn-instance vpna peer 10.1.1.1 as-number 65410 import-route direct
VLL — a Leased Line, Rebuilt Over MPLS
Virtual Leased Line (Martini-style VLL) does one specific job: it makes two Ethernet (or other Layer 2) interfaces on two different routers behave like they're connected by a dedicated wire, tunnelled across an MPLS core via LDP-signalled pseudowires. There's no IP routing decision involved at all — it's a Layer 2 cross-connect, which is exactly why it's the right tool when a customer's own routing has to stay completely untouched by the carrier network in between. It doesn't scale past point-to-point: each VLL connects exactly two access circuits, so a network of many branches needs many VLLs, not one shared VLL. Pros: fully transparent Layer 2 emulation, customer routing is invisible to the carrier core, can run over a GRE tunnel via tunnel-policy when the core doesn't support native MPLS. Cons: strictly point-to-point, no encryption, requires MPLS LDP infrastructure end to end (or a GRE substitute).
mpls lsr-id 10.10.10.1 mpls mpls l2vpn mpls ldp # mpls ldp remote-peer 10.10.10.3 remote-ip 10.10.10.3 # interface GigabitEthernet1/0/0 mpls l2vc 10.10.10.3 101
PWE3 — Circuit Emulation for the Traffic That Isn't IP At All
PWE3 (Pseudo-Wire Emulation Edge-to-Edge) is what VLL becomes when the circuit being carried isn't Ethernet at all — TDM, E1, or other legacy interfaces that predate IP entirely. The example this note draws from is genuinely niche but instructive: a legacy voice-radio E&M interface, carried across an MPLS TE tunnel with hot-standby backup and BFD-triggered failover, so that a link failure produces no audible interruption in the carried traffic at all. If a branch has some genuinely legacy non-IP equipment that has to keep working across a WAN upgrade, PWE3 circuit emulation is the technology that lets it keep behaving exactly as it always did. Pros: transparently carries non-IP legacy circuits, can be combined with MPLS TE hot-standby and BFD for near-zero-loss failover. Cons: highly specialized, point-to-point only, requires hardware/interface support for the specific legacy circuit type, most enterprise branch networks will never need it.
interface Serial4/0/0 link-protocol tdm em passthrough enable mpls l2vc pw-template pe2pe 300 tunnel-policy te # pw-template pe2pe peer-address 2.2.2.9 jitter-buffer depth 8 tdm-encapsulation-number 8 # interface Tunnel1/0/0 tunnel-protocol mpls te mpls te backup hot-standby mode revertive wtr 15
Five Selection Gotchas
SYMPTOMGRE and DSVPN Are Not Encryption — They're Just Tunnels
A network diagram calls it "the branch VPN," and everyone assumes traffic between sites is encrypted, because it says VPN.
CAUSEGRE and DSVPN provide tunneling and, for DSVPN, dynamic hub-spoke registration — neither provides confidentiality. Traffic inside a plain GRE or DSVPN tunnel is exactly as visible to anyone capturing it as it would be unencapsulated.
FIXIf the data needs confidentiality on a public network, run IPSec over the GRE or DSVPN tunnel — see the DSVPN over IPSec note for the exact binding.
SYMPTOMDSVPN Assumes Every Device Has Public-Network Reachability
A new spoke behind a NAT gateway or carrier CGNAT registers with the hub, but spoke-to-spoke shortcut traffic never establishes.
CAUSEDSVPN's NHRP registration and shortcut mechanism assume the hub and spokes can reach each other's public addresses directly. If a spoke's real address is hidden behind NAT the hub can't traverse, hub-spoke registration succeeds but spoke-spoke shortcut traffic frequently doesn't.
FIXConfirm public-IP reachability for every device before designing a DSVPN deployment — this is a prerequisite, not an edge case.
SYMPTOMIPSec ACLs That Don't Mirror Exactly Silently Drop Half the Traffic
One direction of an IPSec tunnel passes traffic, the other doesn't — or the tunnel comes up but only some subnets get through.
CAUSEThe security ACL on each end defines which traffic gets protected, and the two ACLs must be exact mirror images with source and destination swapped. A typo or an omitted subnet on one side leaves that subnet's traffic outside the protected match.
FIXBuild both ACLs from the same source list and swap source/destination programmatically rather than retyping them, and re-verify with display ipsec sa after any subnet addition.
SYMPTOMBGP/MPLS IP VPN Isn't Something You Configure on Your Own Branch Router
A team spends weeks trying to reproduce "MPLS VPN" using CPE routers and public internet links, and gets nowhere.
CAUSEBGP/MPLS IP VPN requires PE routers on a carrier's MPLS backbone running route-distinguishers, route-targets and MP-BGP. A branch's own router is a CE, not a PE, and can't create the VPN separation on its own.
FIXIf the requirement is genuinely carrier-grade multi-site MPLS separation, buy that as a carrier service. For a self-managed alternative over the public internet, DSVPN or IPSec provides the equivalent capability.
SYMPTOMVLL and PWE3 Don't Scale to a Branch Mesh
A design calls for VLL to connect five branches to headquarters and ends up with an unmanageable number of separate pseudowires.
CAUSEVLL and PWE3 are point-to-point by design — a Martini VLL or a PWE3 circuit emulates exactly one dedicated wire between exactly two access interfaces. There is no hub-and-spoke or full-mesh mode.
FIXUse VLL/PWE3 only for genuine point-to-point requirements — a single leased-line replacement, or one legacy circuit. For anything needing more than two sites, use DSVPN or BGP/MPLS IP VPN instead.
Five Frequently Asked Questions
Which of these seven technologies needs a public IP address at every site?
DSVPN and IPSec both tolerate dynamic addressing on the branch side — NHRP registration for DSVPN, aggressive mode for IPSec — as long as every device can actually reach the others' public addresses. GRE and VLL/PWE3 are built around fixed endpoints. BGP/MPLS IP VPN sidesteps the question because the carrier's PE routers handle public-network transport.
Can two of these be combined?
Routinely — IPSec over GRE, IPSec over DSVPN and L2TP over IPSec are all standard combinations, precisely because the tunneling technologies (GRE, DSVPN, L2TP) don't provide encryption on their own.
Which is cheapest to deploy without carrier involvement?
GRE, DSVPN, IPSec, VLL and PWE3 can all be built entirely with customer-owned routers over the public internet or a leased line — no carrier MPLS relationship required. BGP/MPLS IP VPN is the exception: it's fundamentally a carrier service.
Does IPSec work if one side is behind NAT?
Yes, with NAT traversal — aggressive mode plus the nat traversal command, or automatic NAT-T detection on newer software. See the IPSec NAT Traversal note for the exact configuration and ID-type details that make it work.
What's the right technology for connecting 50 branch offices to one headquarters?
DSVPN, purpose-built for large hub-and-spoke deployments with a single hub configuration handling any number of spokes via NHRP, optionally with a second hub for resilience. IPSec over DSVPN adds encryption on top without changing that scaling story.
Related Solution Designs
Multi-Branch VPN Interconnection
The full design this technology comparison feeds into once headquarters needs to connect ten, fifty or more branch sites.
Branch & Remote Access Security (SASE)
One policy layer for every site and every remote worker, once the tunnel technology underneath is decided.
Not sure which of these fits your branch footprint?
Tell us how many sites, what access circuits they already have, and whether encryption is a hard requirement.
Related Reading
DSVPN over IPSec
The exact binding this comparison keeps pointing to whenever DSVPN needs encryption layered on top.
IPSec Virtual Tunnel Interface
How to give policy-based IPSec a routable interface so dynamic routing protocols can run over it.
IPSec NAT Traversal
What changes in IKE and ACL design when one or both IPSec peers sit behind NAT.