Chapter 4: Common IPsec VPN Issues

Cisco Press

1 2 3 4 5 6 7 8 9 Page 9
Page 9 of 9

Note - For more information on serialization delay and other common troubleshooting and design issues with VoIP, please refer to the following link on CCO:

Troubleshooting QoS Choppy Voice Issues: http://www.cisco.com/en/US/partner/tech/tk652/tk698/technologies_tech_note09186a00800f6cf8.shtml


The Effect of Recursive Routing on IPsec VPNs

Recursive routing commonly occurs when a router attempts to install a route over the same route that it is using to learn that route through a given RP. Because multicast updates inherent to most RP operations are unable to be crypto-switched, the effect of recursive routing is most commonly seen in the IPsec+GRE solution in which GRE is used to encapsulate RP traffic prior to IPsec (ESP or AH) encapsulation. We will explore a recursive routing situation in an IPsec+GRE scenario outlined in Figure 4-19.

Figure 4-19

Recursive Routing and IPsec+GRE Deployments

The following order of events describes the influence of the recursive routing scenario in the IPsec+GRE deployment illustrated in Figure 4-19:

  1. Router_A and Router_B look up the GRE tunnel destination interfaces in their routing tables in order to build the GRE tunnel. They both find routes installed in their routing table for the appropriate tunnel destination interfaces and build the GRE tunnel accordingly using the statically configured default route (Example 4-35, line 30).

  2. Router_A and Router_B are configured to encrypt all GRE traffic between each other using ESP. Therefore, all exchanges across the GRE tunnel will be kept confidential.

  3. Router_A and Router_B inject all directly connected routes in to their routing protocol, Enhanced Interior Gateway Routing Protocol (EIGRP) AS1 (Example 4-35, line 24). This includes the loopback192 interfaces and the GRE tunnel interfaces.

  4. Router_A and Router_B build an EIGRP adjacency across the GRE tunnel and begin to exchange routing updates with one another.

  5. Router_A and Router_B learn the static routes installed in step 1 recursively across the GRE tunnel via EIGRP 1, and attempt to install the routes in the routing table. EIGRP learns a more specific route to the GRE tunnel destination than the default used in step 1 above.

  6. Once Router_A and Router_B are instructed to learn each other's tunnel destinations of the GRE tunnel interface (rather than via the static default routes in step 1), they determine that the behavior is recursive, and clear the route from the routing table. This causes both the GRE tunnel and the EIGRP adjacency to go down.

When a recursive routing situation occurs in an IPsec+GRE scenario, IOS CLI will write messages to the console, indicating the failure. Other symptoms indicative of recursive routing failure include RP adjacency loss across the GRE tunnel, which are also written to the IOS CLI. Example 4-35 shows recursive routing configuration errors described in Figure 4-19 and steps 1-6 above. Symptoms of recursive routing in IPsec+GRE scenarios are shown in Example 4-36.

Example 4-35 Configuration Errors Leading to Recursive Routing (Topology in Figure 4-19)

1 interface Loopback192
2  ip address 192.168.1.1 255.255.255.255
3 !
4 interface Tunnel192
5  ip address 192.168.0.1 255.255.255.252
6  tunnel source Loopback192
7  tunnel destination 192.168.2.1
8 !
9 !
10 interface Serial1/0
11 ip address 200.0.0.1 255.255.255.252
12 encapsulation frame-relay
13 serial restart-delay 0
14 frame-relay interface-dlci 102
15 frame-relay lmi-type ansi
16 !
17 !
18 router eigrp 1
19 redistribute connected 
20 network 192.168.0.0
21 default-metric 1500 100 128 128 4700
22 no auto-summary
23 ip classless
24 ip route 0.0.0.0 0.0.0.0 200.0.0.2

Example 4-36 provides the diagnostic output on Router_A that confirms that the GRE tunnel and EIGRP adjacency failures are due to the recursive routing behavior described above. Lines 10 and 18 show the presence of the static route that was used to build the GRE tunnel prior to occurrence of recursive routing. However, line 18 of Example 4-36 shows that there is a recursively learned EIGRP route to the tunnel destination (192.168.2.1) over the tunnel interface itself (next hop of 192.168.0.2). Because this route is more specific than the default route, EIGRP installs it in the routing table, causing the tunnel to fail due to recursive routing (as confirmed in Example 4-36, lines 20 and 21). Once the tunnel fails, EIGRP tears down the adjacency, as illustrated in Example 4-36, line 22.

Example 4-36 Recursive Routing Symptoms and Diagnostic Output in Cisco IOS

1  Router_A#show ip route
2  Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
3     D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
4     N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
5     E1 - OSPF external type 1, E2 - OSPF external type 2
6     i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
7     ia - IS-IS inter area, * - candidate default, U - per-user static route
8     o - ODR, P - periodic downloaded static route
9
10 Gateway of last resort is 200.0.0.2 to network 0.0.0.0
11
12    200.0.0.0/30 is subnetted, 1 subnets
13 C    200.0.0.0 is directly connected, Ethernet0/0
14    192.168.0.0/30 is subnetted, 1 subnets
15 C    192.168.0.0 is directly connected, Tunnel192
16    192.168.1.0/32 is subnetted, 2 subnets
17 C    192.168.1.1 is directly connected, Loopback192
18 D    192.168.2.1 [90/297372416] via 192.168.0.2, 00:00:04, Tunnel192
18 S*  0.0.0.0/0 [1/0] via 200.0.0.2
19 Router_A#
20 *May 8 15:42:10.439: %TUN-5-RECURDOWN: Tunnel192 temporarily disabled due to recursive routing
21 *May 8 15:42:11.439: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel192, changed state to down
22 *May 8 15:42:11.447: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.0.2 (Tunnel192) is down: interface down

In order to prevent this behavior, the administrators of Router_A ensure that the route to the GRE tunnel destination is not learned over the GRE tunnel itself. This can be accomplished by excluding the routes used to establish the GRE tunnel from being redistributed in to EIGRP using either a route-map or distribute list. Example 4-37 provides an example of how to accomplish this using an EIGRP route-map.

Example 4-37 Controlling EIGRP Route Redistribution with Route-Maps and ACLs

access-list 1 deny  192.168.1.0
!     
route-map no-recursive permit 10
 match ip address 1

Example 4-38 provides an alternative to excluding routes from the EIGRP redistribution using a distribute list. In the context of this particular example, the configuration in Example 4-38 will accomplish the same task as the route-map configuration in Example 4-37.

Example 4-38 Controlling EIGRP Route Redistribution with Distribute Lists

router eigrp 1
 redistribute connected
 network 192.168.0.0
 default-metric 1500 100 128 128 4700
 distribute-list 1 in
 no auto-summary
!
access-list 1 deny  192.168.1.0
access-list 1 permit any

Example 4-39 shows an example of EIGRP and GRE tunnel reestablishment once the appropriate route-map and ACL combination have been applied to the EIGRP routing protocol process using the redistribute connected route-map [route-map-name] command.

Example 4-39 GRE Tunnel and EIGRP Adjacency Reestablishment when Excluding Redistribution of Recursively-Learned Routes Using Route-Maps and ACLs

router eigrp 1
 redistribute connected
 network 192.168.0.0
 default-metric 1500 100 128 128 4700
 no auto-summary
!     
crvpn-3600-a#conf t
Enter configuration commands, one per line. End with CNTL/Z.
crvpn-3600-a(config)#router eigrp 1
crvpn-3600-a(config-router)#redistribute connected route-map no-recursive
*May 8 16:27:44.191: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.0.2 (Tunnel192) is up: new adjacency

Summary

In this chapter, we've covered several different broader areas of common issues with IPsec VPN deployments. The first area of common IPsec VPN issues we discussed pertains to configuration of ISAKMP and IPsec themselves, including

  • IKE SA Proposal Mismatches

  • IKE Authentication Errors

  • IPsec SA Proposal Mismatches

  • Crypto ACL Mismatches

When IKE is used, an IKE Phase 1 SA must be established before any additional IPsec SA negotiation can occur. The first task that crypto endpoints must accomplish to build an IKE SA is agreement on IKE SA proposals. We've discussed IKE SA proposal mismatches in the context of each of the following attributes that must be agreed on for a successful IKE SA proposal match:

  • IKE Authentication Method (PSKs, RSA Encryption, or RSA Signatures)

  • IKE Encryption Cipher (DES, 3DES, AES)

  • IKE Hash Algorithm (MD5, SHA1)

  • Diffie-Hellman Group Modulous (1, 2, or 5)

  • IKE SA Lifetime (60-86400 seconds)

Once IKE SA proposals have been agreed upon, the IKE SA must be authenticated. In this chapter, we've explored common techniques for IKE SA proposal troubleshooting and IKE SA authentication troubleshooting with each of the three IKE SA authentication methods—IKE PSKs, RSA Encryption, and RSA Signatures. The methods presented in this chapter can be used to diagnose problems with IKE SA establishment and authentication and verify the existence of an IKE SA before proceeding to investigate potential issues with IPsec SA establishment.

Unless IPsec SAs are manually defined, an IKE SA must exist on the crypto endpoints before an IPsec SA can be established. Once an IKE SA has been confirmed to exist, measures should be taken to confirm that the two crypto endpoints have agreed on IPsec SA proposals. In this chapter, we've discussed techniques IPsec SA failures attributable to mismatches in each of the following attributes:

  • The IP addresses used for IPsec tunnel termination

  • The symmetric IPsec transforms to use on crypto-protected traffic after an IPsec SA has been negotiated

  • The scope of protected traffic in the crypto switching path

When each of the previous attributes match, an IPsec SA can be formed. Techniques for verifying IPsec SA establishment were provided above to confirm the existence of an IPsec SA and the details of IPsec SA proposal agreed upon by the two crypto endpoints.

In addition to discussion of thorough discussion of configuration issues with IPsec VPN deployments, we have also introduced and discussed various architectural issues with IPsec VPN deployments. Unlike configuration issues, architectural issues pertain to incompatibilities and common design challenges when integrating IPsec with different technologies commonly found in the larger system architecture. Architectural issues discussed in this chapter include:

  • IPsec in Firewalled Environments

  • IPsec in NAT Environments

  • IPsec and QoS Inconsistencies

  • IPsec and Fragmentation

  • IPsec+GRE and Recursive Routing

When deploying IPsec through a firewall, several intrinsic design challenges surface. First, the appropriate protocols need to be allowed to pass for the IPsec and ISAKMP traffic to pass through the firewall. Recall that, for an IKE SA to establish successfully, UDP 500 must be allowed through. Once an IPsec tunnel has been built over IKE, the appropriate IP protocol number must be allowed (IP Protocol 50 for ESP and IP Protocol 51 for AH) for encrypted traffic to pass through the firewall. In our discussion of IPsec, we have also discussed the effect of fragmentation and the critical role that IP Unreachables play in PMTUD when preventing IPsec fragmentation after encryption. Firewalls typically do not send IP Unreachables. Therefore, when IPsec is deployed in conjunction with firewalls, it is important to ensure that MTUs are appropriately sized for the IPsec tunnel via some method other than PMTUD.

One primary strength of IPsec as a VPN technology is assurance that data is not manipulated while in transit between two crypto endpoints. When a NAT device is introduced between two crypto endpoints, often parts of the packets in transit are manipulated—specifically the source IP address, destination IP address, source ports, and destination ports. This behavior causes many intrinsic incompatibilities between NAT and IPsec, including:

  • IPsec AH Keyed MIC Failures in NAT Environments

  • Inbound IPsec SA Selector Inconsistencies in NAT Environments

  • IKE Rekeying Failures in PAT Environments

  • Overlapping IPsec Security Policy Database Entries

  • IPsec Security Parameter Index Conflicts on NAT Devices

  • Embedded IP Address Translation Limitations

  • Unidirectional NAT Support

  • TCP and UDP Checksum Failures

IPsec introduces design challenges when deployed in conjunction with QoS. In this chapter, we've discussed how IPsec makes source and destination hash information opaque to intermediate notes that require that hash information to make Weighted-Fair Queueing decisions. We've also discussed how IPsec ubiquifies RSVP signaling information needed by intermediate notes to guarantee end-to-end QoS between to IP endpoints. IPsec incorporates protection against rollback attacks through incorporating an antireplay window. When QoS delays the transmission of encrypted packets outside of the antireplay window on the receiving host, the packet is dropped.

It is important to ensure that fragmentation in IPsec networks is facilitated before encryption takes place. This is because, when a decrypting IPsec endpoint receives a fragment chain, all of the fragments in the chain must be decrypted before the packet can be reassembled, an operation that is performed in the process-switched path. This behavior causes substantial performance and scalability considerations in IPsec VPN endpoints. Proper fragmentation is therefore a paramount design consideration to validate in an IPsec VPN deployment. In this chapter, we have provided several methods for ensuring that fragmentation in IPsec VPN deployments is executed properly, before encryption with IPsec.

The last architectural issue we have discussed in this chapter pertains to recursive routing in IPsec+GRE environments. Recall from our previous discussions that IPsec+GRE is a popular design choice, as it accommodates multicast traffic in the crypto switching path. Care must be taken when building GRE deployments that routes used to build the GRE tunnel are not then learned recursively over the GRE tunnel itself, resulting in the teardown of the GRE tunnel and the corresponding routing protocol adjacency formed over that tunnel.

In the following chapters, we will discuss resilient and highly available IPsec designs that build upon sound IPsec fundamentals introduced in this chapter and in previous chapters. When exploring each of the designs presented in subsequent chapters, it is important to consider each in the context of the common issues with IPsec VPN deployments presented in this chapter.

Copyright © 2007 Pearson Education. All rights reserved.

Related:

Copyright © 2007 IDG Communications, Inc.

1 2 3 4 5 6 7 8 9 Page 9
Page 9 of 9
The 10 most powerful companies in enterprise networking 2022