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.
The DEVNET GRIND! 