Please enable JavaScript.
Coggle requires JavaScript to display documents.
Module 19: Implement Site-toSite Ipsec VPNs - Coggle Diagram
Module 19: Implement Site-toSite Ipsec VPNs
19.1 Configure a Site-to-Site IPsec VPN
19.1.1 IPsec Negotiation
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, which include IKE Phase 1 and Phase 2.
Step 1
Step 2
Step 3
Step 4
Step 5
19.1.2 Site-to-Site IPsec VPN Topology
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.
The topology in the figure for XYZCORP will be used in this section to demonstrate a site-to-site IPsec VPN implementation. Both routers are configured with IP addressing and static routing. An extended ping on R1 verifies that routing between the LANs is operational.
The interface and default routing configurations for R1 and R2 are shown in the example.
An extended ping on R1 verifies that routing between the LANs is operational, as shown in the example output.
19.1.3 IPsec VPN Configuration Tasks
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
19.1.4 Existing ACL Configurations
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.
The example below demonstrates an ACL configuration that allows the traffic necessary for IPsec negotiations. R2 would have a similar configuration.
19.1.5 Handling Broadcast and Multicast Traffic
XYZCORP's topology uses static routing, so no multicast or broadcast traffic needs to be routed through the tunnel. However, if XYZCORP implemented EIGRP or OSPF, these protocols use multicast addresses for routing information exchange. Since IPsec only supports unicast traffic, a GRE tunnel would be required for multicast traffic in a site-to-site IPsec VPN.
GRE supports multiprotocol tunneling, encapsulating multiple Layer 3 protocol types within an IP tunnel. It allows IP multicast tunneling and enables dynamic routing information exchange across the tunnel. GRE does not provide encryption, and its configuration is beyond the scope of this course.
Generic Routing Encapsulation
19.1.6 Check Your Understanding - Identify the IPsec Negotiation Steps
19.2 ISAKMP Policy
19.2.1 The Default ISAKMP Policies
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, as shown in the example after the figure.
R1 has eight default ISAKMP policies ranging from the most secure (policy 65507) to the least secure (policy 65514). If no other policy has been defined by the administrator, R1 will attempt to use the most secure default policy. If R2 has a matching policy, then R1 and R2 can successfully negotiate the IKE Phase 1 ISAKMP tunnel without any configuration by the administrator. Eight default policies allow for flexibility in the negotiations. If there is no agreement to use the most secure default policy, R1 will attempt to use the next most secure policy.
19.2.2 Syntax to Configure a New ISAKMP Policy
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
19.2.3 ISAKMP Policy Configuration
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 example shows the ISAKMP policy configuration. Use the show crypto isakmp policy command to verify the configuration. R2 has an equivalent configuration.
19.2.4 Pre-Shared Key Configuration
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
19.3 IPsec Policy
19.3.1 Define Interesting Traffic
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.
19.3.2 Configure IPsec Transform Set
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.
Configure a transform set using the crypto ipsec transform-set command, as shown here. First, specify a name for the transform set (R1-R2, in the example).
After the transform set is named, the encryption and hashing algorithm can be configured in either order. The examples show the tranform set configuration for R1 and R2.
19.4.1 Syntax to Configure a Crypto Map
19.4.1 Syntax to Configure a Crypto Map
Once the interesting traffic is defined and an IPsec transform set is configured, the next step is to bind these configurations in a crypto map. The sequence number is important when configuring multiple entries. XYZCORP will only need one crypto map entry to match traffic and handle the remaining Security Associations (SAs). The use of the ipsec-manual option is beyond the scope of this course.
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.
19.4.2 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.
19.4.3 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.
19.5 IPsec VPN
19.5.1 Send Interesting Traffic
After configuring both ISAKMP and IPsec policies and applying the crypto map to the outbound interfaces, test the tunnels by sending interesting traffic. Traffic from R1’s LAN interface to R2’s LAN interface is considered interesting, as it matches the ACLs on both routers. An extended ping from R1 will test the VPN configuration. The first ping may fail due to the time it takes to establish the ISAKMP and IPsec tunnels.
19.5.2 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.
19.5.4 Video - Site-to-Site IPsec VPN Configuration
The Site-to-Site IPsec VPN Configuration video typically covers the following key points:
Overview of Site-to-Site IPsec VPN: It explains the concept of connecting two remote sites securely using IPsec, a protocol that provides encryption, integrity, and authentication.
IPsec Components: The video highlights the components needed for configuring a Site-to-Site VPN, such as ISAKMP (Internet Security Association and Key Management Protocol) for establishing the secure connection and the IPsec transform set for defining how data will be encrypted.
Configuration Steps:
Defining Interesting Traffic: Identify which traffic needs to be encrypted (based on ACLs).
Setting Up ISAKMP Policy: Configure the ISAKMP policy for negotiating parameters like encryption, hashing, and authentication.
IPsec Policy Setup: Configure IPsec transform sets to define the encryption and integrity algorithms.
Crypto Map Configuration: Bind the ISAKMP and IPsec policies to the crypto map, specifying which interfaces will use the VPN.
Apply Crypto Map: Apply the crypto map to the relevant interfaces on the routers to enable VPN traffic.
Testing the VPN: Perform tests (like extended pings) to ensure the VPN is working correctly, ensuring that traffic is securely routed between the two sites.
Troubleshooting: The video might also touch on troubleshooting tips for identifying and resolving issues during the configuration process.
