Site-to-Site IPsec VPN Deployments and GRE (IPsecGRE)


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 Overview

The 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 Considerations

Packets 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 Queuing

Some 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 Window

Altering 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 Configurations

Thus 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 Configuration

We 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

AS1-7304A#show run ! crypto df-bit set ! crypto ipsec fragmentation before-encryption ! ! access-list 101 permit gre host 201.1.1.1 host 202.1.1.1 access-list 102 permit gre host 201.1.1.1 host 203.1.1.1 ! interface Tunnel12  ip address 200.1.12.1 255.255.255.252  qos pre-classify  tunnel source 201.1.1.1  tunnel destination 202.1.1.1 ! interface Tunnel13  ip address 200.1.13.1 255.255.255.252  qos pre-classify  tunnel source 201.1.1.1  tunnel destination 203.1.1.1 ! interface Loopback1  ip address 201.1.1.1 255.255.255.255 !


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

AS2-3745A#show run ! crypto df-bit set ! crypto ipsec fragmentation before-encryption ! ! access-list 101 permit gre host 202.1.1.1 host 201.1.1.1 access-list 102 permit gre host 202.1.1.1 host 203.1.1.1 ! interface Tunnel12  ip address 200.1.12.2 255.255.255.252  qos pre-classify  tunnel source 202.1.1.1  tunnel destination 201.1.1.1 ! interface Tunnel23  ip address 200.1.23.1 255.255.255.252  qos pre-classify  tunnel source 202.1.1.1 tunnel destination 203.1.1.1 ! interface Loopback1  ip address 202.1.1.1 255.255.255.255 !


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

AS3-3745A#show run ! crypto df-bit set ! crypto ipsec fragmentation before-encryption ! ! access-list 101 permit gre host 203.1.1.1 host 201.1.1.1 access-list 102 permit gre host 203.1.1.1 host 202.1.1.1 ! interface Tunnel13  ip address 200.1.13.2 255.255.255.252  qos pre-classify  tunnel source 203.1.1.1  tunnel destination 201.1.1.1 ! interface Tunnel23  ip address 200.1.23.2 255.255.255.252  qos pre-classify  tunnel source 203.1.1.1  tunnel destination 202.1.1.1 ! interface Loopback1  ip address 203.1.1.1 255.255.255.255 !


Verification of IPsec+GRE Tunnel Establishment

Verifying 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:

  • Verification of tunnel establishment

  • Verification of RP (including PIM) adjacencies through the tunnel

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:

  • Verify GRE tunnel establishment and interface status.

  • Verify basic connectivity through the GRE tunnel.

  • Verify RP adjacencies across the GRE tunnel.

Example 3-11. Verification of GRE Tunnels and Tunneled Routing Protocols on AS1-7304A

AS1-7304A#show ip int brief Interface             IP-Address      OK? Method Status                Protocol FastEthernet0/0       unassigned      YES NVRAM  administratively down down Serial0/0             unassigned      YES NVRAM  up                    up Serial0/0.12          200.1.1.1       YES manual up                    up Serial0/0.13          200.1.1.9       YES manual up                    up Loopback0             201.1.1.1       YES manual up                    up Loopback1             192.168.1.1     YES manual up                    up Tunnel12              192.168.12.1    YES manual up                    up Tunnel13              192.168.13.1    YES manual up                    up AS1-7304A#ping 192.168.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms AS1-7304A#ping 192.168.13.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.13.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms AS1-7304A#show ip eigrp interfaces IP-EIGRP interfaces for process 192                         Xmit Queue   Mean   Pacing Time   Multicast    Pending Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes Lo1                0        0/0         0       0/10           0           0 Tu12               1        0/0       736      71/2702      6362           0 Tu13               1        0/0       277      71/2702      3710           0 AS1-7304A#sh ip eigrp neighbors IP-EIGRP neighbors for process 192 H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq                                             (sec)         (ms)       Cnt Num 1   192.168.13.2            Tu13              12 00:18:36  277  5000  0  41 0   192.168.12.2            Tu12              12 00:19:01  736  5000  0  48


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

AS1-7304A#sh crypto engine conn active   ID Interface       IP-Address      State  Algorithm          Encrypt  Decrypt    1 Se0/0.12        200.1.1.1       set    HMAC_SHA+3DES_56_C       0        0    2 Se0/0.13        200.1.1.9       set    HMAC_SHA+3DES_56_C       0        0 2002 Se0/0.13        200.1.1.9       set    HMAC_SHA+AES_CBC         0      145 2003 Se0/0.13        200.1.1.9       set    HMAC_SHA+AES_CBC       146        0 2004 Se0/0.12        200.1.1.1       set    HMAC_SHA+AES_CBC         0      139 2005 Se0/0.12        200.1.1.1       set    HMAC_SHA+AES_CBC       139        0


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.





IPsec Virtual Private Network Fundamentals
IPSec Virtual Private Network Fundamentals
ISBN: 1587052075
EAN: 2147483647
Year: N/A
Pages: 113

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net