- Site-to-Site IPsec VPN Deployments
- Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE)
- Hub-and-Spoke IPsec VPN Deployments
- Remote Access VPN Deployments
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
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.
){kind=link}
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 traffic—192.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 engine—these 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