Advanced Services. IPSec Configuration on IOS Platforms

Transcription

1 Advanced Services on IOS Platforms Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA USA Tel: NETS (6387) Fax:

2 Legal Notice THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS DOCUMENT ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB s public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iphone, iquick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries. All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. Copyright 2009 Cisco Systems, Inc. All rights reserved. 2

3 Contents Contents Contents 3 Tables 4 Introduction 5 Preface 5 Scope 5 Assumptions 5 6 ISAKMP Policy 6 ISAKMP Dead Peer Detection 6 IPSec Policy 7 Site-to-Site IPSec Tunnel Configuration with Pre-shared Key Authentication 7 Remote Access 8 Site-to-Site IPSec Tunnel Configuration with IVRF/FVRF and Pre-shared Key Authentication 10 Remote Access IPSec with VRF Configuration 11 ISAKMP Authentication Using Digital Certificates 13 IPSec HA Configuration 14 3

4 Tables Table 1 - IPSec Policy 7 4

5 Introduction Preface Scope This document addresses the most common IPSec configurations on Cisco IOS platforms. The scope of this document will cover IPSec Stateless HA, Site-to-Site and Remote Access Configurations with and without VRF's. Assumptions All the tests in the lab have been performed on the 7200 platforms with the c7200padvipservicesk9-mz t1.bin IOS image. 5

6 ISAKMP Policy The ISAKMP policy controls the parameters ISAKMP uses to control things like encryption type for ISAKMP communication, authentication method, hashing algorithm, and Diffie-Hellman group used for calculating initial keys. The encryption algorithm used for ISAKMP is mostly based on the IPSec SA (usually AES 256). The hashing algorithm sets the security level for the authentication on a per-packet basis, making sure that packets are not changed or spoofed. This should be the same as the IPSec SA. It is recommended to use the more-secure 160-bit hash function SHA. The Diffie-Hellman group sets the level of strength for the Diffie-Hellman calculation. Group 5 is preferred in environments using AES as the encryption method. DH Group 5 specifies the 1536-bit Diffie-Hellman group, which is a method of establishing a shared key over an insecure medium. Diffie-Hellman is used within IKE to establish session keys. IKE provides authentication of the IPSec peers, negotiates IPSec security associations, and establishes IPSec keys. Group 5 should be used for site-to-site tunnels and group 2 for remote access connections. VPN Client software supports only group 2 with AES 256 encryption. Diffie-Hellman group 2 uses 1024-bit keys. It is less secure than Group 5 but is the only supported DH group with AES 256 encryption for VPN clients. By default the ISAKMP lifetime is set to one day or 86,400 seconds. In many cases lowering this time to 8 hours or 28,800 seconds is preferred. It is recommended not to change the IPSec SA default lifetime of 3600 seconds. ISAKMP Dead Peer Detection Dead Peer Detection (DPD) is a mechanism used to detect dead IPSec peers. IPSec is a peer-to-peer type of technology. It is possible that IP connectivity may be lost between peers due to routing problems, peer reloading, or some other situation. This lost connectivity can result in black holes where traffic is lost. DPD, based on a traffic-detection method, is one possible mechanism to remedy this situation. DPD supports two options: on-demand or periodic. The on-demand approach is the default. With ondemand DPD, messages are sent on the basis of traffic patterns. For example, if a router must send outbound traffic and the liveliness of the peer is questionable, the router sends a DPD message to query the status of the peer. If a router has no traffic to send, it never sends a DPD message. If a peer is dead, and the router never has any traffic to send to the peer, the router will not find out until the IKE or IPSec security association has to be rekeyed (the liveliness of the peer is unimportant if the router is not trying to communicate with the peer). On the other hand, if the router has traffic to send to the peer, and the peer does not respond, the router initiates a DPD message to determine the state of the peer. After 5 notacknowledged DPD requests the router declares the peer dead. With the periodic option, you can configure your router so that DPD messages are "forced" at regular intervals. This forced approach results in earlier detection of dead peers. For example, if a router has no traffic to send, a DPD message is still sent at regular intervals, and if a peer is dead, the router does not have to wait until the IKE SA times out to find out.

7 The DPD on-demand option is preferred as it is less resource intensive. You can configure DPD's ondemand option on both tunnel ends with the following command: crypto isakmp keepalive 10 The DPD timer is set to 10 seconds and the router sends a DPD Request every 10 seconds (unless the router receives one from the peer). If DPD Acknowledgement does not get received from the peer. the router uses a default retry timer of two seconds and starts sending DPD Requests at this interval. After the 5th notacknowledged DPD Request the peer is declared dead. IPSec Policy The IPSec policy protects data sent through the network. The transform set controls the encryption method that protects the tunnel. It also controls which authentication hash is used for the packets, if any. It is recommended to use strong encryption with ESP-AES 256 and for the authentication algorithm AH- SHA-HMAC. The following IPSEC policy should be used: Table 1 - IPSec Policy Proposal Definition Authentication algorithm AH-SHA-HMAC Encryption algorithm ESP-AES 256 Encapsulation mode Tunnel mode Lifetime measurement Time Time lifetime 3600s (1 hours) The IPSec SA lifetime of 3600 seconds or 1 hour as the Tunnel mode are the default values and don't require to be explicitly configured. Site-to-Site IPSec Tunnel Configuration with Pre-shared Key Authentication Perform the following steps to setup a site-to-site tunnel. Step 1 Define the ISAKMP policy for a site-to-site tunnel. crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 lifetime Step 2 Define the pre-shared key for a peer. crypto isakmp key pre-shared-key address a.a.a.a10 Step 3 Enable on-demand DPDs. crypto isakmp keepalive 10 7

8 Step 4 Define the IPSec transform set. crypto ipsec transform-set aes-sha esp-aes 256 esp-sha-hmac Step 5 Enable fragmentation before encryption globally.!this command is enabled globally by default and does not have to be explicitly configured. crypto ipsec fragmentation before-encryption!clearing the DF bit in the packet will allow the fragmentation to occur regardless of fact if the initial packet had it set or not. crypto ipsec df-bit clear Step 6 Define the crypto access list. access-list cust-acl permit ip local-proxy remote-proxy Step 7 Define the crypto map. crypto map vpn 10 ipsec-isakmp set peer a.a.a.a10 set transform-set aes-sha match address cust-acl Step 8 Apply the crypto map. interface GigabitEthernetX/Y ip address c.c.c.c !Define mtu size depending on physical connection in production network. ip mtu 1440 duplex full speed 100 media-type rj45 crypto map vpn Step 9 Insure that traffic for remote proxy is routed out via the interface with a crypto map applied. ip route remote-proxy GigabitEthernetX/Y Remote Access The following configuration steps define how to enable remote access for a customer. VPN clients are authenticated against the LOCAL database and the group authorization should be performed locally. Step 1 Define user authentication and group authorization. aaa authentication login default none aaa authentication login vpnclients local aaa authorization network vpnclients local Step 2 Define the local pool for VPN clients. ip local pool cust-xx-pool start-ip-address end-ip-address 8

9 Step 3 Define the ISAKMP policy for remote access. crypto isakmp policy 20 encr aes 256 authentication pre-share group 2 lifetime SHA is the default value for hash functions. Step 4 Define a split-tunneling list to define to what the VPN clients will access over an IPSec tunnel. access-list cust-client-xx-acl permit ip client-xx-servers any Step 5 Define the VPN clients group. crypto isakmp client configuration group cust-xx-group key pre-shared-key pool cust-xx-pool acl cust-client-xx-acl Step 6 Define the ISAKMP profile for VPN clients. crypto isakmp profile cust-xx-client-profile match identity group cust-xx-group client authentication list vpnclients isakmp authorization list vpnclients client configuration address respond Step 7 The IPSec transform set should be the same as for site-to-site tunnels. crypto ipsec transform-set aes-sha esp-aes 256 esp-sha-hmac Step 8 Configure a dynamic crypto map for remote access. crypto dynamic-map cust-xx-dyn 10 set transform-set aes-sha set isakmp-profile cust-xx-client-profile reverse-route Step 9 Add a new crypto map entry for remote access to the customer crypto map. crypto map vpn-cust-xx 200 ipsec-isakmp dynamic cust-xx-dyn Reverse Route Injection is enabled in Step 8. This creates the static /32 route for a VPN client assigned IP address in the global routing table. The next hop of this route is the PC's real IP address. This static route could be redistributed into dynamic routing protocols used inside the customer network to provide full connectivity on Layer 3. 9

10 Site-to-Site IPSec Tunnel Configuration with IVRF/FVRF and Pre-shared Key Authentication The following steps setup site-to-site tunnels with inside and front VRF and pre-shared key authentication. Step 1 Define the customer dedicated VRFs. ip vrf cust-xx-ivrf rd 64512:2000 route-target export 64512:2000 ip vrf cust-xx-fvrf rd 64513:2001 route-target export 64513:2001 Step 2 Define the pre-shared key for a tunnel. crypto keyring cust-xx-key vrf cust-xx-fvrf pre-shared-key address ip-address key key-string Step 3 Define ISAKMP policy for all site-to-site tunnels. crypto isakmp policy 10 encr aes 256 authentication pre-share group 5 lifetime SHA is the default value for hash functions. Step 4 Enable on-demand DPDs. This should be done only once and is applied to all site-to-site tunnels. crypto isakmp keepalive 10 Step 5 Define the customer ISAKMP profile. crypto isakmp profile cust-xx-profile vrf cust-xx-ivrf keyring cust-xx-key match identity address ip-address cust-xx-fvrf Step 6 Define the IPSec policy to use for all IPSec tunnels. crypto ipsec transform-set aes-sha esp-aes 256 esp-sha-hmac Step 7 Enable fragmentation before encryption globally.!this command is enabled globally by default and doesn't have to be explicitly configured. crypto ipsec fragmentation before-encryption!clearing the DF bit in the packet will allow the fragmentation to occur regardless of fact if the initial packet had it set or not. crypto ipsec df-bit clear 10

11 Step 8 Define a crypto access list. access-list cust-xx-acl permit ip local-proxy remote-proxy Step 9 Define the crypto map for a customer. crypto map vpn-cust-xx 10 ipsec-isakmp set peer ip-address set transform-set aes-sha set isakmp-profile cust-xx-profile match address cust-xx-acl reverse-route static Step 10 Apply the crypto map to an interface. interface GigabitEthernetX/Y ip vrf forwarding cust-xx-fvrf!define mtu size depending on physical connection in production network. ip mtu 1440 ip address a.a.a.a crypto map vpn-cust-xx Reverse Route Injection is enabled in Step 9 with a static option. This creates a static route for the remoteproxy subnet in the VRF cust-xx-ivrf routing table immediately after configuration. This static route could be redistributed into dynamic routing protocols inside the customer network to provide full connectivity at Layer 3. Remote Access IPSec with VRF Configuration The following configuration steps define how to enable remote access for a customer. VPN clients are authenticated against centralized TACACS servers residing in dedicated VRFs. VPN clients access services in another specific VRF cust-xx-vrf. Step 1 Define the VRF in which the TACACS server resides. ip vrf vrf rd 64511:2001 route-target export 64511:2001 ip vrf cust-xx-vrf rd 64512:2000 route-target export 64512:2000 Step 2 Define the AAA server group with the TACACS server. aaa new-model aaa group server tacacs+ tac-group server-private tacacs_srv_ip_address key key_value ip vrf forwarding vrf 11

12 Step 3 Define user authentication and group authorization. aaa authentication login default none aaa authentication login vpnclients group tac-group aaa authorization network vpnclients local Step 4 Define a local pool for VPN clients. ip local pool cust-xx-pool start-ip-address end-ip-address Step 5 Define ISAKMP policy for remote access. crypto isakmp policy 20 encr aes 256 authentication pre-share group 2 lifetime SHA is the default value for hash functions. Step 5 Define a split-tunneling list to define to what the VPN clients will access over an IPSec tunnel. access-list cust-client-xx-acl permit ip client-xx-servers any Step 6 Define a VPN clients group. crypto isakmp client configuration group cust-xx-group key pre-shared-key pool cust-xx-pool acl cust-client-xx-acl Step 7 Define an ISAKMP profile for VPN clients. crypto isakmp profile cust-xx-client-profile vrf cust-xx-vrf match identity group cust-xx-group client authentication list vpnclients isakmp authorization list vpnclients client configuration address respond Step 8 The IPSec transform set should be the same as for site-to-site tunnels. crypto ipsec transform-set aes-sha esp-aes 256 esp-sha-hmac Step 9 Configure a dynamic crypto map for remote access. crypto dynamic-map cust-xx-dyn 10 set transform-set aes-sha set isakmp-profile cust-xx-client-profile reverse-route Step 10 A new crypto map entry for remote access should be added to the customer crypto map. crypto map vpn-cust-xx 200 ipsec-isakmp dynamic cust-xx-dyn 12

13 Reverse Route Injection is enabled in Step 9. This creates the static /32 route for the VPN client assigned IP address in the VRF cust-xx-vrf routing table. The next hop of this route is the PC's real IP address. This static route could be redistributed into dynamic routing protocols used inside a customer s network to provide full connectivity at Layer 3. ISAKMP Authentication Using Digital Certificates 13 If IPSec peers use digital certificates for authentication, this chapter highlights the configuration changes that need to be implemented. The following configuration steps are required for CA enrollement: Step 1 Define the domain name on the router. ip domain-name cisco.com Step 2 Create an RSA key pair. crypto key generate rsa Step 3 Define the CA trustpoint. crypto pki trustpoint CA-name enrollment url revocation-check none Step 4 Retrieve the CA root certificate. crypto ca authenticate CA-name Step 5 Enroll with CA. crypto ca enroll CA-name Step 6 Verify with a show command show crypto ca certificate Ensure that both certificates were installed correclty and save them with the write memory command. ISAKMP policies on routers must be changed to reflect authentication with digital certificates.!isakmp Policy for Site-to-Site Tunnels crypto isakmp policy 10 authentication rsa-sig encryption aes-256 hash sha group 5 lifetime 28800!ISAKMP Policy for Remote Access crypto isakmp policy 20 authentication rsa-sig encryption aes-256 hash sha group 2 lifetime 28800

14 In the case of Remote Access OU field from certificate will need to match the configured VPN Clients groups on the routers and will be used as identity in the ISAKMP profile dedicated for Remote Access. In the case of Site-to-Site tunnels the certificate map will need to be configured to match the hostname from certificate: crypto pki certificate map cust-xx-cert-map 10 name co hostname-from-remote-router-certificate The ISAKMP profile will then need to be matched based on the certificate map as follows: crypto isakmp profile cust-xx-profile vrf cust-xx-vrf ca trust-point CA-name match certificate cust-xx-cert-map IPSec HA Configuration Hot Standby Routing Protocol (HSRP) is commonly used to provide failover between routers. HSRP tracks the state of router interfaces and provides a failover mechanism between primary and secondary devices. This functionality can be exploited to provide IPSec redundancy. HSRP has been coupled with RRI and IPSec to provide a stateless IPSec failover mechanism. The Reverse Route Injection (RRI) feature allows dynamic routing information updates during the HSRP and IPSec failover. With stateless IPSec HA in the case of primary router failure/interface failure the secondary router will resume using virtual IP address and becomes new tunnel headend device. Dead Peer Detection - DPD allows customer s spoke routers and VPN clients to detect failure of a router and to reconnect to the new active router. In this kind of implementation all customer s spoke routers and VPN clients connect to the HSRP virtual IP address. The following configuration enables IPSec HA: interface GigabitEthernetX/Y ip mtu 1440 ip address a.a.a.a standby x ip a.a.a.a10 standby x name ipsec-ha-x crypto map vpn-cust-xx redundancy ipsec-ha-x 14