In traditional IPSEC VPN we use transform sets and ACLs to define what should be encrypted and how it should be encrypted. Also worth noting if you have more than one KS in the domain for failover etc you will need to make this key exportable and copy it to all other KS. We'll reference this key when we configure the KS config for our GET VPN so it is important to label it and reuse the name later on. % Generating 2048 bit RSA keys, keys will be non-exportable.
KEYS-1(config)#crypto key generate rsa label GETVPN modulus 2048 The KEK uses RSA keys to protect it so we need to generate this for the KEK: The IKE policy we created above is used for the initial connection to the KS but after this our KEK is used to protect all communication from the KS to the GM. So far we've configured any GET VPN specific config at all but now with the KS config we will! There are a few steps to getting a usable Key Server up and running
Just to be clear this isnt required on the Middle-Man or any transit router. We could configure specific keys but in this case we're not labbing IKE so lets make it easy for ourselves and define a key we'll accept from any source :) Confirm on each with show crypto isakmp policy or similar. KEYS-1(config)#crypto isakmp key 0 MYISAKMPKEY address 0.0.0.0 0.0.0.0 KEYS-1(config-isakmp)#authentication pre-share We'll be using the config below on all devices in our lab: This is used for the initial connectivity from the GM to KS and as ever both the KS and GM need to have one common IKE policy defined that matches exactly on both devices. Group Member (GM) - Encrypt the traffic defined by the KS over the GDOI ( Group Domain of Interpretation)ĭone? (but as ever worth testing yourself) :D The Middle-Man router could easily represent a 元VPN cloud or any other network we have end to end connectivity (of all subnets) on.E.g we can ping from 10.1.1.1 to 10.3.3.3.Key Server (KS) - Shares TEK securely, controls polices and handles re-keying.IKE/ISAKMP profile - Initial secure connection to KS.Middle-Man is completely unaware of the GET VPN (even though the payload is encrypted) and is only there to represent a transit network for the group members network.
CISCO IKEV2 NAME MANGLER FULL
We already have full connectivity between all IPs configured and we'll go through the tunnel setup. It does mean GET VPN is not suitable for general usage over the internet though.įor the Lab we'll be using the topology below and the GNS3 topology and config files can be found.
A side benefit of this single SA and no header modification/tunneling is that if the underlying network supports multicast we can send/encrypt once and that will still be delivered by the network to all devices that need it allowing us again to scale very nicely vs sending/encrypting multiple multicast packets to leave the same interface in traditional point to point vpn networks. This means full IP connectivity before we enables GET VPN is a requirement. One feature GET does not provide over traditional VPNs is tunnelling or encapsulation as we just encrypt the payload data so source/destination IPs etc stay unmodified in the IP header. The initial communication between a new group member (GM) and Key Server (KS) also needs to be secure so accomplish this GET VPN uses an already proven protocol, IKE :) IKE is also used for continued key distribution from the KS to GMs (rekeying) and to protect these transmissions we obviously cant use the TEK so another key is used called the Key Encryption Key (KEK) to protect this IKE tunnel from KS to GM. All group members contact the KS to obtain the TEK and policy for what traffic to encrypt. These are responsible for securely sharing the TEK among all the group/domain members participating in the VPN along with polices to define the "interesting traffic" etc. To do this key "sharing" GET VPN uses a device(s) called Key Servers. For GET we'll only have one single shared key (call the "TEK" or Traffic Encryption Key) encrypting and decrypting all the traffic between all members of the VPN "domain"! This means we can scale much more than traditional VPNs. The most import thing to remember at GET VPN is the "G" means group and the whole group is one single security association!! For traditional VPNs mutliple SPIs can use muliple keys and they number of SA's scales directly with the number of VPN Peers. Group Encrypted Transport (GET) VPN is slightly different and has quite different use cases from more traditional point to point IPSEC VPN where each point to point VPN is quite distinct in its own right.
0 kommentar(er)
