close
VPN Guides

How To Deploy IPSec GETVPN on Cisco IOS Routers

    get vpn explained

    A question I often get asked as a Security consultant is how clients can deploy VPN connections to their branch office faster. A relatively simple option is getvpn or dmvpn.

    Below is an example Cisco get vpn design guide, suitable for IOS deployments.

    Recommended Baseline Network Topology

    This deployment shows the configuration steps required using centralized key servers, group members installed on the remote branch/office routers and a single GETVPN group. Four key servers are deployed across two data centers and the group members in the remote office are configured with the nearest key server. IP/MPLS core is just a transport medium, and the group members are either Serial or Ethernet connected remote office routers. The group member will encrypt the unicast/multicast traffic and forward it to the MPLS core for replication. The MPLS core is responsible for multicast packet replication for all other group members distributed across the core.

    This can be achieved only if the original data source and destination networks are routable since the original network addresses are used on the IPsec/IP header (header preservation) after encrypting the multicast packet.

    Recommended Routing Configuration

    1. BGP is recommended on the WAN. OSPF is recommended on the LAN (for two or more Routers), and Static Routing is recommended to establish EBGP Peers and IPSEC sessions across the MPLS.
    2. BGP is the recommended routing protocol between Remote Site and Head-End. EBGP Peering should be configured between remote office router and IP/MPLS PE Router. IBGP peering should be configured between local Routers in the same remote site/office.
    3. At the Head-End, each Data Center gets their own BGP ASN, with EBGP peering to the IP/MPLS PE Router and their local Tier-2 Router. A single BGP ASN (65000) is assigned to all branches since it is locally significant and removed at the Head-End.
    4. Most remote offices should use the standard TO_BRANCH example policy on the Branch aggregate routers. This sends a data center specific subset of routes to the remote office, along with a default route. This allows the remote office use the most direct connection for the services within the datacenters they connect.
    5. One of the default routes should be preferenced at the remote office to provide consistent user response to services outside of the directly connected data centers. For simplicity, preference the circuit with the lower end-to-end round-trip latency.

    If and when necessary, remote offices can have a tailored route policy. Tailored route policies may be required for MPLS connectivity, and for country connectivity.

    Remote offices only need to advertise their summarized IP space out to Tier-2. Depending on the remote office IP space, a CSPAN route maintenance request may be necessary.

    Network Pre-requisites

    • The enterprise network must have full network reachability between the routers configured as a key server and group member.
    • Remote office routers should be configured for a group member or key server based on the deployment.
    • To use Multicast routing across the IP/MPLS core, multicast VPN must be enabled by the provider.
    • Protocol Independent Multicast (PIM) sparse-mode must be enabled in the provider edge facing interfaces of the group members and the key servers.
    • PIM Rendezvous Point (RP) must be reachable from all the group members and the key servers for the multicast groups address recommended across the IP/MPLS Core.
    • DNS, NTP, PKI (if required), and AAA servers must be reachable in the network.

    Key Server Configuration

    crypto key generate rsa general-keys lab GDOI-REKEY expo mod 1024
    crypto key export rsa GROUP-VPN pem url tftp://10.144.19.40/ 3des password

    The following configuration enables the key server in a router:

    crypto gdoi group GROUP-VPN
    identity number 65000
    server local
    rekey retransmit 10 number 2
    rekey authentication mypubkey rsa GDOI-REKEY
    rekey transport unicast
    sa ipsec 10
    profile gdoi1
    match address ipv4 ACL_GDOI_SA
    no replay
    address ipv4 192.1.1.2
    

    Note

    The policies defined in the key server are downloaded to all group members irrespective of which group member has the network addresses defined in the policy.

    Configure ISAKMP and IPSEC profile

    Then configure the ISAKMP and IPsec profile. The lifetime configuration for the group IPsec SA is defined under the ‘crypto ipsec profile’ configuration below. This configuration uses 2 hours. This deployment uses Pre-shared Keys for authentication between group members/key servers; PKI integration has been tested and certified, but in the absence of a production PKI infrastructure, PSK is recommended.

    crypto keyring gdoi1
    pre-shared-key address 0.0.0.0 0.0.0.0 key example123
    !
    crypto isakmp policy 10
    encr 3des
    group 2
    authen pre-share
    crypto isakmp keepalive 30 periodic
    
    crypto ipsec transform-set example-trans-gdoi esp-3des esp-sha-hmac
    !
    crypto ipsec profile gdoi1
    set security-association lifetime seconds 7200
    set transform-set gdoi-trans-group1
    

    The following configuration shows that there is no crypto map associated with any physical interface.

    interface Loopback0
    ip address 10.163.127.236 255.255.255.255
    !
    interface GigabitEthernet0/1
    description Branch Router
    ip address 10.163.30.12 255.255.255.128
    ip pim query-interval 5
    ip pim sparse-mode
    duplex auto
    speed auto
    

    Cooperative Key Server Configuration

    The procedure to export and import RSA keys is given below.

    crypto key generate rsa general-keys lab GDOI-REKEY expo mod 1024
    % Generating 1024 bit RSA keys, keys will be exportable...[OK]
    

    !!! Export this key to the terminal or TFTP. !!!

    crypto key export rsa GROUP-VPN pem url tftp://10.144.19.40/ 3des password
    

    !!! Import this key using cut-and-paste on all the other key servers. An exportable option is to allow this procedure for any other key servers deployed later. !!!

    crypto key import rsa GROUP-VPN pem general-purpose url tftp://10.144.19.40/ password
    

    Then enable redundancy in both key servers.

    Primary Key Server Configuration

    crypto gdoi group GROUP-VPN
    server local
    redundancy
    local priority 4
    peer address ipv4 192.1.1.3
    

    Secondary Key Server Configuration

    crypto gdoi group GROUP-VPN
    identity number 65000
    server local
    rekey retransmit 10 number 2
    rekey authentication mypubkey rsa GDOI-REKEY
    rekey transport unicast
    sa ipsec 10
    profile gdoi1
    match address ipv4 ACL_GDOI_SA
    no replay
    address ipv4 192.1.1.3
    redundancy
    local priority 3
    peer address ipv4 192.1.1.2

    Group Member Configuration

    IPsec transform-sets and profile configurations are not required as they are part of the negotiation with the key server when establishing the GDOI session. Only ISAKMP configurations are required to be defined to allow the group member and the key server to authenticate each other.

    crypto isakmp policy 10
    encr 3des
    group 2
    authen pre-share
    lifetime 86400
    

    Note

    For using preshared key authentication method, preshared keys are needed in each group member only to authenticate the key server. It is not required to define preshared keys to authenticate other group members.

    crypto keyring gdoi1
    pre-shared-key address 0.0.0.0 0.0.0.0 key example123
    

    The group member is defined with same identity and location of the key server. The clear df-bit was configured to reset df =1 to 0 to avoid fragmentation/MTU issues.

    crypto gdoi group GROUP-VPN
    identity number 65000
    server address ipv4 192.1.1.1
    !
    crypto ipsec df clear
    !
    

    Crypto map has a new type `gdoi’ and is tied to group member created above. !!!!

    crypto map map-GROUP-VPN 10 gdoi
    set group GROUP-VPN
    qos pre-classify
    

    GDOI is enabled by applying crypto map to outside physical interface. !!!!

    !
    interface GigabitEthernet0/0
    description outside interface to Provider Edge #2
    ip address 16.0.0.220 255.255.255.0
    ip pim sparse-dense-mode
    duplex auto
    speed auto
    crypto map map-GROUP-VPN
    

    Limitations of GETVPN – Suggested troubleshooting

    • An additional device is needed to function as the key server. For a 2000 branch network, in this example we recommend 4 key servers, two in data center 1 and two in the second data center.
    • Not suitable for public-Internet-based deployment due to the preservation of source and destination addresses.
    • If a group member has to be removed from a group, two steps must be taken. First, the authentication credentials of the group member need to be deleted. Second, the IPsec and rekey policy must be deleted, which causes all of the group members to re-register.
    • Default redundancy timers are high and the detection of primary key server failure can take as long as 18 minutes. However, you can reduce the values for those timers using manual configuration.
    • If a group member cannot successfully register with the key server, the group member may transmit all data traffic in clear text.
    • If the group member did not receive rekeys and further registration fails, data traffic protected by the policy will also be dropped. The workaround is to do “clear crypto gdoi” in the group member for re-registration.

      Leave a Response


      Warning: Cannot assign an empty string to a string offset in /srv/users/serverpilot/apps/vpnreviews-online-syd/public/wp-includes/class.wp-scripts.php on line 492

      Warning: Cannot assign an empty string to a string offset in /srv/users/serverpilot/apps/vpnreviews-online-syd/public/wp-includes/class.wp-scripts.php on line 492