CHAPTER 7 Implementing IPsec Site-to-Site VPNs

CHAPTER 7 Implementing IPsec Site-to-Site VPNs

1. Planning and Preparing an IPsec Site-to-Site VPN

   • IPsec can perform the following
     • Confidentiality
       • 3DES, IDEA, AES
     • Data integrity
       • MD5 / SHA / HMAC
     • Hiding the private address space from the Internet
       • Because IPsec’s Encapsulation Security Protocol (ESP) in tunnel mode encrypts and encapsulates the original packet, and then places a new IP header before forwarding the packet, the Internet sees only the packet as being from the global IP address of one router and destined to the global address of the second router.
     • Autentication
       • digital signatures
       • PSK
   • methods for encryption
     • Tunel
       • IP header and the payload are encrypted
     • Transport
       • only the packet payload is encrypted
   • Liberar ports para IPSec funcionar
     • UDP port 500 -IKEv1 Phase 1
     • UDP port 4500 - NAT
     • Layer 4 Protocol 50 - ESP
     • Layer 4 protocol 51 - AH
   • Planning IKEv1 Phase 1 - Parametros a serem usados na config
     • Hashing: SHA
     • Authentication: RSA-Sigs (which require PKI to be used)
     • DH group: 5
     • Lifetime: 3600 seconds
     • Encryption: AES-256
   • Planning IKEv1 Phase 2 - Parametros a serem usados na config
     • HMAC: SHA
     • Lifetime: Default
     • PFS: Group 2
     • Outside interfaces of routers
     • Encryption: AES-192
     • VPN Peer global IP addresses
     • Traffic to protect: Bidirectional traffic between local networks (R1 and R2 local)

2. Implementing and Verifying an IPsec Site-to-Site VPN in Cisco IOS Devices

   • 1 - config NTP (deviso ao RSA)
     • In earlier chapters, we discussed important resources such as Network Time Protocol (NTP) and certificate authorities (CA). Because we chose to implement RSA-Signatures for this customer, we want to implement NTP as one of our first steps. This is because when exchanging certificates during IKEv1 Phase 1, if R1 thinks the year is 2040, and the certificate it just received from R2 is listed as being valid from 2012 through 2016, R1 will reject the certificate as not being valid, and IKEv1 Phase 1 will not end well. (If IKEv1 Phase 1 does not work, IKEv1 Phase 2 does not have a chance either.) So for this implementation, we use a service provider on the simulated Internet (in our customer’s topology) that will provide both NTP and CA services at the address of 3.3.3.3 (in the simulated Internet portion of the topology diagram).
     • show ntp status
     • show ntp association
       • We can check to see if the router has the NTP server configured with the ! 
   • 2 - Preparing for and Obtaining Digital Certificates
     • Our next task, in preparation for the IPsec, is to generate key pairs on R1 and R2, configure them to use a CA, have them authenticate the CA (get the root certificate), and then enroll with the CA (request their own identity certificates). The CA is at 3.3.3.3 and supports Simple Certificate Enrollment Protocol (SCEP). From R1 and R2, the process is the same, and the commands used for R1
     • ip domain name cisco.com
     • crypto key generate rsa general-keys modulus 1024
     • ! Specify the CA that you would like to use, and the URL to be used to ! reach that CA
       • R1(config)# crypto pki trustpoint CA R1(ca-trustpoint)# enrollment URL http://3.3.3.3
     • Request the root certificate through "authenticating" the CA
       • R1(config)# crypto pki authenticate CA
     • Request an Identity certificate for this router, via SCEP and the ! "enroll" option
       • R1(config)# crypto pki enroll CA
   • IKEv1 Phase 1 policy
     • ! Note, that a show running-config, would only show configured items in the ! policy if they were different from the default. Here is a snippet from ! the show run: crypto isakmp policy 1 encr aes 256 group 5 lifetime 3600
     • ! Because the authentication and hash are using the defaults, they are not ! shown even though we put them in the configuration. (interesting to know) ! We won't need a pre-shared key, because we are using digital signatures/ ! certificates for the IKEv1 Phase 1 authentication.
     • crypto isakmp policy 1
       • R1(config-isakmp)# encr aes 256 R1(config-isakmp)# group 5 R1(config-isakmp)# lifetime 3600 R1(config-isakmp)# authentication rsa-sig R1(config-isakmp)# hash sha
     • show crypto isakmp policy
   • IKEv1 Phase 2 policy
     • crypto ipsec transform-set MYSET esp-aes esp-sha-hmac
     • access-list 100 permit ip 172.16.0.0 0.0.255.255 192.168.0.0 0.0.0.255
     • crypto map MYMAP 1 ipsec-isakmp
       • R1(config-crypto-map)# match address 100 R1(config-crypto-map)# set peer 209.165.201.1 R1(config-crypto-map)# set transform-set MYSET R1(config-crypto-map)# set pfs group2
     • interface GigabitEthernet1/0
       • R1(config-if)# crypto map MYMAP
   • Troubleshooting IPsec Site-to-Site VPNs in Cisco IOS
     • verifies the IKEv1 Phase 1 policy
       • show crypto isakmp policy
     • shows virtually all of the rest of the ! config including the transform set and crypto ACLs involved, and where ! the crypto map is applied
       • show crypto map
     • Interesting Traffic to Trigger IPsec
       • ping 192.168.0.2 source g1/0
     • Debug Used for Troubleshooting IKEv1 Phase 1
       • debug crypto isakmp
     • see if ! there is an IKEv1 Phase 1 tunnel already in place
       • show crypto isakmp sa
     • Troubleshooting IKEv1 Phase 2, the IPsec Tunnel
       • show crypto map
     • To verify the IKEv1 Phase 1 and 2 tunnels
       • show crypto isakmp sa
         • QM_IDLE is the desired state
       • show crypto isakmp sa detail
     • verify the IPsec (IKEv1 Phase 2) tunnel
       • show crypto ipsec sa
     • view of the ! cryptography
       • show crypto engine connections active