Nowadays, the requirement for encrypted communication between business locations is part of the standard requirements from our customers. More and more regulatory laws force the use of encrypted communication.
The classic scalability issue with IPSec site-to-site encryption is that it requires each location to have a VPN to every other location. In other words, we will need N^2 tunnels defined on a network with N devices. This is obviously, a non scalable solution.
A partial list of this and other scalability issues of the site-to-site VPNs are:
- Require a full mesh. In other words, require N^2 tunnels to be defined.
- Create an overlay logical network over the network. In many cases, this also means, having different routing tables. One for the encrypted path and one for the regular path.
- Only basic QoS supported
- Very inefficient multicast replication
To work around these issues Cisco created the Group Encrypted Transport (GET) VPN. Among the benefits GET VPN offer are:
- Scalable architecture
- Any-to-any instant connectivity
- Native routing with no overlays
- Support for Advanced QoS
- Efficient Multicast replication
- Transport agnostic (works with private LAN/WAN, FR/AATM, IP, MPLS)
GET VPN defines one or more key-servers which authenticates group members, distributes keys and policies. The traffic is encrypted on demand basis by the group members (i.e. participant routers). Contrary to IPSec which defines a new IP header, GET VPN preserve the original IP header and thus maintain QoS and multicast information for the connection.
Representation of an IP packet, IPSec Encrypted Packet and GET Encrypted Packet:
For more technical information on Cisco Group Encrypted Transport VPN visit this site.
The next part of this tutorial will cover actual configuration examples of GET VPN.
