Chapter 2, “IPSec Overview,” described the IPSec architecture and the basic building blocks necessary to create a VPN. In this chapter, you will read about advanced IPSec features that will both improve the scalability and fault tolerance of IPSec VPNs and mitigate some of its inherent limitations. The base topology shown in Figure 3-1 will be used to explain the advanced IPSec features in this chapter.
IPSec is a peer-to-peer type of technology; IP reachability between IPSec peers is required for an IPSec session to be established between them. It is possible that IP connectivity may be lost between the peers due to routing problems, peer reloading, or some other situation. In such cases, there is often no way for IKE and IPSec to identify the loss of peer connectivity. The IPSec control plane protocol (IKE) is based on UDP and is, therefore, inherently connectionless; the IKE and IPSec security associations (SAs) established between the peers can remain until their lifetimes naturally expire. This lack of IPSec session liveliness creates “black holes” where traffic is lost. It is highly desirable to recognize these “black holes” as soon as possible, primarily because the IPSec SAs consume expensive CPU cycles when one side of the session continues to encrypt traffic to its unreachable peer. Also, the lack of failure detection of a peer may prevent the activation of an alternate backup peer. Finally, when reachability to the peer is restored, the peer may have no IKE or IPSec SAs, and the encrypted packets destined to the peer will be dropped by the peer, as it has no valid SA. Hence, the old IKE and IPSec SAs that are still present are really invalid and may preclude the creation of new IPSec SAs.
A keepalive mechanism, wherein the peers exchange some type of message to inform each other that they are alive, will help resolve these issues. Interestingly enough, the IKE protocol specification has no notion of such a keepalive mechanism. Cisco IOS allows the configuration of an IKE periodic keepalive mechanism that can be configured between IOS IPSec peers. Example 3-1 shows the configuration of an IKE keepalive in IOS from SPOKE-1-EAST’s standpoint.
Example 3-1. IKE Keepalive Configuration on SPOKE-1-EAST
spoke-1-east crypto isakmp policy 1 authentication pre-share ! crypto isakmp key cisco address 9.1.1.35 crypto isakmp key Cisco address 9.1.1.36 crypto isakmp keepalive 60 3
IKE keepalive messages are exchanged periodically by each peer to declare their availability. If three consecutive keepalive messages are unacknowledged, the associated peer is unreachable and the associated SAs should be removed and an IPSec tunnel built to a backup peer if one is present. In the above example, keepalives are sent every 60 seconds and the retry is a default value of 3, which means that it will take 180 seconds (60 times 3) to declare the IPSec endpoint dead. IKE keepalives are encrypted and authenticated, just like other IKE IPSec packets.
Note
The IKE keepalive mechanism has its limitations. The mechanism is able to detect the status of only the IKE SAs and endpoints. However, there may be cases in which the IKE peer is reachable, but its protected networks behind the peer are not. In that case, IKE keepalives do not help.
The IKE keepalive mechanism works fine to detect dead IKE peers and prevent “black holes” and conserve expensive CPU resources; however, one of the limitations of the IKE keepalive mechanism is its scalability. An IPSec router that is terminating a few thousand site-to-site IPSec sessions with IKE keepalives turned on will consume expensive CPU cycles for the housekeeping of the IKE keepalive messages, thereby limiting the scalability of the number of IPSec sessions that can be terminated by this router. An alternative mechanism to the IKE keepalive is known as Dead Peer Detection (DPD), discussed in the next section.
Dead peer detection (DPD), defined in RFC 3706, is an alternative mechanism that is more scalable than the IKE keepalives in detecting dead IPSec peers. Unlike the keepalive mechanism, DPD does not send periodic messages to check liveliness of a peer. The fundamental premise behind DPD is that DPD is a traffic-based detection method. In other words, DPD specifies that when traffic is occurring between the peers; there is no need to send a keepalive to check for liveliness of the peer, as the IPSec traffic serves as implicit proof of the availability of the peer.
If, on the other hand, a period of time elapses during which no traffic is exchanged between the peers, the liveliness of each peer is questionable. Note also that liveliness of a peer is needed only if traffic is to be sent to the peer. For example, if SPOKE-1-EAST in Figure 3-1 has sent outbound IPSec packets towards the VPN-GW1-EAST and has not received any IPSec packets inbound from VPN-GW1-EAST for a period of idle time, you might expect that SPOKE-1-EAST will initiate a DPD exchange. However, if SPOKE-1-EAST does not have data traffic to send to VPN-GW1-EAST, it really does not need to know if it is alive.
By delaying the DPD exchange (which, when sent, is sent in parallel with the start of the data traffic), DPD avoids sending extra messages and allows more time for an intermediate network outage to recover. After all, if the intermediate network is not needed at a given time, why detect that it is currently down? Doing so might force IPSec re-keying before it is necessary.
DPD capability is negotiated between IPSec peers during IKE negotiation by using a DPD vendor ID, as shown in Figure 3-2.
The DPD vendor ID is 16 bytes long. The first 14 bytes are the HASHED_VENDOR_ID field, and take the value HASHED_VENDOR_ID = {0xAF, 0xCA, 0xD7, 0x13, 0x68, 0xA1, 0xF1, 0xC9, 0x6B, 0x86, 0x96, 0xFC, 0x77, 0x57}. Even though this field is called HASHED_VENDOR_ID, the value of that this field is fixed, so it is not really vendor-specific. The last two bytes represent the current major (MJR) and minor (MNR) version of the protocol. An IKE peer must send the vendor ID if it wishes to take part in DPD exchanges.
Figure 3-3 shows the bidirectional DPD message exchange between the initiator and the responder, which means that for an R_U_THERE message, there should be a corresponding ACK.
The DPD message format is shown in Figure 3-4.
The protocol ID is set to 500 for ISAKMP, and the SPI length should be set to 16, which is equal to the length of the ISAKMP cookies—which, as we know from Chapter 2, “IPSec Overview,” serves as the SPI for IKE/ISAKMP. Table 3-1 lists the ISAKMP Notify message types.
Example 3-2 shows the DPD configuration on SPOKE-1-EAST. The configuration is essentially the same as the IKE keepalive configuration, except that two more timer parameters are provided to configure idle interval and retransmit interval.
Example 3-2. DPD Configuration
spoke-1-east version 12.2 service log backtrace service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname spoke-1-east ! enable password lab ! clock timezone EST 0 ip subnet-zero ! ! ip domain name cisco.com ! ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.35 crypto isakmp key Cisco address 9.1.1.36 crypto isakmp keepalive 60 2 ! ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto map vpn 1 ipsec-isakmp set peer 9.1.1.35 set peer 9.1.1.36 set transform-set test match address 100 ! interface Serial0/0 ip address 9.1.1.146 255.255.255.252 crypto map vpn ! interface Ethernet0/1 ip address 10.0.68.1 255.255.255.0 half-duplex ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.145 ! access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255 ! ! line con 0 line aux 0 line vty 0 4 password lab login ! ! end spoke-1-east# spoke-1-east#show cry isa sa det Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal X - IKE Extended Authentication Conn id Local Remote Encr Hash Auth DH Lifetime Capabilities 1 9.1.1.146 9.1.1.35 des sha psk 1 23:59:39 D spoke-1-east# debug crypto isakmp ISAKMP (0:1): purging node 942371640 ISAKMP: received ke message (4/1) ISAKMP: DPD received kei with flags 0x8 ISAKMP (0:1): more than 60 seconds since last inbound data. Sending DPD. ISAKMP (0:1): DPD Sequence number 0x17815542 ISAKMP: set new node -1912932512 to QM_IDLE ISAKMP (0:1): sending packet to 9.1.1.35 my_port 500 peer_port 500 (I) QM_IDLE ISAKMP (0:1): purging node -1912932512 ISAKMP (0:1): received packet from 9.1.1.35 dport 500 sport 500 (I) QM_IDLE ISAKMP: set new node -1385918665 to QM_IDLE ISAKMP (0:1): processing HASH payload. message ID = -1385918665 ISAKMP (0:1): processing NOTIFY R_U_THERE_ACK protocol 1 spi 0, message ID = -1385918665, sa = 82CFB8F8 ISAKMP (0:1): DPD/R_U_THERE_ACK received from peer 9.1.1.35, sequence 0x17815542 ISAKMP (0:1): deleting node -1385918665 error FALSE reason "informational (in) state 1" ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY ISAKMP (0:1): Old State = IKE_P1_COMPLETE New State = IKE_P1_COMPLETE
The idle interval timer facilitates the fault detection and recovery of idle resources in the absence of a valid connection. Idle interval is the configured time wherein the peer (SPOKE-1-EAST) has not received any inbound data on its SA from the remote peer (VPN-GW1-EAST). As you can see from the debugs in Example 3-2, once the interval is hit, an R_U_THERE_MESSAGE is sent and the initiator expects an ACK back. If the ACK is not received, the R_U_THERE message will be retransmitted three times, depending on the retransmit interval, before the initiator declares the remote peer dead. In the case of Example 3-2, you can see that R_U_THERE_ACK was received from VPN-GW1-EAST.
Note
Note that two conditions have to be met before a DPD R_U_THERE_MESSAGE is sent. First, the idle timer must expire, and second, the router has to have data going out to the peer. If the second condition is not met, the message is not sent. This policy conserves resources.
The lack of data or a response from the remote peer (VPN-GW1-EAST) will cause the local peer (SPOKE-1-EAST) to clear the local IPSec connection and recover the security association resources assigned. After clearing the resources, it may attempt to reestablish a connection with the same peer or with an alternate peer (VPN-GW2-EAST).
The characteristics of dead peer detection make the protocol a much more scalable fault-detection mechanism than IKE keepalives, especially in the context of addressing the state of IPSec connections to thousands of remote peers. The detection of an invalid IPSec security association may occur quickly by setting the idle interval and retry interval to a fairly low value with relatively few retries. The key advantage to DPD is that the periodic polling that is seen in IKE keepalives is suppressed in DPD, saving system resources.
Note
If one of peers supports only the original IKE keepalive mechanism while the other peer supports the DPD mechanism, the peer running DPD will fall back to the traditional periodic ISAKMP keepalive method. It is important to note that there are cases in which periodic IKE keepalives are necessary. These cases occur when there is Network Address Translation (NAT) or a firewall between the two peers. In such cases, periodic keepalives are required to refresh the state entries on the NAT or the firewall box. In the section “NAT Traversal (NAT-T),” which appears later in this chapter, you will examine a feature known as NAT Traversal. NAT Traversal has a NAT keepalive mechanism that negates the need for periodic IKE keepalive messages for maintaining state information on the NAT or firewall box.
Both IKE keepalives and DPD are useful mechanisms, but each has its limitations. For instance, they only detect if the IKE SAs and the endpoints are alive. They are useful if the path between the IKE peer fails for some reason, and the peer endpoints are not reachable from one another. On the other hand, if the IKE endpoints are reachable but the protected networks behind the endpoints are not, then these mechanisms cannot prevent the black-holing of traffic after it reaches the IKE endpoint.
When an IOS router creates an IPSec SA for a peer, it allocates a certain amount of resources to maintain the SA; the SA requires both memory and several managed timers. For idle peers, these resources are wasteful and consume expensive resources. Furthermore, these wasted resources could eventually prevent the router from creating new SAs with other active peers. The solution to this problem is to monitor the SAs for activity, removing idle SAs after a specified period of inactivity. The configuration of the SA idle timeout is shown in Example 3-3 along with the debug output.
Example 3-3. Idle Timeout Configuration
vpn-gw1-east version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname vpn-gw1-east ! logging queue-limit 100 ! ip subnet-zero ! ip domain name cisco.com ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.146 ! crypto ipsec security-association idle-time 120 ! crypto ipsec transform-set test esp-3des esp-sha-hmac crypto map vpn 1 ipsec-isakmp set peer 9.1.1.33 set transform-set test match address 100 ! ! ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 speed 100 full-duplex no cdp enable crypto map vpn ! interface FastEthernet0/1 ip address 10.1.1.2 255.255.255.0 speed 100 full-duplex no cdp enable ! router ospf 1 log-adjacency-changes network 10.1.1.0 0.0.0.255 area 0 redistribute static ! ip http server no ip http secure-server ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 ! ! ! access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255 ! line con 0 line aux 0 line vty 0 4 login ! ! end vpn-gw1-east#show cry isa sa Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal X - IKE Extended Authentication psk - Preshared key, rsig - RSA signature renc - RSA encryption Conn id Local Remote Encr Hash Auth DH Lifetime Capabilities 1 9.1.1.35 9.1.1.146 des sha psk 1 23:59:20 vpn-gw1-east# debug crypto ipsec ipsec(create_sa): starting idle timer, 120 seconds ISAKMP: Created a peer struct for 9.1.1.146, peer port 500 ISAKMP: Locking peer struct 0x82A461D8, ipsec refcount 1 for from create_transfor ipsecipsecipsec(delete_sa): deleting SA, (sa) sa_dest= 9.1.1.35, sa_prot= 50, sa_spi= 0x2CA9A57F(749315455), sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2000 ipsec(delete_sa): deleting SA, (sa) sa_dest= 9.1.1.146, sa_prot= 50, sa_spi= 0x7F4A6D6C(2135584108), sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2001 ipsec(lifetime_expiry): SA idletime reached; deleting ipsec SA ipsec(lifetime_expiry): notifying END_TUNNEL local: 9.1.1.35 / ivrf: 0 remote: 9.1.1.146 / fvrf: 0 / peer port: 500 spoke-1-east# debug crypto ipsec ISAKMP (0:1): received packet from 9.1.1.35 dport 500 sport 500 (I) QM_IDLE ISAKMP: set new node -329991077 to QM_IDLE ISAKMP (0:1): processing HASH payload. message ID = -329991077 ISAKMP (0:1): processing DELETE payload. message ID = -329991077 ipsec(key_engine): got a queue event... ipsec(key_engine_delete_sas): rec'd delete notify from ISAKMP ipsec(key_engine_delete_sas): delete SA with spi 749315455/50 for 9.1.1.35 ipsec(delete_sa): deleting SA, (sa) sa_dest= 9.1.1.146, sa_prot= 50, sa_spi= 0x7F4A6D6C(2135584108), sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2000 ipsec(delete_sa): deleting SA, (sa) sa_dest= 9.1.1.35, sa_prot= 50, sa_spi= 0x2CA9A57F(749315455), sa_trans= esp-3des esp-sha-hmac , sa_conn_id= 2001 ISAKMP: received ke message (4/1) ISAKMP: Unlocking ipsec struct 0x82E0D92C notified by ipsec, count 0
Idle timeout is an important IPSec feature for IPSec scalability, especially on hub sites where there may be thousands of tunnel terminations, but only a few that are active.
Reverse Route Injection (RRI) is a mechanism used to integrate route availability to IPSec state. Without RRI, routing decisions are made independent of the IPSec peer state. A route to the secure subnet of the remote peer must exist. The route might be statically configured or derived through some form of end-to-end dynamic routing exchange. Coupling the IPSec security association state with the viability of a route path simplifies the end-to-end fault recovery process. The Cisco RRI process inserts a static route associated with an IPSec peer into the forwarding information base. The availability of the route in the forwarding information base may be propagated to adjacent routers by redistributing the static routes. In this section, you’ll review two scenarios for RRI:
Static IPSec peers
Dynamic IPSec peers
A static IPSec peer is one in which the crypto maps and the corresponding IPSec security policies and proxies are pre-defined (site-to-site). In the static IPSec peer case, an IPSec session can be initiated either from the hub or the spoke. A dynamic IPSec peer is one in which the spoke side or client initiates IPSec (telecommuter) session and the receiver’s IPSec proxies are not pre-defined.
Figure 3-5 shows an application for RRI for static IPSec peers.
In Figure 3-5, VPN-GW1-EAST is the head-end router, which terminates IPSec from SPOKE- 1-EAST. With RRI configured on VPN-GW1-EAST, the remote subnet protected by SPOKE-1-EAST (that is, 10.0.68.0/24) is inserted into VPN-GW1-EAST’s forwarding table as a static route. These subnets can be advertised further by redistributing the static route to the routing protocol of choice; in example 3-4, it is redistributed into OSPF. Example 3-4 shows VPNGW1-EAST’s configuration along with a snapshot of the routing table.
Example 3-4. RRI Configuration
vpn-gw1-east ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname vpn-gw1-east ! logging queue-limit 100 ! ip subnet-zero ! ! ip domain name cisco.com ! ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.146 crypto ipsec security-association idle-time 120 ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto map vpn 1 ipsec-isakmp set peer 9.1.1.146 set transform-set test match address 100 reverse-route remote-peer 9.1.1.33 ! ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 speed 100 full-duplex no cdp enable crypto map vpn ! interface FastEthernet0/1 ip address 10.1.1.2 255.255.255.0 speed 100 full-duplex no cdp enable ! router ospf 1 log-adjacency-changes network 10.1.1.0 0.0.0.255 area 0 redistribute static subnets ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 ! ! access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255 ! ! line con 0 line aux 0 line vty 0 4 login ! end vpn-gw1-east#show ip route Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is 9.1.1.33 to network 0.0.0.0 9.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 9.1.1.32/29 is directly connected, FastEthernet0/0 S 9.1.1.146/32 [1/0] via 9.1.1.33 10.0.0.0/24 is subnetted, 2 subnets C 10.1.1.0 is directly connected, FastEthernet0/1 S 10.0.68.0 [1/0] via 9.1.1.146 S* 0.0.0.0/0 [1/0] via 9.1.1.33
Note
The behavior of RRI injecting a route into the routing table has changed as of Cisco IOS Software Release 12.3(14)T onwards. A new option has been added in the RRI command reverse-route remote-peer <ip address> static. Without the static keyword, a route is injected into the routing table only after successful establishment of IPSec SA. The “static” keyword is required if the static route has to be injected into the routing table without an SA being established in advance (which was the legacy behavior discussed in example 3-4).
RRI functionality for dynamic peers behaves exactly the same way as the static IPSec peers, except that the route to the spoke subnet is injected only after the IPSec SAs are successfully established.
RRI also gives the option of adding a route to the destination tunnel endpoint address, which is important in case the interface where the crypto map is applied is a broadcast interface, such as Ethernet. If an IP address is not specified, the route will point to the interface where the crypto map is bound. For remote access clients (for example, telecommuter clients) that use dynamic crypto maps, the route injection is tightly coupled with creation of IPSec security associations. In this case, a route will be dynamically created based on the source proxy ID and mask passed by the client during Quick Mode.
Today, when the physical link of an IPSec gateway (hub) goes down, SAs are not cleared until the IPSec SA timer expires (idle timeout or IPSec SA lifetime). For dynamic IPSec peers, RRI routes are purged from the routing table when the SAs are cleared; if a redundant hub site is present, the spokes automatically initiate IKE/IPSec toward the new hub, and all is fine. However, on static IPSec peers, the failure of a link on the IPSec gateway causes some issues with RRI.
You saw earlier that for static peers (with the static keyword), the RRI routes are injected into the routing table irrespective of whether SAs are established. This means that even if the SAs time out, the RRI route is never purged from the original hub’s routing table. Since the RRI route is never purged, traffic destined to the RRI-injected subnet is always drawn to the original hub where the SAs no longer exist. If the IPSec SAs cannot be reestablished by the original hub for the destination spoke, the traffic will be “black-holed” at this hub. This issue is resolved by combining RRI with the Cisco Hot Standby Routing Protocol (HSRP), which is discussed in the next section.
HSRP is commonly used to provide failover between routers. HSRP tracks the state of router interfaces and provides a failover mechanism between primary and secondary devices. This functionality can be exploited to provide IPSec redundancy. A simple mechanism to provide IPSec redundancy using HSRP is illustrated in Figure 3-6.
Figure 3-6 shows two routers, VPN-GW1-EAST and VPN-GW2-EAST, at the hub site with a common Ethernet on both the Internet-facing and corporate-facing sides. The remote router, in this case, SPOKE-1-EAST has an IPsec peering with the HSRP address at the hub. The active HSRP router will terminate the IPSec connection from the remote router. If the active router fails, the standby router becomes the active router and the remote router renegotiates a new IPSec session with the new active router. So far, this redundancy scheme will work fine. One problem with this scheme is the assumption that routing is symmetric. In other words, all traffic from the remote router to the active HSRP peer and the reverse traffic flow from the hub site back to the remote router is assumed to be traversing the same IPSec hub router; however, this may not be the case. RRI configuration integrated with HSRP on the hub routers ensures that routing is indeed symmetric. This solution will be explored further in Chapter 6, “Designing Fault-Tolerant IPSec VPNs.” Example 3-5 illustrates how you would map the standby IP address to the crypto map on VPN-GW1-EAST followed by the configuration on SPOKE-1- EAST. The configuration would be the same on VPN-GW2-EAST, aside from the IP address on the physical interface and the HSRP standby priority.
Example 3-5. IPSec and HSRP Configuration
vpn-gw1-east crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.146 crypto isakmp keepalive 60 3 ! ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto map vpn 1 ipsec-isakmp set peer 9.1.1.146 set transform-set test match address 100 reverse-route remote-peer 9.1.1.33 ! ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 duplex full random-detect standby delay minimum 30 reload 60 standby ip 9.1.1.34 standby priority 105 standby preempt standby name ipsec standby track FastEthernet2/0 crypto map vpn redundancy ipsec ! interface FastEthernet2/0 ip address 10.1.1.2 255.255.255.0 duplex full standby 1 ip 10.1.1.1 standby 1 priority 105 standby 1 preempt standby 1 name ip standby 1 track FastEthernet0/0 ! router ospf 1 log-adjacency-changes redistribute static subnets network 10.1.1.0 0.0.0.255 area 0 ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 no ip http server ! access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255 ! ! line con 0 stopbits 1 line aux 0 stopbits 1 line vty 0 4 login ! end spoke-1-east: crypto map vpn 1 ipsec-isakmp set peer 9.1.1.34 set transform-set test match address 100 ! interface Serial0/0 ip address 9.1.1.146 255.255.255.252 crypto map vpn ! interface Ethernet0/1 ip address 10.0.68.1 255.255.255.0 half-duplex ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.145 ! access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255
Note
HSRP runs only over Ethernet interfaces. Although it cannot run over serial interfaces, it can track the state of any interface.
HSRP’s interaction with RRI IPSec provides a good IPSec high-availability solution. The state of several important interfaces associated with routing and crypto on VPN-GW1-EAST may be mutually tracked such that a failure on any of the interfaces is synchronized; the routes and crypto termination are all revoked on VPN-GW1-EAST such that the responsibility may be transferred to the secondary router, VPN-GW2-EAST. One thing this solution does not provide is IPSec statefulness. This means that, from the perspective of SPOKE-1-EAST, it has to initiate a completely new IKE and IPSec security association to VPN-GW2-EAST’s HSRP address because VPN-GW2-EAST has no IKE or IPSec SA to SPOKE-1-EAST. Also, the spoke won’t re-initiate the IKE/IPSec SAs with the standby router until IKE or DPD times out.
A better high-availability solution is one in which the connection state can be shared between the IPSec gateways VPN-GW1-EAST and VPN-GW2-EAST. The principle benefit to the stateful failover model is that the remote spoke (VPN-SPOKE1-EAST) doesn’t need to renegotiate an IPSec security association with a standby peer because a valid security association already exists. Stateful failover is further discussed in the next section.
You have seen in Chapter 2, “IPSec Overview,” that the establishment of an IPSec security association between two endpoints requires the creation of security state information that is used to encrypt or authenticate traffic. The security association state is stored in data structures referred to as the security association database (SADB). In the event of a communications failure between two IPSec peers, the SADB must be cleared for the peer and re-created as the IPSec security association is restored. Obviously, it would be very useful for redundancy if the SADB can be duplicated and kept in synch on another peer. This is exactly the intent of the stateful failover model. Stateful failover is accomplished via a SADB transfer and synchronization process.
The IPSec state stored for a remote peer on an active router may be transferred to a standby router such that the standby router may assume the responsibilities for communicating with the active router’s remote peers. The active router and the standby router must synchronize the SADB between themselves. By synchronizing the state of the SADB between the two active and standby peers, the remote peer may maintain its IPSec state with either of the active or standby routers without requiring the renegotiation of IKE and IPSec security associations. Of course, the security transform associated with the remote peers is specified in the SADB; therefore, the IPSec policies will be identical.
Two IPSec gateways engaged in the stateful failover model must be configured such that the IKE identity address is consistent because the IPSec policy between the routers must not change. The standby router must assume the IKE identity of the active router during failover. By synchronizing the state of the SABD between the two potential remote peers, the loss of an active peer allows the standby peer to assume the role of the active peer without the remote peer’s knowledge of the transfer of responsibility. The information that the active router transmits to the standby router includes:
IKE cookie’s stamp
Session keys
Sequence number counter and window state
Kilobyte (KB) lifetime expirations
Dead peer detection (DPD) sequence number updates
Shown in Example 3-6 is the configuration of VPN-GW1-EAST and VPN-GW2-EAST with stateful IPSec using the State Synchronization Protocol (SSP) configured between them. The example also includes snapshots of various relevant show commands on both the gateways showing the SADB synchronization.
Example 3-6. Configuration for Stateful Switchover using SSP
vpn-gw1-east version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryptionyf ! hostname vpn-gw1-east ! ip subnet-zero ! ip cef ! ssp group 1 remote 9.1.1.36 redundancy ipsec ! ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.146 crypto isakmp keepalive 10 10 crypto isakmp ssp 1 ! ! ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto map vpn ha replay-interval inbound 100 outbound 1 crypto map vpn 1 ipsec-isakmp set peer 9.1.1.146 set transform-set test match address 100 reverse-route remote-peer 9.1.1.33 ! ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 duplex full random-detect standby delay minimum 30 reload 60 standby ip 9.1.1.34 standby priority 105 standby preempt standby name ipsec standby track FastEthernet2/0 crypto map vpn ssp 1 ! interface FastEthernet2/0 ip address 10.1.1.2 255.255.255.0 duplex full standby 1 ip 10.1.1.1 standby 1 priority 105 standby 1 preempt standby 1 name ip standby 1 track FastEthernet0/0 ! router ospf 1 log-adjacency-changes redistribute static subnets network 10.1.1.0 0.0.0.255 area 0 ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 no ip http server ! access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255 ! ! end vpn-gw1-east#show cry isa sa dst src state conn-id slot 9.1.1.34 9.1.1.146 QM_IDLE 1 0 vpn-gw1-east#show cry eng conn act ID Interface IP-Address State Algorithm Encrypt Decrypt 1 FastEthernet0/0 9.1.1.35 set HMAC_SHA+DES_56_CB 0 0 2000 FastEthernet0/0 9.1.1.35 set HMAC_SHA+3DES_56_C 0 4631 2001 FastEthernet0/0 9.1.1.35 set HMAC_SHA+3DES_56_C 4610 0 vpn-gw1-east#show cry ipsec sa interface: FastEthernet0/0 Crypto map tag: vpn, local addr. 9.1.1.34 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0) current_peer: 9.1.1.146 PERMIT, flags={origin_is_acl,} #pkts encaps: 6893, #pkts encrypt: 6893, #pkts digest 6893 #pkts decaps: 6893, #pkts decrypt: 6893, #pkts verify 6893 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 9.1.1.34, remote crypto endpt.: 9.1.1.146 path mtu 1500, media mtu 1500 current outbound spi: DE0F857C inbound esp sas: spi: 0x5E9B7765(1587246949) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 100, conn id: 2000, flow_id: 1, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4607260/3534) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xDE0F857C(3725559164) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 100, conn id: 2001, flow_id: 2, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4607622/3534) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas: vpn-gw1-east#show ssp packet SSP packet Information Socket creation time: 00:01:42 Local port: 3249 Server port: 3249 Packets Sent = 43, Bytes Sent = 2232 Packets Received = 5, Bytes Received = 92 vpn-gw1-east#show ssp peer SSP Peer Information IP Address Connection State Local Interface 9.1.1.36 Connected FastEthernet0/0 vpn-gw1-east#show cry ipsec ha Interface VIP SAs ipsec HA State FastEthernet0/0 9.1.1.34 2 Active since 16:09:50 vpn-gw2-east# show running-config Building configuration... Current configuration : 1587 bytes ! version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname vpn-gw2-east ! ip subnet-zero ! ! ip cef ! ssp group 1 remote 9.1.1.35 redundancy ipsec ! ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.146 crypto isakmp keepalive 10 10 crypto isakmp ssp 1 ! ! ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto map vpn ha replay-interval inbound 100 outbound 1 crypto map vpn 1 ipsec-isakmp set peer 9.1.1.146 set transform-set test match address 100 reverse-route remote-peer 9.1.1.33 ! interface FastEthernet0/0 ip address 9.1.1.36 255.255.255.248 duplex full standby delay minimum 30 reload 60 standby ip 9.1.1.34 standby preempt standby name ipsec standby track FastEthernet2/0 crypto map vpn ssp 1 ! interface FastEthernet2/0 ip address 10.1.1.3 255.255.255.0 duplex full standby 1 ip 10.1.1.1 standby 1 preempt standby 1 name ip standby 1 track FastEthernet0/0 ! router ospf 1 log-adjacency-changes redistribute static subnets network 10.1.1.0 0.0.0.255 area 0 ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 no ip http server ip pim bidir-enable ! access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255 ! ! line con 0 stopbits 1 line aux 0 stopbits 1 line vty 0 4 login ! end vpn-gw2-east#show cry isa sa dst src state conn-id slot 9.1.1.34 9.1.1.146 QM_IDLE 1 0 vpn-gw2-east#show ssp packet SSP packet Information Socket creation time: 00:05:19 Local port: 11001 Server port: 3249 Packets Sent = 5, Bytes Sent = 92 Packets Received = 121, Bytes Received = 5664 vpn-gw2-east#show cry isa ha VIP SAs Stamp HA State 9.1.1.34 1 6F2BFDBB Standby since 16:10:44 UTC vpn-gw2-east#show cry ipsec sa interface: FastEthernet0/0 Crypto map tag: vpn, local addr. 9.1.1.34 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0) current_peer: 9.1.1.146 PERMIT, flags={origin_is_acl,} #pkts encaps: 162402, #pkts encrypt: 162402, #pkts digest 162402 #pkts decaps: 162404, #pkts decrypt: 162404, #pkts verify 162404 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 57, #recv errors 0 local crypto endpt.: 9.1.1.34, remote crypto endpt.: 9.1.1.146 path mtu 1500, media mtu 1500 current outbound spi: DE0F857C inbound esp sas: spi: 0x5E9B7765(1587246949) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 100, conn id: 2000, flow_id: 1, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4142627/3552) IV size: 8 bytes replay detection support: Y HA Status: STANDBY inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0xDE0F857C(3725559164) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 100, conn id: 2001, flow_id: 2, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4147199/3552) IV size: 8 bytes replay detection support: Y HA Status: STANDBY outbound ah sas: outbound pcp sas:
Example 3-6 shows the configuration of stateful IPSec using SSP. An alternate way to configure IPSec failover using an alternate mechanism known as Stateful Switch Over (SSO) is shown in Example 3-7.
Example 3-7. Configuration for Stateful Switchover using SSO
vpn-gw1-east version 12.2 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryptionyf ! hostname vpn-gw1-east ! ip subnet-zero ! redundancy inter-device scheme standby ipsec ! ipc zone default association 1 no shutdown protocol sctp local-port 5000 local-ip 9.1.1.35 retransmit-timeout 300 1000 path-retransmit 10 assoc-retransmit 20 remote-port 5000 remote-ip 9.1.1.36 ! ip cef ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.146 crypto isakmp keepalive 10 10 ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto map vpn ha redundancy replay-interval inbound 1000 outbound 1000 crypto map vpn 1 ipsec-isakmp set peer 9.1.1.146 set transform-set test match address 100 reverse-route remote-peer 9.1.1.33 ! ! interface FastEthernet0/0 ip address 9.1.1.35 255.255.255.248 duplex full random-detect standby delay minimum 30 reload 60 standby ip 9.1.1.34 standby priority 105 standby preempt standby name ipsec standby track FastEthernet2/0 crypto map vpn redundancy ipsec stateful ! interface FastEthernet2/0 ip address 10.1.1.2 255.255.255.0 duplex full standby 1 ip 10.1.1.1 standby 1 priority 105 standby 1 preempt standby 1 name ip standby 1 track FastEthernet0/0 ! router ospf 1 log-adjacency-changes redistribute static subnets network 10.1.1.0 0.0.0.255 area 0 ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.33 no ip http server ! access-list 100 permit ip 10.1.1.0 0.0.0.255 10.0.68.0 0.0.0.255 ! ! end
The objective of both configurations shown in Example 3-6 and 3-7 is the same, which is to provide IPSec stateful failover. From an end-user perspective, other than the configuration syntax, there is not much difference between the two mechanisms. The SSP mechanism was developed specifically for IPSec stateful failover, whereas the SSO mechanism uses a more generic High Availability infrastructure which is used for providing stateful failover mechanisms for many other protocols in Cisco IOS such as OSPF, BGP, IP and others, in addition to IPSec.
A router fragments IP packets when the packet size exceeds the MTU of the outgoing interface. With IPSec, the addition of an IPSec header may cause IP fragmentation. IPSec RFCs state that this fragmentation, if needed, is performed after encryption for outbound processing. For inbound processing when an IPSec endpoint receives fragmented packets, the IPSec layer gets a reassembled packet from the IP layer before decryption.
Note
Fragmentation works in the Cisco Express Forwarding (CEF) switching path in all high-end routers such as the Cisco 7200, whereas reassembly of fragmented IP packets occurs in the IOS process switch path on all Cisco routers. Also, remember that reassembly of fragmented packets is performed only for packets that are destined to the router; fragmented packets that transit the routers are switched in the CEF path.
It is always desirable to avoid IP fragmentation between endpoints. Path MTU Discovery (PMTUD), stated in RFC 1191, was developed for this purpose. PMTUD dynamically determines the lowest MTU between two endpoints by using the Don’t Fragment (DF) bit in the IP header to dynamically discover the PMTU of a path. The basic idea of PMTU is that a source initially assumes that the PMTU of a path is the (known) MTU of its first hop, and sends all packets on that path with the DF bit set. If any of the IP packets need to be fragmented by some router along the path, that router will discard the packet and send an ICMP Destination Unreachable message to the host with a code meaning “fragmentation needed and DF set.” Upon receipt of such a message, the source host reduces its assumed PMTU for the path. PMTU is only supported for TCP, in which case the source host, upon reception of the ICMP unreachable message, sets the TCP maximum segment size (MSS). PMTU has some issues with IPSec, which will be explored in the next section.
As described in RFC 1191, PMTU works on the premise that an ICMP unreachable packet informs the host with a code meaning “fragmentation needed and DF set.” The amount of information that is returned in the ICMP message is limited, and with an IPSec packet this affects what selectors are available to identify security associations, originating hosts, and other aspects for use in further propagating the PMTU information. An ICMP PMTU may identify only the first (outermost) security association because the ICMP PMTU may contain only 64 bits of the “offending” packet beyond the IP header, which would capture only the first SPI from AH or ESP.
You can see this issue illustrated using Figure 3-6. Assume a host connected to subnet 10.0.68.0 is sending traffic to destination 10.1.1.0 with the DF bit set. IPSec policy on SPOKE-1-EAST encapsulates all traffic from this subnet to the destination subnet. The DF bit from the original IP packet is copied to the IPSec header. Also assume that the MTU of an intermediate router in the backbone requires fragmentation of the IPSec-encapsulated packet. The DF bit is set on this packet and therefore cannot be fragmented. It must be dropped by the backbone router and an ICMP unreachable (PMTU message) is sent back to the source. The source address in the PMTU message is that of the IPSec endpoint (SPOKE-1-EAST), because this router is the source of the IPSec-encapsulated packet. The ICMP PMTU message carries the SPI information, which points to the IPSec SA. In this case, a single SA is used for all hosts on the subnet. Therefore, the IPSec router has no way to figure out which host to send the Path MTU message to. To figure this out, you have two options:
The IPSec router sends the PMTU message to all hosts on this subnet.
The IPSec router stores the PMTU with the SPI and waits until the next packet(s) arrives from the originating host(s) for the relevant security association. If the packets are bigger than the PMTU, drop the packet(s), and compose ICMP PMTU message(s) with the new packet(s) and the updated PMTU, and send the originating host(s) the ICMP message(s) about the problem. This involves a delay in notifying the originating host(s), but avoids the problems of the first bullet.
The second option is more feasible than the first and is, in fact, required by the IPSec RFCs. Cisco IOS behavior mimics this option. Example 3-8 shows how SPOKE-1-EAST reacts to change in PMTU by updating the SADB.
Example 3-8. Change in PMTU in the IPSec SA
spoke-1-east# show cry ipsec sa
interface: Serial0/0
Crypto map tag: vpn, local addr. 9.1.1.146
local ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
current_peer: 9.1.1.35:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
#pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 9.1.1.146, remote crypto endpt.: 9.1.1.35
path mtu 1500, media mtu 1500
current outbound spi: BBB91DFA
inbound esp sas:
spi: 0x99E52DE4(2581933540)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607999/3589)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xBBB91DFA(3149471226)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607999/3589)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
spoke-1-east#
ICMP: dst (9.1.1.146) frag. needed and DF set unreachable rcv from 9.1.1.145
ipsec(adjust_mtu): adjusting path mtu from 1500 to 1400,
(identity) local= 9.1.1.146, remote= 9.1.1.35,
local_proxy= 10.0.68.0/255.255.255.0/0/0 (type=4),
remote_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4)
ICMP: dst (10.1.1.10) frag. needed and DF set unreachable sent to 10.0.68.5
ICMP: dst (10.1.1.10) frag. needed and DF set unreachable sent to 10.0.68.5
spoke-1-east# show cry ipsec sa
interface: Serial0/0
Crypto map tag: vpn, local addr. 9.1.1.146
local ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
current_peer: 9.1.1.35:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 35, #pkts encrypt: 35, #pkts digest 35
#pkts decaps: 39, #pkts decrypt: 39, #pkts verify 39
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: 9.1.1.146, remote crypto endpt.: 9.1.1.35
path mtu 1400, media mtu 1500
current outbound spi: BBB91DFA
inbound esp sas:
spi: 0x99E52DE4(2581933540)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607987/3020)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xBBB91DFA(3149471226)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
sa timing: remaining key lifetime (k/sec): (4607986/3020)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
Note
Another option to deal with PMTU for TCP packets is to configure the TCP MSS size on the interface facing the host using the command ip tcp mss adjust <value>. This option still will not solve the PMTU if an intermediate router along the path needs to fragment the IPSec packet.
One of the assumptions for PMTU to work is that the ICMP unreachables can reach the source. It is possible that firewalls may block ICMP messages from reaching the sources, which will break PMTUD. A workaround for this situation is to override the DF bit using the following IOS command:
Spoke-1-east(config)# crypto ipsec df-bit [clear | set | copy]
In the first case, with the DF bit clear option, no path MTU is performed and the DF bit in the IPSec header is set to 0 and fragmented if required. The default behavior is to copy the DF bit from the IP packet to the IPSec header.
The IPSec RFCs state that IP fragmentation for IPSec-encapsulated packet should happen after encryption. It would be immensely helpful if the encrypting router looks ahead and knows that after encryption and addition of the IPSec header, the resulting packet will exceed the MTU of the outbound interface and would need fragmentation. By looking ahead, the packet can be fragmented before encryption, which saves the decrypting IPSec router from the CPU-intensive job of reassembling the IPSec fragments. Reassembly of the IP packet is off-loaded to the end host. The Cisco IOS feature that performs this function is known as Look Ahead Fragmentation. The feature is quite intuitively simple; a packet arriving into an IPSec gateway will have its length plus IPSec encapsulation overhead compared to the encrypting interface’s MTU. If the expected packet size is larger than the MTU of the outbound interface, the IPSec gateway will fragment the IP packet prior to encryption. Otherwise, the packet is forwarded with encryption without fragmentation.
Example 3-9 shows the configuration of this feature. It can be configured on an interface or globally.
Example 3-9. Look Ahead Fragmentation Configuration
vpn-spoke1-east
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.34
crypto isakmp keepalive 60 3
crypto ipsec fragmentation before-encryption
Look Ahead Fragmentation configuration works for IP traffic using IPSec tunnel mode only, and will not work in case of transport mode. The reason is that in transport mode, the IP header of the original packet is used in each of the fragments, which results in the More Fragment bit set in the first fragment’s IP header and the fragment offset in the subsequent fragments. The receiving IPSec peer has no way of knowing whether an individual packet was fragmented before encryption or after encryption. Therefore, in case of transport mode, the fragments are reassembled before decryption.
Designing a VPN using IPSec for connectivity between peers has inherent limitations. These are:
IPSec can encrypt/decrypt only IP traffic.
IP traffic destined to a multicast or broadcast IP address cannot be handled by IPSec, which means that IP multicast traffic cannot traverse the IPSec tunnel. Also, many routing protocols (such as EIGRP, OSPF, and RIPv2) use a multicast or a broadcast address; therefore, dynamic routing using these routing protocols cannot be configured between IPSec peers.
These limitations can be overcome by configuring an IP-encapsulated GRE tunnel between the peers and applying IPSec protection on the GRE/IP tunnel. RFC 2784 covers GRE in detail. It essentially GRE-encapsulates any payload in an IP unicast packet destined to the GRE endpoint. A GRE-encapsulated packet is shown in Figure 3-7.
When GRE is used in conjunction with IPSec, either tunnel mode or transport mode can be used. Tunnel mode adds an IPSec IP header to the GRE packet whereas IPSec transport mode uses the original GRE packet’s IP header. Figures 3-8 and 3-9 show GRE with IPSec in tunnel mode and transport mode, respectively.
IPSec transport mode is the most efficient way to combine GRE and IPSec together because GRE encapsulation already places a new IP header on the payload. The use of IPSec transport mode, however, requires that the GRE encapsulation use an IP source and destination address that is reachable via the IP path to its peer. GRE adds 24 bytes of overhead to the original IP packet. In conjunction with IPSec transport mode, GRE encapsulation adds 4 bytes of extra overhead in comparison to the 20 bytes of overhead added by IPSec tunnel mode. Although the additional overhead and extra processing for GRE encapsulation reduce the overall throughput and may impact the latency of the connection, the benefits of using GRE with IPSec far outweigh the impact.
Use of GRE with IPSec also has the useful side effect of making IPSec VPN configuration simpler. Traditional IPSec configuration between peers requires IPSec policy configuration to specify the protected subnets so that traffic destined to the protected subnets is encrypted or decrypted. Every time a new protected subnet is added or deleted, the IPSec policy configuration needs to be updated on both peers. Also, the security policy database (SPD) and security association database (SADB) size can get quite large depending on the IPSec SA bundles negotiated and installed. This usually has an impact on the overall performance and scalability of the security gateway. Using GRE with IPSec significantly reduces the configuration complexity, as the policy in the SPD needs to match the traffic only to the GRE endpoint addresses. The addition or deletion of the protected subnets requires no change in the configuration of the IPSec SPD peers. The protected subnet traffic is directed to be encrypted by being routed out the GRE tunnel interface (everything that goes through the GRE tunnel will be encrypted). This does mean that the granularity for what gets encrypted is now at the IP address level rather than the port level in the transport header. In general, this is not an issue because usually all traffic for hosts on protected subnets is to be encrypted.
The GRE encapsulation does increase the size of the packet and potentially causes fragmentation issues. Packet fragmentation can be avoided by ensuring that PMTUD is enabled. To ensure that PMTUD works as expected, ICMP code 3 type 4 messages must be allowed through the network. If ICMP code 3 type 4 messages are not supported in the network, setting a lower MTU size on the tunnel interface will cause fragmentation before encryption to happen, achieving the same effect as Look Ahead Fragmentation. If the end hosts support PMTUD, then they will match the packet size to the configured MTU. Both the IPSec and GRE specifications support Path MTU Discovery by allowing the copy of the DF bit of the original IP header into the newly built IP header. This is usually a configuration option of the devices.
If the end host does not support PMTUD and the DF bit is not set, the packet will be fragmented and sent over the GRE-encrypted tunnel. One benefit to reducing the MTU on the GRE tunnel is that packet fragmentation occurs before it hits the encryption process; therefore, the reassembly is done on the end host and not on the peer IPSec gateway.
Example 3-10 shows the configuration of GRE tunnels protected by IPSec on SPOKE-1-EAST. Note the tunnel protection ipsec profile gre command under the GRE tunnel interface configuration, which is a new way of protecting GRE tunnels using IPSec wherein the physical interface that the GRE tunnel traverses does not need the crypto map configuration. Compare this configuration with Example 3-11, which shows the old way of IPSec-protected GRE in IOS.
Example 3-10. GRE and IPSec Using Tunnel Protection CLI
spoke-1-east ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.35 crypto isakmp keepalive 60 2 ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto ipsec profile gre set transform-set test ! int tu0 ip address 192.168.1.1 255.255.255.0 ip mtu 1400 ip tcp adjust-mss 1360 tunnel source s0/0 tunnel destination 9.1.1.35 tunnel path-mtu-discovery tunnel protection ipsec profile gre ! interface Serial0/0 ip address 9.1.1.146 255.255.255.252 crypto map vpn ! interface Ethernet0/1 ip address 10.0.68.1 255.255.255.0 half-duplex ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.145 ip route 10.0.1.0 0.0.0.255 tu0
Example 3-11. GRE Tunnel Keepalive
spoke-1-east ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.35 crypto isakmp keepalive 60 2 ! crypto ipsec transform-set test esp-3des esp-sha-hmac mode transport ! crypto map vpn 1 ipsec-isakmp set peer 9.1.1.35 set transform-set test match address 100 ! int tunnel0 ip address 192.168.1.1 255.255.255.0 ip mtu 1400 ip tcp adjust-mss 1360 tunnel path-mtu-discovery tunnel source s0/0 tunnel destination 9.1.1.35 keepalive 20 3 ! interface Serial0/0 ip address 9.1.1.146 255.255.255.252 crypto map vpn ! interface Ethernet0/1 ip address 10.0.68.1 255.255.255.0 half-duplex ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.145 ip route 10.0.1.0 0.0.0.255 tu0 ! access-list 100 permit gre host 9.1.1.146 host 9.1.1.35 spoke-1-east#show cry isa sa dst src state conn-id slot 9.1.1.35 9.1.1.146 QM_IDLE 82 0 spoke-1-east#show int tu0 Tunnel0 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of Ethernet0/1 (10.0.68.1) MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (20 sec), retries 3 Tunnel source 9.1.1.146 (Serial0/0), destination 9.1.1.35 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel TTL 255 Checksumming of packets disabled, fast tunneling enabled Last input 00:00:07, output 00:00:07, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:14 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 483 packets input, 36396 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 168 packets output, 8596 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out Tunnel0: sending keepalive, 9.1.1.35->9.1.1.146 (len=24 ttl=255), counter=1 Tunnel0: GRE/IP encapsulated 9.1.1.146->9.1.1.35 (linktype=7, len=48) IP: s=9.1.1.146 (Tunnel0), d=9.1.1.35 (Serial0/0), len 48, sending, proto =47 IP: s=9.1.1.35 (Serial0/0), d=9.1.1.146 (Serial0/0), len 24, rcvd 3, proto=47 Tunnel0: GRE/IP to decaps 9.1.1.35->9.1.1.146 (len=24 ttl=253) Tunnel0: keepalive received, 9.1.1.35->9.1.1.146 (len=24 ttl=253), reset
The primary motivation for using GRE with IPSec is its ability to run dynamic routing protocols such as OSPF or EIGRP between sites for advertising the protected subnets. Dynamic routing also implicitly helps in failover situations. On the other hand, if static routes are used for the reachability of the protected subnets with GRE, then there is no way for the IPSec peers to know that the protected subnets are not reachable when the GRE tunnel endpoints are not reachable anymore. To facilitate knowledge of the tunnel status, GRE keepalive messages can be configured on the GRE peers. Example 3-11 shows configuration of GRE keepalive under the tunnel interface. GRE tunnel comes up as soon as it sees the default route in the routing table on SPOKE-1-EAST. Now, if VPN-GW1-EAST goes down, you want the tunnel interface on SPOKE-1-EAST to go down—this is facilitated by GRE keepalives.
Note
GRE keepalives are not supported with the tunnel protection IPsec configuration syntax. Therefore, for GRE keepalive functionality, you need to use the old-style crypto map configuration.
Figure 3-10 shows the format of a GRE keepalive packet from SPOKE-1-EAST’s perspective.
Notice that the destination IP address in the inner IP header is SPOKE-1-EAST’s tunnel source address (9.1.1.146) and the source IP address in the inner IP header is that of the tunnel destination address of VPN-GW1-EAST (9.1.1.35). The protocol type (PT) in the inner header is set to 0. This payload is sent in a GRE tunnel with a protocol type of IP in the outer header with source and destination addresses as configured on the tunnel interface shown in Example 3-11. The tunnel keepalive counter is incremented by one as shown in the debug snapshots in Example 3-11. As the GRE tunnel is protected via the crypto map, this keepalive packet will be encrypted when it leaves SPOKE-1-EAST. The packet will reach the far end tunnel endpoint peer (VPN-GW1-EAST) via normal routing. Upon arrival on VPN-GW1-EAST, the packet will get decrypted and then decapsulated; the resulting packet will have a source IP address of VPNGW1- EAST and a destination IP address of SPOKE-1-EAST. This packet will now make its way back to SPOKE-1-EAST through the GRE tunnel, which is again encrypted. The packet, on reaching SPOKE-1-EAST after decryption and GRE decapsulation, will result in a PT of 0, which will signify that this is a keepalive packet that it originally constructed. The receipt of this packet signifies the GRE tunnel is up. The tunnel keepalive counter will be reset to 0 and the packet will be discarded. This process is repeated periodically by each GRE peer.
When VPN-GW1-EAST becomes unreachable from SPOKE-1-EAST for whatever reason, SPOKE-1-EAST will continue to construct and send the keepalive packets as well as normal traffic. Because the keepalives do not come back, the tunnel line protocol will stay up as long as the tunnel keepalive counter is less than the configured retry value. When the number of retries exceeds the configured value, the line protocol will be brought down on the tunnel interface on VPN-SPOKE1-EAST.
In the up/down state, the tunnel will not forward or process any traffic apart from the keepalive packets. The reception of a keepalive packet from VPN-GW1-EAST would imply that the tunnel endpoint is again reachable; when this happens, the tunnel keepalive counter will be reset to 0 and the line protocol will change state back to up, resuming data traffic.
One thing worth mentioning is that GRE keepalive packets are sent out with the TOS bit set to 5 so that the routers process those packets with higher priority, even during congestion.
Network Address Translation (NAT) is typically used to connect a private network such as a corporate network with private IP addresses to a public network such as the Internet. Because private addresses are not routable on the Internet, NAT replaces the private IP addresses with routable addresses in the public network. Keep in mind that to function, NAT doesn’t just swap IP source and destination addresses, but it may also swap TCP source and destination ports, change the IP and TCP header checksums, change the TCP sequence and acknowledgment numbers, and change IP addresses contained in the data payload. NAT is supposed to be transparent to whatever applications it works with, but this assumption is not true when NAT is used in conjunction with IPSec. Next, you’ll see how NAT affects IPSec protocols.
You may recall from Chapter 2, “IPSec Overview,” that AH protects the entire IP packet, including invariant header fields such as the source and destination IP address, through a message digest algorithm to produce a keyed hash. The recipient uses the hash to authenticate the packet. If any field in the original IP packet is modified, authentication will fail and the recipient will discard the packet. AH is intended to prevent unauthorized modification, source spoofing, and man-in-the-middle attacks. But NAT, by definition, modifies IP packets. Therefore, NAT on AH does not work.
Like AH, ESP also employs a message digest algorithm for packet authentication. But unlike AH, the hash created by ESP does not include the outer packet IP header fields. This solves one problem, but leaves other problems with ESP. When TCP or UDP are involved, as they are in transport mode ESP, there are two caveats for ESP and NAT to work together. First, because NAT modifies the TCP packet, NAT must also recalculate the checksum used to verify integrity. On the other hand, ESP authentication will fail if NAT updates the TCP checksum. If NAT does not update the checksum (for example, if the payload is encrypted), TCP verification will fail.
In tunnel mode, however, ESP has no issues with NAT. In this mode, the original IP address and transport information is included as payload. So, NAT and ESP can work together in tunnel mode when the NAT translation is 1:1 on addresses with no multiplexing of inside addresses to a single outside address using the transport layer port for differentiation.
IKE has problems when NAT devices transparently modify outgoing packets. The first issue is that some devices might depend on IKE negotiation being made by incoming packets sent from UDP port 500. If a NAT device is introduced, the final packet port will, most surely, not be the expected port; therefore, IKE negotiation will not even begin. Another issue comes about when IKE includes IP addresses as part of the authentication process, which depends on which IKE mode is used. If the authentication is based on the IP address, the changes made by a NAT device will cause IKE negotiation to fail.
The easiest way to get around IPSec issues with NAT is to avoid the problem by performing NAT before IPSec, but this is not always possible. In this section, you will examine other options for tackling IPSec issues with NAT.
The IPSec NAT Traversal (NAT-T) feature introduces support for IPSec traffic to travel through NAT points in the network. There are three parts to NAT Traversal. The first is to determine if the remote peer supports NAT Traversal. The second is to detect the presence of a NAT function along the path between the peers. The third is to determine how to deal with NAT using UDP encapsulation.
The ability of a peer to support NAT-T and detection of NAT along the path is performed as part of the IKE phase 1 negotiation process. NAT-T capability exchange is done in the first two messages of the IKE phase 1 exchange with the addition of a new vendor identification (ID) payload. Both peers need to exchange the ID for the NAT-T support between the peers. Once the NAT-T capability is successfully exchanged, the detection of NAT along the path is accomplished.
To detect whether a NAT device exists along the network path, the peers send a payload with hashes of the IP address and port of both the source and destination address from each end. If both ends calculate the hashes and the hashes match, each peer knows that a NAT device does not exist on the network path between them. If the hashes do not match (that is, if the address or port have been translated), then each peer needs to perform NAT Traversal to get the IPSec packet through the network. The hashes are sent as a series of NAT-D payloads. Each payload contains one hash. If multiple hashes exist, multiple NAT-D payloads are sent. In most environments, there are only two NAT-D payloads—one for the source address and port and one for the destination address and port. The destination NAT-D payload is sent first, followed by the source NAT-D payload, which implies that the receiver should expect to process the local NAT-D payload first and the remote NAT-D payload second. The NAT-D payloads are included in the third and fourth messages in Main Mode and in the second and third messages in Aggressive Mode. Once the responder sends the NAT-D payload, the initiator must change ports when sending the ID payload if there is NAT between the hosts. The initiator must set both UDP source and destination ports to 4500. All subsequent packets sent to this peer must be sent on port 4500. The changing of the port by IKE is called floating IKE. Figure 3-11 shows the IKE phase 1 exchange using pre-shared keys and NAT-T.
Similarly, if the responder needs to rekey the phase 1 SA, then it must start the negotiation using UDP (4500,Y). Any implementation that supports NAT traversal must support negotiations that begin on port 4500. If a negotiation starts on 4500, then it doesn’t need to change anywhere else in the exchange.
After IKE phase 1 is complete, both peers know if there is NAT between them. The final decision of using the NAT-T is left to IKE phase 2 (that is, Quick Mode). The use of NAT-T is negotiated inside the SA payloads of Quick Mode. In Quick Mode, both ends can also send the original addresses of the IPSec packets (in case of the transport mode) to the other end such that the other end has the possibility to fix the TCP/IP checksum field after NAT. Let’s now look at the packet format of an actual data packet once IKE and IPSec SAs have been negotiated between the peers using UDP encapsulation. Shown in Figure 3-12 is an UDP-encapsulated ESP packet in tunnel mode.
The UDP header is a standard header where the source port and destination port must be the same as used by floated IKE traffic. The checksum should be transmitted as a zero value. The ESP encapsulation is unchanged from what you learned in Chapter 2, “IPSec Overview.” After ESP, the UDP header is inserted and the total length, protocol, and header checksum is recalculated in the new IP outer header.
At the decryption end, the UDP header is first removed from the packet and the total length, protocol, and header checksum field is edited to match the new resulting IP packet and processed for decryption.
One more thing worth mentioning is that most NAT devices expire the translation after an idle period of time. To ensure that the translations do not expire, NAT keepalive messages are sent between the peers with a payload that resembles the one shown in Figure 3-13.
The only field that is different here compared to the other UDP-encapsulated packets is the checksum field. The sender should use a one-octet long payload with the value 0xFF. The receiver should ignore a received NAT keepalive packet.
A topology with a NAT device in front of SPOKE-1-EAST is shown in Figure 3-14. Example 3-12 shows the configuration and debugs for SPOKE-1-EAST doing NAT-T negotiation. Peers that run IOS code that support NAT-T automatically exchange this capability. The CLI to control the NAT keepalive timer to disable NAT-T is also indicated in Example 3-12.
Example 3-12. NAT Keepalive Configuration in IOS
spoke-1-east version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname spoke-1-east ! enable password lab ! ip domain name cisco.com ! ! crypto isakmp policy 1 authentication pre-share crypto isakmp key cisco address 9.1.1.35 crypto isakmp keepalive 60 crypto isakmp nat keepalive 60 ! ! crypto ipsec transform-set test esp-3des esp-sha-hmac ! crypto map vpn 1 ipsec-isakmp set peer 9.1.1.35 set transform-set test match address 100 ! ! interface Serial0/0 ip address 9.1.1.146 255.255.255.252 crypto map vpn ! interface Ethernet0/1 ip address 10.0.68.1 255.255.255.0 half-duplex no keepalive ! ip classless ip route 0.0.0.0 0.0.0.0 9.1.1.145 no ip http server ip pim bidir-enable ! ! access-list 100 permit ip 10.0.68.0 0.0.0.255 10.1.1.0 0.0.0.255 ! ! line con 0 line aux 0 line vty 0 4 password lab login ! ! end spoke-1-east# ISAKMP (0:1): constructed NAT-T vendor-03 ID ISAKMP (0:1): vendor ID is NAT-T ISAKMP (0:1): found peer pre-shared key matching 9.1.1.35 ISAKMP (0:1) local preshared key found ISAKMP (0:1): Checking ISAKMP transform 1 against priority 1 policy ISAKMP: encryption DES-CBC ISAKMP: hash SHA ISAKMP: default group 1 ISAKMP: auth pre-share ISAKMP: life type in seconds ISAKMP: life duration (VPI) of 0x0 0x1 0x51 0x80 ISAKMP (0:1): atts are acceptable. Next payload is 0 ISAKMP (0:1): constructed HIS NAT-D ISAKMP (0:1): constructed MINE NAT-D ISAKMP ISAKMP:received payload type 17 ISAKMP (0:1): Detected NAT-D payload ISAKMP (0:1): NAT does not match MINE hash hash received: 1 76 36 D8 8B 88 BA D6 8E C9 AC B1 B1 7 AB C6 C0 66 DF BE my nat hash : 77 7D 44 40 FA D0 7D A1 29 54 91 A9 D7 EC 40 A4 38 18 F1 EA ISAKMP:received payload type 17 ISAKMP (0:1): Detected NAT-D payload ISAKMP (0:1): NAT match HIS hash ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE ISAKMP (0:1): Old State = IKE_I_MM4 New State = IKE_I_MM4 ISAKMP (0:1): sending packet to 9.1.1.35 my_port 4500 peer_port 4500 (I) MM_KEY_EXCH ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE ISAKMP (0:1): Old State = IKE_I_MM4 New State = IKE_I_MM5 ISAKMP (0:1): received packet from 9.1.1.35 dport 4500 sport 4500 (I) MM_KEY_EXCH spoke-1-east#show cry isa sa det Codes: C - IKE configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal X - IKE Extended Authentication Conn id Local Remote Encr Hash Auth DH Lifetime Capabilities 1 9.1.1.146 9.1.1.35 des sha psk 1 23:59:09 DN spoke-1-east#show cry ipsec sa interface: Serial0/0 Crypto map tag: vpn, local addr. 9.1.1.146 local ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) current_peer: 9.1.1.35:4500 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 1, #recv errors 0 local crypto endpt.: 9.1.1.146, remote crypto endpt.: 9.1.1.35 path mtu 1500, media mtu 1500 current outbound spi: 8531E6D1 inbound esp sas: spi: 0x8BC80991(2345142673) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel UDP-Encaps, } slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4608000/3483) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x8531E6D1(2234640081) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel UDP-Encaps, } slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4607999/3483) IV size: 8 bytes replay detection support: Y outbound ah sas:
This section deals with another method for resolving IPSec and NAT incompatibilities. This method, however, applies only to ESP-based IPSec traffic.
The feature, IPSec pass-through, supports IKE and ESP (IP protocol 50) only in tunnel mode through an IOS PAT box. AH or ESP in transport mode are not supported.
With ESP, we know that the IP header is not authenticated, so NAT can change the IP addresses. In case of AH, authentication includes the IP header of the packet as seen in Chapter 2, “IPSec Overview. There is no way to perform address translation on a packet using NAT and recover it. NAT will change the source address, destination address, or port; therefore, authentication will fail at the remote peer. The same reason holds true for ESP in transport mode. There are two issues to be considered here—one is IKE and the other is ESP in tunnel mode. We will again refer to Figure 3-13 to explain these issues.
IKE uses UDP port 500. If there is just one device behind the NAT/PAT box, then there is nothing that needs to be done by the PAT gateway, as the IKE flow will pass unmodified as standard UDP traffic. When there is more than one IPSec device behind the PAT gateway, a unique delimiter is required to identify the IKE session for each of the IPSec endpoints. The delimiter used is the initiator cookie that is part of IKE header.
In the case of ESP, PAT needs to use some other field in the packet to multiplex. The only field that is accessible to PAT and is unique is the security parameter index (SPI) that is part of the ESP header.
The same principles apply if there is just one IPSec endpoint passing through the PAT gateway. The SPI of the endpoint can be used to map to the translation. The problem arises when more than one IPSec endpoint exists behind the PAT gateway and they all establish connections to the same remote peer. The IPSec SA is unidirectional. When the packets return from the remote peer, it will have a different SPI. The PAT gateway sitting in the middle has no way to associate inbound and outbound SPIs and decide that they belong to same ESP connection of one IPSec endpoint. Next, you examine one of the most commonly used methods to overcome this problem.
The first method, referred to as the restricted method, allows PAT to serially establish translation tables on ESP traffic initiated from inside IPSec endpoints to an outside IPSec endpoint. Once the outside endpoint starts replying, PAT assumes the packets are associated with the only outstanding IPSec session allowed to go, and “binds” the two SPIs in the translation. From this moment on, the next inside IPSec endpoint is allowed to send ESP traffic and establish its unique translation map, and so on.
Refer to the topology shown in Figure 3-14, which explains the workings of restricted ESP. The NAT translation on INTERNET-PAT-ROUTER is shown in Example 3-13. You can see that the there is both in and out mapping of the translation along with SPIs.
Example 3-13. NAT/PAT Translation with ESP
NAT-ROUTER#show ip nat translations Pro Inside global Inside local Outside local Outside global esp 100.1.1.2:0 9.1.1.146:0 9.1.1.35:0 9.1.1.35:5D826FB2 esp 100.1.1.2:0 9.1.1.146:62BC13C 9.1.1.35:0 9.1.1.35:0
From this point on, all ESP traffic between 9.1.1.146 and 9.1.1.35 using SPI1 and SPI2 uses these translations. If the endpoints decide to change SPI values, essentially a new ESP translation must be established. The one critical restriction with this approach is that PAT must first see the in-to-out connection requesting a new SPI in order to create the in-to-out translation capable of mapping the returning out-to-in reply packets.
Example 3-14 shows the configuration that is needed on the PAT box to allow ESP in a restricted way. You can see that the SPIs from the NAT translation on the NAT-ROUTER match the inbound and outbound SPIs of IPSec SAs created between VPN-GW1-EAST and SPOKE-1-EAST.
Example 3-14. PAT Configuration to Allow ESP
NAT-ROUTER# version 12.2 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname NAT-ROUTER ! ip subnet-zero ! ! interface FastEthernet0/0 ip address 100.1.1.1 255.255.255.252 ip nat outside duplex full ! interface Serial1/1:0 ip address 9.1.1.145 255.255.255.252 ip nat inside ! router ospf 1 log-adjacency-changes network 100.1.1.0 0.0.0.255 area 0 ip nat service list 1 IKE preserve-port ip nat service list 1 ESP spi-match ip nat inside source list 1 interface FastEthernet0/0 overload ip classless ip route 0.0.0.0 0.0.0.0 100.1.1.1 no ip http server no ip http secure-server ! ! ! access-list 1 permit 9.1.1.146 ! ! line con 0 exec-timeout 0 0 stopbits 1 line aux 0 stopbits 1 line vty 0 4 login line vty 5 15 login ! ! end NAT-ROUTER# debug ip nat ipsec NAT: ipsec: using mapping to create outbound ESP IL=9.1.1.146, SPI=62BC13C, IG=100.1.1.2 NAT: ipsec: created In->Out ESP translation IL=9.1.1.146 SPI=0x62BC13C, IG=100.1.1.2, OL=9.1.1.34, OG=9.1.1.34 NAT: ipsec: Inside host (IL=9.1.1.146) trying to open an ESP connection to Outside host (OG=9.1.1.34), wait for Out->In reply NAT: ipsec: new Out->In ESP transl OG=9.1.1.34 SPI=0x5D826FB2, IG=100.1.1.2, IL=9.1.1.146 NAT-ROUTER#show ip nat translations Pro Inside global Inside local Outside local Outside global esp 100.1.1.2:0 9.1.1.146:0 9.1.1.34:0 9.1.1.34:5D826FB2 esp 100.1.1.2:0 9.1.1.146:62BC13C 9.1.1.34:0 9.1.1.34:0 udp 100.1.1.2:500 9.1.1.146:500 9.1.1.34:500 9.1.1.34:500 NAT-ROUTER#show ip nat translations esp verbose Pro Inside global Inside local Outside local Outside global esp 9.1.1.33:0 9.1.1.146:0 9.1.1.34:0 9.1.1.34:5D826FB2 create 00:04:01, use 00:04:01, timing-out, flags: extended, 0x100000, use_count: 1 esp 9.1.1.33:0 9.1.1.146:62BC13C 9.1.1.34:0 9.1.1.34:0 create 00:04:01, use 00:04:01, left 00:00:58, Map-Id(In): 2, flags: extended, use_count: 0 vpn-gw1-east: vpn-gw1-east#show cry isa sa dst src state conn-id slot 9.1.1.34 100.1.1.2 QM_IDLE 10 0 vpn-gw1-east#show cry ipsec sa interface: FastEthernet0/0 Crypto map tag: vpn, local addr. 9.1.1.34 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0) remote ident (addr/mask/prot/port): (10.0.68.0/255.255.255.0/0/0) current_peer: 9.1.1.33 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 9.1.1.34, remote crypto endpt.: 100.1.1.2 path mtu 1500, media mtu 1500 current outbound spi: 5D826FB2 inbound esp sas: spi: 0x62BC13C(103530812) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 100, conn id: 2000, flow_id: 1, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4607998/3507) IV size: 8 bytes replay detection support: Y inbound ah sas: inbound pcp sas: outbound esp sas: spi: 0x5D826FB2(1568829362) transform: esp-3des esp-sha-hmac , in use settings ={Tunnel, } slot: 100, conn id: 2001, flow_id: 2, crypto map: vpn sa timing: remaining key lifetime (k/sec): (4607999/3507) IV size: 8 bytes replay detection support: Y outbound ah sas: outbound pcp sas:
This chapter covered many advanced IPSec features, some of which are specific to Cisco IOS, which help IPSec VPNs scale better and be more fault tolerant. You also explored how to use GRE in combination with IPSec to work around implicit limitations of native IPSec. Finally, you looked at how to solve IPSec issues with NAT. The concepts covered in this chapter lay the foundation for future chapters on IPSec scalability and fault tolerance. Subsequent chapters include case studies to help you understand the features within the context of design and deployment scenarios.