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:
    1. PKI configuration (optional)
    2. IKE Phase 1 Configuration
    3. GDOI Group Configuration
    4. IPSec profile configuration on KS and crypto map on GM
    5. 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 getvpn

    Next, set the group identifier. It should be the same for all KS and GM. We
    identity number 1234

    identify our router as KS. We
    server local

    configure the change of IPSec keys (exactly them, not ISAKMP) once a day. We set up
    rekey lifetime seconds 86400

    a 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 3

    Configure authentication.
    rekey authentication mypubkey rsa getvpn-export-general
    Here getvpn-export-general are our keys received from CA.

    Next, we specify how to update the keys, unicast or multicast.
    rekey transport unicast

    Next, we actually configure group IPSec SA:
    sa ipsec 1

    We bind the IPSec profile.
    profile GETVPN_PROFILE

    We determine what to encrypt.
    match address ipv4 199

    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:
    access-list 199 permit ip

    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:
    access-list 199 permit ip
    This will significantly reduce the number of SAs.

    Next, configure TBAR (protection against repetitions, based on a time window)
    replay time window-size 5
    and set the address from which we will control the change of keys.
    address ipv4

    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:
    crypto gdoi group getvpn
    identity number 1234
    server address ipv4

    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

    1. You must configure RSA keys on the primary KS and export both keys (private and public) to all COOP KSs.
    2. 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 periodic

    crypto gdoi group getvpn
    server local


    local priority 100

    peer address ipv4
    peer address ipv4

    protocol 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.
    1. 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
    2. COOP KS must have the same GET VPN configuration. This does not happen automatically.
    3. 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 1360

    Thus, summing up :
    1. We have a new technology that allows you to encrypt connections between offices.
    2. The main application is to increase the privacy of MPLS VPN.
    3. Advantages - native support for spoke-to-spoke connections, high scalability and multicast support.
    4. Disadvantages - a direct consequence of the lack of tunnels - limited to impossible work via the public Internet.
    5. 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

    Also popular now: