Please enable JavaScript.
Coggle requires JavaScript to display documents.
:explode: Impmenet site-to-site IPsec VPNs :explode:, image, image, image,…
:explode:
Impmenet site-to-site IPsec VPN
s :explode:
Configure a Site-to-Site IPsec VPN
:star:
IPsec VPN Configuration Tasks
:star:
Security Policy Requirements
All XYZCORP VPNs should be implemented using the following security policy:
Encrypt traffic with AES 256 and SHA.
Authenticate with PSK.
Exchange keys with DH group 14.
ISAKMP tunnel lifetime is 1 hour.
IPsec tunnel uses ESP with a 15-minute lifetime.
Configuration Tasks:
The configuration tasks required to meet this policy are:
Task 1: Configure the ISAKMP Policy for IKE Phase 1
Task 2: Configure the IPsec Policy for IPsec Phase 2
Task 3: Configure a Crypto Map for the IPsec Policy
Task 4: Apply the IPsec Policy
Task 5: Verify that the IPsec Tunnel is Operational
Existing ACL Configurations
:star:
Although XYZCORP does not have an existing ACL configuration, this would not be the case in a production network. Perimeter routers typically implement a restrictive security policy, blocking all traffic except for traffic specifically allowed. Prior to implementing a site-to-site IPsec VPN, ensure that the existing ACLs do not block traffic necessary for IPsec negotiations. The ACL command syntax to permit ISAKMP, ESP, and AH traffic is shown here.
Site-to-Site IPsec VPN Topology
:star:
Implementing a site-to-site VPN requires configuring settings for both IKE Phase 1 and Phase 2. In the phase 1 configuration, the two sites are configured with the necessary ISAKMP security associations to ensure that an ISAKMP tunnel can be created. In the phase 2 configuration, the two sites are configured with the IPsec security associations to ensure that an IPsec tunnel is created within the ISAKMP tunnel. Both tunnels will be created only when interesting traffic is detected.
Handling Broadcast and Multicast Traffic
:star:
The XYZCORP topology uses static routing, so there is no multicast or broadcast traffic that needs to be routed through the tunnel. But what if XYZCORP decided to implement EIGRP or OSPF? These routing protocols use multicast addresses to exchange routing information with neighbors. IPsec only supports unicast traffic. To enable routing protocol traffic, the peers in a site-to-site IPsec VPN implementation would need to be configured with a Generic Routing Encapsulation (GRE) tunnel for the multicast traffic.
GRE supports multiprotocol tunneling, as shown in the figure. It can encapsulate multiple OSI Layer 3 protocol packet types inside an IP tunnel. Adding an additional GRE header between the payload and the tunneling IP header provides the multiprotocol functionality. GRE also supports IP multicast tunneling. Routing protocols that are used across the tunnel enable dynamic exchange of routing information in the virtual network. GRE does not provide encryption. GRE configuration is beyond the scope of this course
IIPsec Negotiation
:star:
In order for an IPsec VPN tunnel to become operational, IPsec negotiation must first occur. The IPsec negotiation process to establish a VPN involves five steps
IKE Phase 2 begins. The IPsec peers use the authenticated secure tunnel to negotiate the IPsec SA policy. The negotiation of the shared policy determines how the IPsec tunnel is established.
The IPsec tunnel is created, and data is transferred between the IPsec peers based on the IPsec SAs.
IKE Phase 1 begins. The peers negotiate the ISAKMP SA policy. When the peers agree on the policy and are authenticated, a secure tunnel is created.
The IPsec tunnel terminates when the IPsec SAs are manually deleted, or when their lifetime expires.
An Internet Security Association Key Management Protocol (ISAKMP) tunnel is initiated when host A sends “interesting” traffic to host B. Traffic is considered interesting when it travels between the peers and meets the criteria that are defined in an ACL
ISAKMP Policy
:checkered_flag:
Syntax to Configure a New ISAKMP Policy
:check:
To configure a new ISAKMP policy, use the crypto isakmp policy command, as shown in the figure. The only argument for the command is to set a priority for the policy (from 1 to 10000). Peers will attempt to negotiate using the policy with the lowest number (highest priority). Peers do not require matching priority numbers.
When in ISAKMP policy configuration mode, the SAs for the IKE Phase 1 tunnel can be configured. Use the mnemonic HAGLE to remember the five SAs to configure:
Hash
Authentication
Group
Lifetime
Encryption
ISAKMP Policy Configuration
:check:
To meet the security policy requirements for XYZCORP, configure the ISAKMP policy with the following SAs:
Hash is SHA
Authentication is pre-shared key
Group is 14
Lifetime is 3600 seconds
Encryption is AES
The Default ISAKMP Policies
:check:
The first task is to configure the ISAKMP policy for IKE Phase 1. The ISAKMP policy lists the SAs that the router is willing to use to establish the IKE Phase 1 tunnel. The Cisco IOS comes with default ISAKMP policies already in place. To view the default policies, enter the show crypto isakmp default policy command
Pre-Shared Key Configuration
:check:
The XYZCORP security policy requires that a pre-shared key be used for authentication between the peers. The administrator can either specify a host name or an IP address for the peer. The command syntax is shown below.
XYZCORP uses the key phrase cisco12345 and the IP address of the peer as shown in the examples after the figure
IPsec Policy
:fire:
Define Interesting Traffic
:explode:
Although the ISAKMP policy for the IKE Phase 1 tunnel is configured, the tunnel does not yet exist. This is verified with the show crypto isakmp sa command in the figure below. Interesting traffic must be detected before IKE Phase 1 negotiations can begin. For the XYXCORP site-to-site VPN, interesting traffic is any permitted communications between the Site 1 and Site 2 LANs.
To define interesting traffic, configure each router with an ACL to permit traffic from the local LAN to the remote LAN, as shown in the following examples for R1 and R2. The ACL will be used in the crypto map configuration to specify what traffic will trigger the start of IKE Phase 1.
Configure IPsec Transform Set
:explode:
The next step is to configure the set of encryption and hashing algorithms that will be used to transform the data sent through the IPsec tunnel. This is called the transform set. During IKE Phase 2 negotiations, the peers agree on the IPsec transform set to be used for protecting interesting traffic
:silhouette:
IPsec VPN
:car:
Send Interesting Traffic
Now that both the ISAKMP and IPsec policies are configured, and the crypto map is applied to the appropriate outbound interfaces, test the two tunnels by sending interesting traffic across the link.
The extended ping command syntax and results are shown below. The first ping failed because it takes a few milliseconds to establish the ISAKMP and IPsec tunnels.
:heavy_check_mark:
Verify the ISAKMP and IPsec Tunnels
Sending interesting traffic does not actually mean that the tunnels are established. R1 and R2 will route traffic between the two LANs even if the ISAKMP and IPsec policy configurations are wrong. To verify that tunnels have been established, use the show crypto isakmp sa and show crypto ipsec sa commands. In the output below, notice that the tunnel is active between the two peers, 172.30.2.1 and 172.30.2.2, and that they are using the R1-R2_MAP crypto map.
:star:
Crypto Map
:world_map:
Syntax to Configure a Crypto Map
Now that the interesting traffic is defined, and an IPsec transform set is configured, it is time to bind those configurations with the rest of the IPsec policy in a crypto map. The syntax to start a crypto map set is shown below. The sequence number is important when configuring multiple crypto map entries. XYZCORP will only need one crypto map entry to match traffic and account for the remaining SAs.
Router(config)# crypto map map-name seq-num { ipsec-isakmp | ipsec-manual }
The available configurations for a crypto map entry when you are in crypto map configuration mode are shown below. The map name is R1-R2_MAP, and the sequence number is 10.
:world_map:
Crypto Map Configuration
To finish the configuration to meet the IPsec security policy for XYZCORP, complete the following:
Step 1. Bind the ACL and the transform set to the map.
Step 2. Specify the peer’s IP address.
Step 3. Configure the DH group.
Step 4. Configure the IPsec tunnel lifetime.
The crypto map configurations for R1 and R2 are shown below.
Use the show crypto map command to verify the crypto map configuration, as shown below for R1. All the required SAs should be in place. Notice that the output shows that no interfaces are currently using the crypto map.
:world_map:
Apply and Verify the Crypto Map
To apply the crypto map, enter interface configuration mode for the outbound interface and configure the crypto map map-name command. Below is the configuration for XYZCORP. Notice the show crypto map output now displays that the Serial 0/0/0 interface is using the crypto map. R2 is configured with the same command on its Serial 0/0/0 interface.
