GET VPN – Key Servers, Group Members, and Tunnel-less VPN Tunnels some how!


GET VPN or Group Encrypted Transport VPN is a whole different animal than Tunneling traffic between sites in an integral / encrypted manner, as it is a “Tunnel-less” approach to VPN between Branch locations!

Some important components to GET VPN that make it possible

KS / Key Server = Responsible for pushing “GET VPN” Policy to Group Members

GM / Group Members = GET VPN Group Members

TEK / Transport Encryption Key = Group Members use to Encrypt their traffic

KEK / Key Encryption Key = Encrypt Traffic to Key Server

So the Group Members use the KEK to get their Policy from the Key Server, then use the TEK to Encrypt their traffic, all while somehow remaining Tunnel-less.

Think about Tunnel-less. No endpoints. No Peers.

Tunnel-less VPN is done by utilizing the Original IP Header of packets, called “IP Header Preservation” when not being hidden within an Encrypted Tunnel.

The Key Server pushes a Policy to GET VPN Group Members defining what traffic to protect, and how to protect it, which does use IPSec ESP (Encapsulated Security Paylod) to Encrypt the traffic (though IPSec does not imply a tunnel).

This technology can also be piggy backed onto DMVPN!

Because of the nature of Key Servers and using Original IP Headers which DMVPN works right around NAT Translations, we could configure GET VPN right on top of DMVPN, though I am honestly not sure what that would look like at this stage 🙂

GDOI is the ISAKMP Domain of Interpretation (DOI) = The Language of GET VPN’s Key Servers and Group Members!

Unfortunately there is no configuration for this one, as this is still within the CCIE R/S VPN Technologies, where configurations are more towards the CCIE Security.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s