Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE)At the core of IPsec is point-to-point functionality, which is not suited for all of today's IP communications. Indeed, many of today's voice and video applications require point-tomultipoint connectivity. As such, they leverage IP multicast techniques to selectively flood data to interested parties. Traditionally, IP multicast traffic has not effectively been passed through the crypto switching path on IPsec routers. As we have discussed, this precludes users from encrypting multicast applications such as multicast voice (hoot-n-holler), multicast video (IPTV), and routing protocols (OSPF, ISIS, RIP, EIGRP). The current solution for accommodating these types of traffic in cipher-text is IPsec+GRE. Site-to-Site IPsec+GRE Architectural OverviewThe IPsec+GRE model is used most commonly when there are traffic types that require confidentiality which are not traditionally suited for IPsec point-to-point traffic. IP multicast-based applications, such as routing protocols that use multicast updates and multicast applications for streaming voice and video over IP, would fall in to this category. Through the use of GRE, these multicast traffic types can be represented (encapsulated with a unicast GRE header) in a format acceptable to the IPsec crypto engine. Figure 3-5 illustrates the process of encrypting a multicast data feed with IPsec+GRE. Note that the original IP multicast header will not present an IP packet format acceptable for IPsec direct encapsulation. Because of this, GRE is used to encapsulate the multicast header and payload with a unicast header, resulting in a packet that can then be encapsulated with either ESP or AH. The GRE header and original IP multicast header will be encrypted as they are both part of the ESP-protected payload. Figure 3-5. Multicast Packet GRE Encapsulation (IP Multicast Encapsulated GRE Encapsulated in ESP)Although IPsec+GRE does provide a wider scope of confidentiality when applying the ESP encapsulation, and enables confidentiality for additional IP applications, increased maximum transmission unit (MTU) sizes of encapsulated packets become an increased design concern. Increased Packet Size and Path MTU ConsiderationsPackets continue to get larger and larger as continuous layers of encapsulation are added to the original IP payload. For example, an IP-encapsulated RTP packet for voice of 64 bytes in length grows to approximately 128 bytes after it is encapsulated in RTP (12 bytes), UDP (8 bytes), IP (20 bytes), and GRE (24 bytes), and to 184 bytes after the GRE-encapsulated RTP packet is encapsulated again with an ESP header, padding and authentication fields, and trailer (subtotal of approximately 56 bytes). Increasing packet sizes in this fashion also increases the chances that the packet will be fragmented after it has been encrypted, as would be the case if the encrypted packet exceeds the MTU of a link somewhere in the path between the two VPN endpoints. This can cause problems on the decrypting router, which will attempt to decrypt the fragmented packets in the process switching path (without hardware assist), causing scalability issues in terms of performance. Path MTU discovery can be deployed in conjunction with the Cisco IOS IPsec prefragmentation, enabling the encrypting router to dynamically determine the smallest MTU of the path between VPN endpoints. The encrypting VPN router is then capable of fragmenting to the appropriate MTU for the path on a per-SA basis using IPsec prefragmentation, assuring that the fragmentation of IPsec packets always occurs prior to encryption and is therefore done in the fast path. Note Common fragmentation issues in IPsec VPNs are discussed in detail in Chapter 4, "Common IPsec VPN Issues." Available solutions for fragmenting prior to encryption, including path MTU discovery and IPsec prefragmentation, are also discussed in Chapter 4. GRE and Weighted Fair QueuingSome quality of service (QoS) techniques, such as weighted fair queuing (WFQ), perform conversation hashing decisions based on the original source and destination IP address, which can be ubiquified after IPsec or GRE encapsulation. While DiffServ markings are copied to the outer IP header in tunnel mode IPsec, the original source and destination are not carried forward into outer IP header. In order to appropriately execute hashing decisions in WFQ operations, packets must therefore be classified prior to encapsulation. Cisco IOS supports IPsec QoS pre-classify functionality on IOS VPN endpoints to assure that flow and conversation-based queuing decisions can be executed accurately in IPsec VPN environments. QoS and the IPsec Anti-Replay WindowAltering the scheduling of packets before IPsec processing (as is the case with QoS pre-classify) conflicts with sequencing schemes native to IPsec that are used for anti-replay protection. Cisco IOS offers IPsec QoS Pre-Classify, which allows packets to be queued prior to ESP, AH, or GRE encapsulation. Alternatively, anti-replay windows can be increased to ensure that IPsec packets are received within the anti-replay window even when reordered and delayed due to queuing decisions on nodes between IPsec VPN endpoints. When deploying QoS in vendor-diverse environments, it is recommended that the operation be monitored to ensure that packet reordering does not conflict with anti-replay functions native to IPsec. Site-to-Site IPsec+GRE Sample ConfigurationsThus far, we have introduced the requirement of unicast presentation of data flows to the IPsec crypto engine. In this section, we will discuss working IPsec+GRE configuration procedures, examples, and verification techniques to use when encapsulating multicast traffic with a unicast header so that it can be processed with encrypted with IPsec. Cisco IOS Site-to-Site IPsec+GRE ConfigurationWe will now alter the configurations that we built in Examples 3-1 through 3-3 to include GRE encapsulation prior to the encapsulation of ESP. The IPsec transform and ISAKMP polices will remain consistent with Examples 3-1 through 3-3, as will the some of the crypto map configuration elements, such as the PFS and peering configurations. However, other crypto map configuration elements, such as the crypto ACLs, will change to accommodate GRE traffic. We will also demonstrate IOS QoS for IPsec VPNs by configuring the routers to classify packets prior to GRE encapsulation and crypto processing. The topology used for these configurations is depicted in Figure 3-2, but instead of native IPsec ESP tunnels, the ESP-encapsulated point-to-point GRE tunnels are used between the edge routers of AS#1, AS#2, and AS#3. Example 3-8 illustrates some of the configuration changes made to AS1-7304A to accommodate IPsec+GRE. One of the most important differences in this configuration compared to Example 3-1 is the change in the crypto ACLs. Note that in Example 3-8, the crypto ACLs protect GRE traffic from the GRE tunnel source and destination address from AS1-7304A to AS2-3745A and AS3-3745A, respectively. This will effectively encrypt all traffic passing over the GRE tunnels from AS1-7304A to AS2-3745A and AS3-3745A. In addition to the crypto ACL change on ASS1-7304A, several measures are taken to guarantee that encrypted packets are not fragmented. AS1-7304A's crypto engine will attempt to fragment packets to the path MTU (discovered through path MTU discovery between the two VPN endpoints) of the appropriate SA in the SADB. Additionally, AS1-7304A is configured to set the DF bit in the outer IP header of the encrypted fragments, effectively ensuring that network nodes between the two crypto endpoints are not able to fragment encrypted messages while in transit. Example 3-8. Site-to-Site VPN Configuration on AS1-7301A
Example 3-9 provides the IPsec+GRE configuration for the IPsec VPN gateway for AS2. Like AS1-7304A, AS2-3745A is configured to protect all GRE-encapsulated data from a local GRE tunnel source to the appropriate GRE tunnel endpoints on AS1-7304A and AS3-3745A. AS2-3745A also is configured to prevent fragmentation after encryption and to classify packets with QoS prior to encryption. Example 3-9. Site-to-Site VPN Configuration on AS2-3745A
Example 3-10 provides the IPsec+GRE configuration for the IPsec VPN gateway for AS3. Like AS1-7304A, AS3-3745A is configured to protect all GRE-encapsulated data from a local GRE tunnel source to the appropriate GRE tunnel endpoints on AS1-7304A and AS2-3745A. AS3-3745A also is configured to prevent fragmentation after encryption and to classify packets with QoS prior to encryption. Example 3-10. Site-to-Site VPN Configuration on AS3-3745A
Verification of IPsec+GRE Tunnel EstablishmentVerifying an IPsec+GRE tunnel begins with the same steps that are taken in the verification of a standard IPsec tunnel. Verification of ISAKMP and IPsec SAs must be done, and basic connectivity through the GRE tunnel must be established. However, when GRE is added to the VPN, steps must be taken to verify tunneled connectivity prior to the addition of IPsec:
Once these basic tunneling operations have been verified, they must be re-verified after the addition of IPsec. In addition to that re-verification, the administrator should also verify the establishment of ISAKMP SA, IPsec SA, and that traffic passed over the IPsec+GRE tunnel is actually being encrypted, as we explored in Examples 3-4 through 3-7. Example 3-8 demonstrates the non-crypto GRE verification steps on AS1-7304A (prior to the addition of the crypto map to the physical interface) and the verification of the full IPsec+GRE tunnel (after the crypto map has been applied to the physical interface). Again, note that all EIGRP traffic is kept confidential from the OSPF core via IPsec processing of all GRE traffic (which in this case includes all EIGRP traffic192.168.x.x/16 address space) between endpoints. Example 3-11 illustrates several typical diagnostic steps needed to verify the establishment of a GRE tunnel and of RP adjacencies using that GRE tunnel, including:
Example 3-11. Verification of GRE Tunnels and Tunneled Routing Protocols on AS1-7304A
After we have verified the basic operation of the routing protocol adjacencies and updates over the GRE tunnels, we are ready to verify that the crypto engine is processing the GRE tunnel through which subsequent control and data plane traffic will traverse. The diagnostic output in Example 3-12 verifies that protected traffic (in this case all GRE traffic) is being processed by the crypto engine. This output reflects statistics after 100 pings are forwarded across each GRE (and subsequently IPsec) tunnel. Note that there are more than 100 packets processed by the crypto enginethese extra packets are GRE-tunneled packets using various control plan traffic including RP updates and adjacency maintenance. Example 3-12. Verification of Crypto-Processed Traffic after Crypto Maps Have Been Applied to Physical Interfaces That Will Protect All GRE Traffic Between the Two GRE Tunnel Endpoints
Tip It is recommended that the administrator re-verify the steps taken in Example 3-11 to confirm the operation of GRE and RPs after the crypto map has been added. It is further recommended that the administrator verify the cryptographic elements added to the GRE tunnel using the techniques outlined in our discussion of site-to-site VPNs in Examples 3-4 through 3-7. |