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.
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:
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).
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.
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.
Router_A and Router_B build an EIGRP adjacency across the GRE tunnel and begin to exchange routing updates with one another.
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.
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.