I am working on understanding GET vpn. I want to ask few questions:
1) Suppose i have 4 spoke (branches) and one HUB site. With GET VPN spokes are authenticates with hub (key server) and then get security policies and then form VPN with HUB dynamically.It means we dont need to form static vpn tunnels from spokes to hub. DMVPN provides spoke to spoke dynamic VPN tunnel and GET vpn provides spoke to hub dynamic vpn tunnel. Am i right in understanding? But how about routing from spoke to hub and from spoke to spoke? It can be dynamic?
2) GET VPN is tunnel less which preserve the multicast header. But if we have internet between branches and hub then internet does not support routing of multicast traffic. It means GET vpn is beneficial if we have privte WAN?
Get VPN does not form tunnels to hub as DMVPN does, it creates a tunnel to hub to download the Security policies and then it uses these to create a VPN "domain" in which "tunnels" from spoke to spoke are not needed, what I mean is that the WAN where GETVPN is running becomes the encryption domain and then when you need to reach a spoke you go to it via this encrypted domain. Routing happens on the WAN environment prior to the encryption.
2 GETVPN is only recommented for private WAN environments.
Thanks a lot for your reply and great explanation. One more question is that if branches and HUB are interconnected via MPLS network then encryption of multicast traffic with header preservation is not possible i guess because service provider will not do the routing of multicast traffic then in this condition GET VPN can not be used?
GETVPN does not run into similar scalability concerns that IPSec/GRE or DMVPN solutions run into
b) Tunnel header preservation - superior multicast handling
Source and destination stays intact. Multicast packets only need to be encrypted once and then multicast core is responsible for replicating and distributing traffic.
c) Separation of control and data plane.
Inproved scalability because unlike DMVPN or IPsec/GRE or EzVPN hub, a Key Server is not in the data path and is only responsible for control plane thereby resulting in better network scalability
d) Any to Any connectivity w/o a need to negotiate new IPsec tunnels
Due to groups SA concept, any packet which any group member encrypts, can be decrypted by any other group member.
One thing I must point out is that GETVPN is only suitable in environments where we have end to end routing e.g. MPLS or L2 (FR/ATM) connectivity, This is because of tunnel header preservation. If GETVPN has to be deployed on the Internet, it has to be combined with DMVPN or GRE overlay.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...