GET VPN Explained: Tunnel-less Encryption for Private WANs

By Taylor Thomas · 2026-09-02

The site-to-site VPN designs on the SCOR blueprint build overlay tunnels: endpoints negotiate keys, and encrypted traffic flows between tunnel endpoints. GET VPN — Group Encrypted Transport — is the exception. It encrypts traffic between any number of sites without building a single tunnel, by separating the two jobs a VPN normally bundles together: key management moves to a dedicated key server, and encryption stays on the routers, using keys the whole group shares.

The Group Model

In a pairwise IPsec design, N sites that all need to reach each other face a full mesh of negotiated security associations, and each new site means new negotiations at every existing site. GET VPN replaces that with a group. Each router — a group member — registers once with a key server using GDOI, the Group Domain of Interpretation defined in RFC 6407. The key server authenticates the member, then pushes down the group policy: what traffic to encrypt, which algorithms to use, and the keys themselves.

Two kinds of keys come down. Traffic encryption keys, or TEKs, are what group members use to encrypt and decrypt the data plane — because the group’s members share its current TEKs, any member can decrypt traffic from any other, and adding a site means one key-server relationship, not pairwise negotiations with every peer. The key encryption key, or KEK, protects the rekey channel: when the key server refreshes keys before they expire, it sends rekey messages encrypted with the KEK, either as unicast to each member or as multicast to the group. The key server distributes keys and policy but forwards no user traffic — it sits entirely outside the data path, so its load scales with membership and rekey events, not with traffic.

Header Preservation: The Actual Trick

What makes the design tunnel-less is what happens to the IP header. Standard IPsec tunnel mode encapsulates and protects the entire original packet — header included — behind a new outer header addressed between tunnel endpoints; that outer header is the tunnel. GET VPN uses the same tunnel-mode encapsulation but with header preservation: the original source and destination addresses are copied into the outer header. The network between sites sees encrypted packets carrying the same addresses the cleartext carried, and forwards them by those addresses.

That preserves what depends on addresses. Routing needs no overlay: the WAN’s existing routing carries the encrypted traffic. Multicast keeps working natively, replicated by the core exactly as before, rather than being unicast-replicated into tunnels. Any-to-any traffic flows directly between sites, with no hub to hairpin through.

The same property draws the deployment boundary. Header preservation means internal addresses appear on the wire and must be routable end to end — true on a private WAN such as an MPLS L3VPN, where the provider already routes your addressing, and generally false across the public internet, where private addressing is not routable and address translation along the path breaks header preservation. GET VPN answers a specific question: the sites are already connected and can already reach each other — the WAN just cannot be treated as trusted. Encryption is added; topology is not.

Group Consequences

Sharing security associations across many senders changes some IPsec mechanics. Conventional anti-replay keeps a sequence-number window per inbound security association, which cannot arbitrate many independent senders transmitting under one shared SA — so GET VPN provides time-based anti-replay, discarding packets whose time-based sequence values fall outside a configured window against a shared pseudotime reference the key server maintains and distributes to the group.

The key server also becomes critical infrastructure. Members holding valid keys keep encrypting if it fails — it is not in the data path — but registration and rekeying stop, and keys have lifetimes. Production designs therefore deploy cooperative key servers: multiple key servers that synchronize group state, with one elected primary handling rekeys and the others ready to take over.

Where It Sits on the Blueprint

SCOR 350-701 v2 objective 1.6 asks you to describe site-to-site and remote access VPN deployment types, naming GETVPN alongside virtual tunnel interfaces, standards-based IPsec, SSL VPN, DMVPN, and FlexVPN — the exam skill is matching the model to the requirement: overlay tunnels for the internet, group encryption for the private WAN that needs any-to-any encryption with native multicast. The SCOR course builds the underlying IPsec mechanics first — the ISAKMP-based IKE machinery that GDOI registration builds on, and the transport choices that pairwise designs make — and the full VPN design map, from crypto foundations to platform configuration, lives in the course catalog.

Frequently Asked Questions

What makes GET VPN tunnel-less if it still uses IPsec?

GET VPN encrypts with tunnel-mode IPsec but copies the original source and destination addresses into the outer IP header, so no point-to-point tunnel is created and the WAN forwards the encrypted packet by the same addresses the cleartext carried. Address-based routing, address-based QoS classification, and multicast replication keep working because the addresses the network sees do not change — though encryption does grow the packet and hides transport-layer ports from in-path classification.

Why is GET VPN not used over the public internet?

Header preservation exposes the original source and destination addresses on the wire, and the encrypted packets are routed by those addresses. On a private WAN such as an MPLS VPN those addresses are routable end to end. On the public internet private addressing is not routable and address-translating middleboxes generally break the header-preservation model, so overlay designs like DMVPN or FlexVPN fit instead.

What happens if the key server fails?

Encryption between group members continues, because the key server is not in the data path and members hold valid keys until they expire. What stops is new registration and rekeying — which is why production designs deploy cooperative key servers that synchronize group state, so a surviving key server continues issuing rekeys.