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.
Contents
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
- 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.
- 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.
- 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.
- 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.
- 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.
