Cisco Group Encrypted Transport Virtual Private Network (GET VPN)
Cisco GET VPN - a new technology from Cisco, designed to ensure the security of tunnels through provider connections, which has a number of useful features. This article is dedicated to its description, features and customization.
Let's start by tradition with the statement of the problem. Classical topology consists of several branches connected through a provider network.
It is required to connect the networks behind the branches among themselves. The most common solution is IPSec and in particular DMVPN. Which, among other things, is a tunneling technology and allows the use of public Internet channels. The disadvantage of this solution is that the network is built on the principle of hub-n-spoke, and spoke-to-spoke tunnels are installed as necessary, which is not very convenient.
Another common option is MPLS VPN, which although it allows you to build an easily scalable network, does not provide the privacy required in some cases. Cisco GET VPN is designed specifically for MPLS VPN networks, allowing encryption of transmitted data without compromising scalability and reachability of spoke-to-spoke.
In addition, GET VPN technology itself does not tunnel, i.e. replacing the header, which practically negates its applicability when transmitting data over the Internet, since the vast majority of hosts on private networks use private IP addresses. In the case of MPLS VPN, such problems do not arise due to the use of the VPNv4 extension by the provider.
General concepts.
In the future, I assume that the reader is familiar with IPSec technology and terminology.
The innovation of GET VPN is the introduction of the concept of “ trusted group ”, all members of which share the same IPSec SA (security association). This allows any member of the group ( GM , group member) to decrypt the traffic encrypted by any other GM. In addition, since every GM can decrypt our message, we can send multicasts.
For all GMs, the same encryption keys are defined . This is implemented using the GDOI protocol .(Group Domain of Interpretation). Two different keys are used: one for encrypting data, the other for encrypting control messages. The packet to be transmitted is encapsulated by the ESP using the received shared key.
The figure shows that the original title is not replaced by anything, hence the restriction on Internet use.
The key servers ( KS , key servers) are responsible for synchronizing and updating keys . All encryption policies, protocols used, “interesting” traffic, timers, etc. tuned to KS and distributed throughout GM. GMs first authenticate to IKE Phase 1, and then receive the necessary data from KS during registration. In other words, only IKE Phase 1 and KS parameters are configured on GM. He gets the rest automatically.
In addition, since KS actually becomes a point of failure for the entire network, it is possible to create several KS, called COOP KS (cooperative KS), with the ability to pick up functions in cold standby mode.
We pass from terminology to the actual configuration of GET VPN on Cisco IOS.
Customization .
So, let us have the aforementioned topology, the branches in which are connected using MPLS VPN, i.e. we assume that the connection between them has been established and we are not afraid to forward packets with private source and / or destination addresses there.
GET VPN configuration can be divided into several stages:
Stage 1. General for KS and GM.
We configure routers to receive certificates from CA. This is a topic for a separate small article, so in the future I will assume that we received the certificates. The only note will be the need to make the keys on KS as exportable, since they must be the same for all COOP KS.
Stage 2 . In the usual way, we configure the crypto isakmp policy. I will describe the policy using PKI, for pre-shared everything is the same. A few comments. 1) Cisco recommends using AES as the best cryptographic strength / processor ratio. Let me remind you that by default, for isakmp policy authentication is rsa-sig, so the line with it does not appear in the config. 2) Recommended value for rekey
- 1200 s. Cisco recommends doing it in the range of 15-30 minutes, with a default of 20.
Stage 3 . The most serious part.
3.1. Configuring KS
Create a gdoi group.
Next, set the group identifier. It should be the same for all KS and GM. We
identify our router as KS. We
configure the change of IPSec keys (exactly them, not ISAKMP) once a day. We set up
a retransmission scheme when changing keys (there are two types: twice with an interval of 60s or three times with an interval 40c)
Configure authentication.
Here getvpn-export-general are our keys received from CA.
Next, we specify how to update the keys, unicast or multicast.
Next, we actually configure group IPSec SA:
We bind the IPSec profile.
We determine what to encrypt.
Here I allow myself to dwell in more detail. The fact is that for traditional p2p IPSec tunnels it is customary to describe interesting traffic in the most concrete way. for example, for a tunnel between R1 and R2, we would write on R1:
Since there are many tunnels in GET VPN, there will be a lot of such records. Therefore, Cisco recommends that you maximize ACE. For example, in our case, it is best to write ACL 199 as follows:
This will significantly reduce the number of SAs.
Next, configure TBAR (protection against repetitions, based on a time window)
and set the address from which we will control the change of keys.
3.2. GM tuning.
Everything is much simpler here, in fact, we need to specify which group we belong to (using the identity number) and KS of this group. Stage 4. 4.1. KS setup. On KS, you need to create the settings that GM will launch. 4.2 GM setup It is necessary to link the GET VPN group to the crypto map. Stage 5 .Let’s leave for another article, if the topic is of interest :) If you are interested, let's take a look. As already mentioned, we can configure several KS, one of which will be the main one, and the other - to pick up its functions in the fall.
So, to configure COOP KS you need the following:
With keys , I think everyone is familiar.
We generate exportable keys: Export them: And import on all COOP KS: Next, configure KS . Be sure to enable ISAKMP keepalive so that they can detect each other's death. Go to our group. Include redundancy: Assign priority (the server with the highest priority will be primary, if the priorities are equal - primary will be KS with the highest IP address) and point it to all the other KSs And set the timers : Timeout refresh - the interval at which primary KS sends messages to the rest. Default 20s Timeout periodic
- if during this time the secondary KS does not receive refresh messages, it informs all other KS about problems with primary.
Retransmit - the number of messages from secondary KS to all other KS when not receiving a message from primary. By default, 2 messages are sent, after which KS redefine their roles.
By tradition, a few comments.
In conclusion, it remains only to hang our crypto map on the interface and take into account the additional costs of the header:
Thus, summing up :
Again, I do not pretend to be complete. Behind the scenes were the COOP KS settings, the supported router models, and much more. If the topic is interesting - we’ll take a deeper look, but for now let me take a leave :) You
can read in more detail here: GET VPN Design and Implementation Guide
UPD 1. Thank you for valuable comments quickshooter and Fedia
Ilya Podkopaev, instructor
Let's start by tradition with the statement of the problem. Classical topology consists of several branches connected through a provider network.
It is required to connect the networks behind the branches among themselves. The most common solution is IPSec and in particular DMVPN. Which, among other things, is a tunneling technology and allows the use of public Internet channels. The disadvantage of this solution is that the network is built on the principle of hub-n-spoke, and spoke-to-spoke tunnels are installed as necessary, which is not very convenient.
Another common option is MPLS VPN, which although it allows you to build an easily scalable network, does not provide the privacy required in some cases. Cisco GET VPN is designed specifically for MPLS VPN networks, allowing encryption of transmitted data without compromising scalability and reachability of spoke-to-spoke.
In addition, GET VPN technology itself does not tunnel, i.e. replacing the header, which practically negates its applicability when transmitting data over the Internet, since the vast majority of hosts on private networks use private IP addresses. In the case of MPLS VPN, such problems do not arise due to the use of the VPNv4 extension by the provider.
General concepts.
In the future, I assume that the reader is familiar with IPSec technology and terminology.
The innovation of GET VPN is the introduction of the concept of “ trusted group ”, all members of which share the same IPSec SA (security association). This allows any member of the group ( GM , group member) to decrypt the traffic encrypted by any other GM. In addition, since every GM can decrypt our message, we can send multicasts.
For all GMs, the same encryption keys are defined . This is implemented using the GDOI protocol .(Group Domain of Interpretation). Two different keys are used: one for encrypting data, the other for encrypting control messages. The packet to be transmitted is encapsulated by the ESP using the received shared key.
The figure shows that the original title is not replaced by anything, hence the restriction on Internet use.
The key servers ( KS , key servers) are responsible for synchronizing and updating keys . All encryption policies, protocols used, “interesting” traffic, timers, etc. tuned to KS and distributed throughout GM. GMs first authenticate to IKE Phase 1, and then receive the necessary data from KS during registration. In other words, only IKE Phase 1 and KS parameters are configured on GM. He gets the rest automatically.
In addition, since KS actually becomes a point of failure for the entire network, it is possible to create several KS, called COOP KS (cooperative KS), with the ability to pick up functions in cold standby mode.
We pass from terminology to the actual configuration of GET VPN on Cisco IOS.
Customization .
So, let us have the aforementioned topology, the branches in which are connected using MPLS VPN, i.e. we assume that the connection between them has been established and we are not afraid to forward packets with private source and / or destination addresses there.
GET VPN configuration can be divided into several stages:
- PKI configuration (optional)
- IKE Phase 1 Configuration
- GDOI Group Configuration
- IPSec profile configuration on KS and crypto map on GM
- COOP KS Configuration (optional)
Stage 1. General for KS and GM.
We configure routers to receive certificates from CA. This is a topic for a separate small article, so in the future I will assume that we received the certificates. The only note will be the need to make the keys on KS as exportable, since they must be the same for all COOP KS.
Stage 2 . In the usual way, we configure the crypto isakmp policy. I will describe the policy using PKI, for pre-shared everything is the same. A few comments. 1) Cisco recommends using AES as the best cryptographic strength / processor ratio. Let me remind you that by default, for isakmp policy authentication is rsa-sig, so the line with it does not appear in the config. 2) Recommended value for rekey
crypto isakmp policy 10
encr aes
lifetime 1200
group 2- 1200 s. Cisco recommends doing it in the range of 15-30 minutes, with a default of 20.
Stage 3 . The most serious part.
3.1. Configuring KS
Create a gdoi group.
crypto gdoi group getvpnNext, set the group identifier. It should be the same for all KS and GM. We
identity number 1234identify our router as KS. We
server localconfigure the change of IPSec keys (exactly them, not ISAKMP) once a day. We set up
rekey lifetime seconds 86400a retransmission scheme when changing keys (there are two types: twice with an interval of 60s or three times with an interval 40c)
rekey retransmit 40 number 3Configure authentication.
rekey authentication mypubkey rsa getvpn-export-generalHere getvpn-export-general are our keys received from CA.
Next, we specify how to update the keys, unicast or multicast.
rekey transport unicastNext, we actually configure group IPSec SA:
sa ipsec 1We bind the IPSec profile.
profile GETVPN_PROFILEWe determine what to encrypt.
match address ipv4 199Here I allow myself to dwell in more detail. The fact is that for traditional p2p IPSec tunnels it is customary to describe interesting traffic in the most concrete way. for example, for a tunnel between R1 and R2, we would write on R1:
access-list 199 permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255Since there are many tunnels in GET VPN, there will be a lot of such records. Therefore, Cisco recommends that you maximize ACE. For example, in our case, it is best to write ACL 199 as follows:
access-list 199 permit ip 10.0.0.0 0.0.255.255 10.0.0.0 0.0.255.255This will significantly reduce the number of SAs.
Next, configure TBAR (protection against repetitions, based on a time window)
replay time window-size 5and set the address from which we will control the change of keys.
address ipv4 192.168.1.13.2. GM tuning.
Everything is much simpler here, in fact, we need to specify which group we belong to (using the identity number) and KS of this group. Stage 4. 4.1. KS setup. On KS, you need to create the settings that GM will launch. 4.2 GM setup It is necessary to link the GET VPN group to the crypto map. Stage 5 .
crypto gdoi group getvpn
identity number 1234
server address ipv4 192.168.1.1
crypto ipsec transform-set GETVPN_SET esp-aes esp-sha-hmac
crypto ipsec profile GETVPN_PROFILE
set security-association lifetime seconds 7200
set transform-set GETVPN_SET crypto map getvpn-map 10 gdoi
set group getvpn
- You must configure RSA keys on the primary KS and export both keys (private and public) to all COOP KSs.
- It is necessary to configure the actual redundancy
With keys , I think everyone is familiar.
We generate exportable keys: Export them: And import on all COOP KS: Next, configure KS . Be sure to enable ISAKMP keepalive so that they can detect each other's death. Go to our group. Include redundancy: Assign priority (the server with the highest priority will be primary, if the priorities are equal - primary will be KS with the highest IP address) and point it to all the other KSs And set the timers : Timeout refresh - the interval at which primary KS sends messages to the rest. Default 20s Timeout periodic
Primary_KS(config)#crypto key generate rsa general-keys label getvpn-keys modulus 1024 exportable
Primary_KS(config)#crypto key export rsa getvpn-keys pem terminal 3des Ci$co
COOP_KS(config)# crypto key import rsa getvpn-keys pem exportable terminal Ci$co
сrypto isakmp keepalive 15 periodiccrypto gdoi group getvpn
server localredundancylocal priority 100peer address ipv4 192.168.2.1
peer address ipv4 192.168.3.1protocol timeout refresh 20
protocol timeout periodic 30
protocol retransmit 2- if during this time the secondary KS does not receive refresh messages, it informs all other KS about problems with primary.
Retransmit - the number of messages from secondary KS to all other KS when not receiving a message from primary. By default, 2 messages are sent, after which KS redefine their roles.
By tradition, a few comments.
- COOP KS send their messages to UDP port 848, while the messages contain information about all GM and policies. Communication grows with increasing GM numbers and will require fragmentation. In order for KS to process such messages normally, you may have to increase the system buffer:
buffers huge size 65535 - COOP KS must have the same GET VPN configuration. This does not happen automatically.
- COOP KS can be registered on each other also as GM.
In conclusion, it remains only to hang our crypto map on the interface and take into account the additional costs of the header:
ip tcp adjust-mss 1360Thus, summing up :
- We have a new technology that allows you to encrypt connections between offices.
- The main application is to increase the privacy of MPLS VPN.
- Advantages - native support for spoke-to-spoke connections, high scalability and multicast support.
- Disadvantages - a direct consequence of the lack of tunnels - limited to impossible work via the public Internet.
- A feature is the presence of common IPSec keys, allowing all members of the group to decrypt messages sent by other members of this group.
Again, I do not pretend to be complete. Behind the scenes were the COOP KS settings, the supported router models, and much more. If the topic is interesting - we’ll take a deeper look, but for now let me take a leave :) You
can read in more detail here: GET VPN Design and Implementation Guide
UPD 1. Thank you for valuable comments quickshooter and Fedia
Ilya Podkopaev, instructor