Basic IPsec VPN Topologies and Configurations

This chapter is from the book 

In this chapter, we will review several common deployments of IPsec virtual private networks (VPNs). We will begin by reviewing the typical site-to-site IPsec model over a dedicated circuit between two endpoints, then discuss some of the design implications as that dedicated circuit grows to include an entire routed domain. We will discuss aggregation of many site-to-site IPsec VPNs at an aggregation point, or hub IPsec router, in a standard hub-and-spoke design and extend the IPsec aggregation concept to include Remote Access VPN (RAVPN) design considerations. Figure 3-1 illustrates a loose process that may be helpful when configuring a crypto endpoint for basic IPsec operations. Though effective IPsec VPN design drives the complexity of configuration far beyond what is depicted in Figure 3-1, most of the basic topologies we will discuss will relate to this procedure on a fundamental level.

Each of the following deployments requires the configuration of IPsec in a point-to-point fashion in one way or another. As such, all of the topologies discussed share common configuration tasks to establish the IPsec tunnel:

1. Decide how strong the IPsec transform must be and what mode the tunnel must use (define IPsec Transform Set).
2. Decide how the session keys must be derived and if IKE is necessary (create ISAKMP Policy or Session Keys within Crypto Map).
3. If IKE is required, decide on ISAKMP policy parameters (create Internet Security Association and Key Management Protocol policy), addressing the following tasks in your configuration:

   • Authentication method (select one of the following):

     Assign key and peer if pre-shared.

     Create and share RSA public keys if RSA-encr.

     Authenticate and enroll with CA if RSA-sig.

   • Diffie-Hellman Key Modulus (Group #)
   • Hash used for IKE authentication
   • Encryption method used for IKE channel
4. Identify and assign IPsec peer and any High-Availability requirements. (Create crypto map.)

   Note

   In this chapter, topologies will include only limited discussions of IPsec High-Availability (HA) design concepts. IPsec HA design and examples are discussed in greater detail in Chapters 5–9.

5. Define traffic sets to be encrypted (Crypto ACL Definition and Crypto Map Reference).
6. Identify requirement for PFS and reference PFS group in crypto map if necessary.
7. Apply crypto map to crypto interfaces.

Site-to-Site IPsec VPN Deployments

The most basic form of IPsec VPN is represented with two VPN endpoints communicating over a directly connected shared media, or dedicated circuit, which closely resembles bulk encryption alternatives at Layer 1 and 2 of the OSI stack (see Table 1-1 for VPN technologies and the OSI stack). This scenario, while simple to deploy and manage, can be cost prohibitive and does not yield many of the benefits of IPsec VPN connectivity over a routed domain (multiple Layer 3 hops between endpoints).

Indeed, because IPsec is a Layer 3 VPN technology, it was designed to function across multiple Layer 3 hops in order to circumvent many of the scalability and manageability issues in previous VPN alternatives. As such, IPsec deployed over a routed domain will also provide further scalability, flexibility, and availability over and beyond the simple dedicated-circuit model. In this section, we will explore design concepts related to both topologies and the corresponding configuration and verification processes required.

Site-to-Site VPN Architectural Overview for a Dedicated Circuit

Site-to-site IPsec VPNs are typically deployed when two or more autonomous systems wish to communicate with each other over an untrusted media when confidential exchange of data is required. Consider the situation described in Figure 3-2, where three autonomous systems wish to communicate using dedicated T-1 circuits between each pair.

It is important to note that, assuming that each autonomous system (AS) does not act as a transit AS, there is only one path between each AS. Therefore, in this specific case, there is no benefit to configuring redundant peering options or sourcing IPsec tunnel endpoints from highly available IP addresses (such as a loopback address). In this simple site-to-site topology, it is most common to source IPsec VPN tunnel endpoints on the physical interfaces (DS-3 in this case) themselves. This type of topology does not leave room for much in the way of IPsec HA design, and therefore, it is relatively simple to deploy. We will now explore the configuration steps necessary to establish the basic site-to-site IPsec VPN described earlier, and then we will outline some common techniques used to verify the establishment and operation of the IPsec VPN tunnel.

Cisco IOS Site-to-Site IPsec VPN Configuration

The configurations in the following examples were all built using the process described in Figure 3-1 and pertain to the topology depicted in Figure 3-2. Some design considerations for these particular IPsec VPNs are as follows:

• Tunnel mode is used to keep the original IP header confidential.
• The routers are capable of handling 256-bit AES ESP transforms in hardware. Hash-based Message Authentication Codes (HMAC) are implemented in the transform to ensure integrity in the cipher block chain of encrypted packets traversing the IPsec security association (SA).
• The DH group is 5 in order to accommodate the large key material needed by the AES transform.
• There is no certification authority (CA), and the administrators want to use hardware acceleration, which rules out the RSA-encrypted nonces method of authentication. So preshared keys are used for Internet Security Association and Key Management Protocol (ISAKMP) authentication.
• Strong authentication is required during ISAKMP, so the hash is SHA-1 and the symmetric transform for the IKE SA is 3DES.
• It is desirable to have the IPsec session keys derived independently (as opposed to derived from the ISAKMP DH shared secret keys). As such, perfect forward secrecy (PFS) is enabled. Again, the group is 5 to generate the appropriate key material for the IPsec transform (AES).

Example 3-1 provides a configuration for the AS1-7301A in Figure 3-2. This router's configuration employs all of the elements necessary to accommodate a site-to-site IPsec VPN, including the IPsec transform, crypto ACL, and IPsec peer. In this case, AS1-7301A uses two site-to-site IPsec VPNs, to AS#2 and AS#3, respectively. This is accomplished by using two process IDs within the same crypto map (AS1VPN 10 and AS1VPN 20). AS1VPN, process 10, protects traffic from AS1 to AS2, as defined in Crypto ACL 101. AS1VPN, process 20, protects traffic from AS1 to AS3 (Example 3-1, line 14), as defined in Crypto ACL 102 (Example 3-1, line 15).

Example 3-1. Site-to-Site VPN Configuration on AS1-7301A

AS1-7304A#show running-config
!
crypto ipsec transform-set ivdf3-1 esp-aes esp-sha-hmac
crypto map AS1VPN 10 ipsec-isakmp
 set peer 200.1.1.2
 set transform-set ivdf3-1
 match address 101
 set pfs group5
crypto map AS1VPN 20 ipsec-isakmp
 set peer 200.1.1.10
 set transform-set ivdf3-1
 match address 102
 set pfs group5
access-list 101 permit ip 211.0.0.0 0.255.255.255 212.0.0.0 0.255.255.255
access-list 102 permit ip 211.0.0.0 0.255.255.255 213.0.0.0 0.255.255.255
!
interface HSSI1/0
 ip address 200.1.1.1 255.255.255.252
 encapsulation HDLC
 crypto map AS1VPN
   interface HSSI2/0
   ip address 200.1.1.9 255.255.255.252
 encapsulation HDLC
 crypto map AS1VPN

Example 3-2 provides the configuration for the IPsec VPN gateway for AS2, AS2-3745A. Like AS1-7304A, AS2-3745A uses a single crypto map with two process IDs to protect traffic flows to AS1 and AS3. AS2VPN 10 protects traffic to AS1 (endpoint 200.1.1.1), and references ACL101 for crypto-protected traffic and IPsec transform "ivdf3-1." AS2VPN 20 protects traffic to AS3 (endpoint 200.1.1.6), and references ACL102 for crypto-protected traffic and IPsec transform "ivdf3-1." AS2-3745 uses a relatively strong transform, AES cipher with SHA1 HMAC authentication. PFS is also configured to refresh the symmetric transform key each time an IPsec SA is negotiated.

Example 3-2. Site-to-Site VPN Configuration on AS2-3745A

AS2-3745A#show running-config
!
crypto ipsec transform-set ivdf3-1 esp-aes esp-sha-hmac crypto map AS2VPN 10 ipsec-isakmp
 set peer 200.1.1.1
 set transform-set ivdf3-1
 match address 101
 set pfs group5
crypto map AS2VPN 20 ipsec-isakmp
 set peer 200.1.1.6
 set transform-set ivdf3-1
 match address 102
 set pfs group5
access-list 101 permit ip 212.0.0.0 0.255.255.255 211.0.0.0 0.255.255.255
access-list 102 permit ip 212.0.0.0 0.255.255.255 213.0.0.0 0.255.255.255
!
interface HSSI1/0
 ip address 200.1.1.2 255.255.255.252
 encapsulation HDLC
 crypto map AS2VPN
interface HSSI2/0
 ip address 200.1.1.5 255.255.255.252
 encapsulation HDLC
 crypto map AS2VPN

Example 3-3 provides the configuration for the IPsec VPN gateway for AS3, AS3-3745A. Like AS1-7304A and AS2-3745A, AS3-3745A uses a single crypto map with two process IDs to protect traffic flows to AS1 and AS3. AS3VPN 10 protects traffic to AS1 (endpoint 200.1.1.9), and references ACL101 for crypto-protected traffic and IPsec transform "ivdf3-1." AS3VPN 20 protects traffic to AS3 (endpoint 200.1.1.5), and references ACL102 for crypto-protected traffic and IPsec transform "ivdf3-1." AS2-3745 uses a relatively strong transform, AES cipher with SHA1 HMAC authentication. PFS is also configured to refresh the symmetric transform key each time an IPsec SA is negotiated.

Example 3-3. Site-to-Site VPN Configuration on AS3-3745A

AS3-3745A#show run
!
crypto ipsec transform-set ivdf3-1 esp-aes esp-sha-hmac
crypto map AS3VPN 10 ipsec-isakmp
 set peer 200.1.1.9
 set transform-set ivdf3-1
 match address 101
 set pfs group5
crypto map AS3VPN 20 ipsec-isakmp
 set peer 200.1.1.5
 set transform-set ivdf3-1
 match address 102
 set pfs group5
access-list 101 permit ip 213.0.0.0 0.255.255.255 211.0.0.0 0.255.255.255
access-list 102 permit ip 213.0.0.0 0.255.255.255 212.0.0.0 0.255.255.255
!
interface HSSI1/0
 ip address 200.1.1.10 255.255.255.252
 encapsulation HDLC
 crypto map AS3VPN
interface HSSI2/0
 ip address 200.1.1.6 255.255.255.252
 encapsulation HDLC
 crypto map AS3VPN

Verifying Cisco IOS Site-to-Site IPsec VPN Operation

Now that we have configured a full mesh of IPsec VPN tunnels between AS#1, AS#2, and AS#3, we must take some basic precautionary measures to guarantee that the VPN is operating successfully:

1. Verify the establishment of ISAKMP SAs.
2. Verify the establishment of IPsec SAs.
3. Verify that basic network connectivity has been established over the VPN.
4. Verify that the Crypto Engine is actively participating in IPsec and that protected traffic is being encrypted and decrypted.
5. Check physical interface statistics for errors.

Examples 3-4 through 3-7 provide examples of these verification tasks on AS1-7304A in Figure 3-2. First, we verify that an ISAKMP SA has been successfully established. Example 3-4 confirms that there are indeed two ISAKMP SAs established to AS2-3745A and AS3-3745A. Note that these SAs are in "QM_IDLE" state, meaning that the ISAKMP SA is authenticated and can be used for subsequent Quick Mode (Phase 2) exchanges. The ISAKMP SA can exist in a number of other states. These states are described in Table 3-1 for ISAKMP SA negotiation in Main Mode.

Table 3-1. ISAKMP SA States for IKE Main Mode SA Negotiation

IKE SA State (Main Mode)	Description
MM_NO_STATE	The ISAKMP SA has been created, but nothing else has happened yet. It is "larval" at this stage—there is no state.
MM_SA_SETUP	The peers have agreed on parameters for the ISAKMP SA.
MM_KEY_EXCH	The peers have exchanged Diffie-Hellman public keys and have generated a shared secret. The ISAKMP SA remains unauthenticated.
MM_KEY_AUTH	The ISAKMP SA has been authenticated. If the router initiated this exchange, this state transitions immediately to QM_IDLE, and a Quick Mode exchange begins.

Though the SA described in Example 3-4 was negotiated using Main Mode, Aggressive Mode could have been used instead. Table 3-2 presents the ISAKMP SA states and their descriptions for SAs negotiated with Aggressive Mode. Note that in Table 3-2, there are inherently fewer states described for Aggressive Mode, because Aggressive Mode involves fewer message exchanges than does Main Mode.

Table 3-2. ISAKMP SA States for IKE Aggressive Mode Negotiation

IKE SA State (Aggressive Mode)	Description
AG_NO_STATE	The ISAKMP SA has been created, but nothing else has happened yet. It is "larval" at this stage—there is no state.
AG_INIT_EXCH	The peers have done the first exchange in Aggressive Mode, but the SA is not authenticated.
AG_AUTH	The peers have done the first exchange in Aggressive Mode, but the SA is not authenticated.

Example 3-4. Verification of ISAKMP SAs for AS1-7304A

AS1-7304A#show crypto isakmp sa
dst             src             state         conn-id slot
200.1.1.10      200.1.1.9       QM_IDLE             2    0
200.1.1.1       200.1.1.2       QM_IDLE             1    0

After we can verify that Phase 1 SAs are established (by examining the output listed in Example 3-4), we are then ready to verify the establishment of IPsec SAs. Example 3-5 provides output needed to verify several important elements of Phase 2 SA establishment:

• The IPsec VPN Peer Address for the SA (200.1.1.2 for AS1VPN process 10 and 200.1.1.10 for AS1VPN process 20).
• The crypto-protected IPsec address sets specified in the Crypto ACLs for this SA (211.0.0.0/8->212.0.0.0/8 for AS1VPN process 10 and 211.0.0.0/8->213.0.0.0/8 for AS1VPN process 20).
• Inbound SA information, including IPsec transform used, crypto map used, initialization value (IV), and replay information. Note that there are fields for ESP, PCP, and Authentication Header (AH)—only the ESP fields are populated because there is no AH specified in the transform set for this IPsec SA.
• Outbound SA information, including IPsec Transform used, crypto map used, IV, and replay information. Note that there are fields for ESP, PCP, and AH—only the ESP fields are populated as there is no AH specified in the transform set for this IPsec SA.
• The peering encryption/decryption activity for this security association.

Example 3-5. Verification of IPsec SAs for AS1-7304A

AS1-7304A#show crypto IPsec sa

interface: HSSI1/0
  Crypto map tag: AS1VPN, local addr. 200.1.1.1
 protected vrf:
 local  ident (addr/mask/prot/port): (211.0.0.0/255.0.0.0/0/0)
 remote ident (addr/mask/prot/port): (212.0.0.0/255.0.0.0/0/0)
 current_peer: 200.1.1.2:500
  PERMIT, flags={origin_is_acl,}
 #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
 #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.: 200.1.1.1, remote crypto endpt.: 200.1.1.2
 path mtu 1500, media mtu 1500
 current outbound spi: 770BFB0E
 inbound esp sas:
  spi: 0xBAB54AEB(3132443371)
  transform: esp-aes esp-sha-hmac ,
    in use settings ={Tunnel, }
    slot: 0, conn id: 2000, flow_id: 7, crypto map: AS1VPN

    crypto engine type: Software, engine_id: 1
    sa timing: remaining key lifetime (k/sec): (4439346/3318)
    ike_cookies: 3A2297BC 4BED61BF 7571B28B 40217AB8
    IV size: 16 bytes
    replay detection support: Y

inbound ah sas:

inbound pcp sas:
outbound esp sas:
spi: 0x770BFB0E(1997273870)
 transform: esp-aes esp-sha-hmac ,
 in use settings ={Tunnel, }
 slot: 0, conn id: 2001, flow_id: 8, crypto map: AS1VPN
 crypto engine type: Software, engine_id: 1
 sa timing: remaining key lifetime (k/sec): (4439347/3316)
 ike_cookies: 3A2297BC 4BED61BF 7571B28B 40217AB8
 IV size: 16 bytes
 replay detection support: Y

outbound ah sas:

outbound pcp sas:

interface: HSSI2/0
  Crypto map tag: AS1VPN, local addr. 200.1.1.9
 protected vrf:
 local ident (addr/mask/prot/port): (211.0.0.0/255.0.0.0/0/0)
 remote ident (addr/mask/prot/port): (213.0.0.0/255.0.0.0/0/0)
 current_peer: 200.1.1.10:500
  PERMIT, flags={origin_is_acl,}
  #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
  #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 6, #recv errors 0

  local crypto endpt.: 200.1.1.9, remote crypto endpt.: 200.1.1.10
  path mtu 1500, media mtu 1500
  current outbound spi: E60B73DB
  inbound esp sas:
  spi: 0x1A397721(439973665)
    transform: esp-aes esp-sha-hmac ,
    in use settings ={Tunnel, }
    slot: 0, conn id: 2002, flow_id: 9, crypto map: AS1VPN
    crypto engine type: Software, engine_id: 1
    sa timing: remaining key lifetime (k/sec): (4594078/3450)
    ike_cookies: BB9827E5 847ADAE6 4ED69C6A 7546D684
    IV size: 16 bytes
    replay detection support: Y

  inbound ah sas:

  inbound pcp sas:
  outbound esp sas:
  spi: 0xE60B73DB(3859510235)
    transform: esp-aes esp-sha-hmac ,
    in use settings ={Tunnel, }
    slot: 0, conn id: 2003, flow_id: 10, crypto map: AS1VPN
    crypto engine type: Software, engine_id: 1
    sa timing: remaining key lifetime (k/sec): (4594079/3450)
    ike_cookies: BB9827E5 847ADAE6 4ED69C6A 7546D684
    IV size: 16 bytes
    replay detection support: Y

  outbound ah sas:

  outbound pcp sas:

In Example 3-6, we will attempt to send traffic across both IPsec VPN tunnels to the remote peers on AS2-3745A and AS3-3745A, respectively. First, we display the crypto-protected address spaces by displaying the ACLs referenced in the crypto map. Next, we send 100 ICMP echo requests to both peers. Note that in both cases, we drop the first ICMP packet during IKE and IPsec SA negotiation.

Example 3-6. Verification of Connectivity along the Crypto Path

AS1-7304A#show access-list 102
Extended IP access list 102
    10 permit ip host 201.1.1.1 host 202.1.1.1
AS1-7304A#show access-list 103
Extended IP access list 103
    10 permit ip host 201.1.1.1 host 203.1.1.1
AS1-7304A#ping
Protocol [ip]:
Target IP address: 202.1.1.1
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 201.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 202.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 201.1.1.1

.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (99/100), round-trip min/avg/max = 44/46/48 ms
AS1-7304A#ping
Protocol [ip]:
Target IP address: 203.1.1.1
Repeat count [5]: 100
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 201.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100, 100-byte ICMP Echos to 203.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 201.1.1.1
.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (99/100), round-trip min/avg/max = 44/46/52 ms

After we have successfully sent traffic to the remote crypto endpoints, we must then verify that it was successfully encrypted by the IPsec crypto engine. Example 3-7 provides the active IKE and IPsec SAs resident in the crypto engine for AS1-7304A. Note that the SAs with IDs 1 and 2 have not increased their packet count. This is expected, because these are the ISAKMP SAs (the same ones previously displayed in Example 3-4). Because IPsec SAs are unidirectional, we confirm that there are 4 SAs present in AS1-7304A's SADB:

• SA ID #2000: Inbound SA to AS2-3745A
• SA ID #2001: Outbound SA from AS2-3745A
• SA ID #2002: Inbound SA from AS3-3745A
• SA ID #2003: Outbound SA to AS3-3745A

We can confirm that the SA from AS1-7304A is actively encrypting echo requests to AS2-374A (99/100 corresponds to the success rate of Example 3-6) and that the SA received from AS2-3745A is actively decrypting the echo replies sent from AS2-3745A to AS1-7304A (also 99/100, corresponding to the success rate of Example 3-6). The same behavior is confirmed for the two SAs built between AS1-7304A and AS3-3745A (Example 3-7, SA ID #2002 and #2003).

Example 3-7. Crypto Engine Verification

AS1-7304A#show crypto engine connections 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
2000 Se0/0.12      200.1.1.1     set    HMAC_SHA+AES_CBC          0       99
2001 Se0/0.12      200.1.1.1     set    HMAC_SHA+AES_CBC         99        0
2002 Se0/0.13      200.1.1.9     set    HMAC_SHA+AES_CBC          0       99
2003 Se0/0.13      200.1.1.9     set    HMAC_SHA+AES_CBC         99        0

Site-to-Site Architectural Overview over a Routed Domain

The design considerations of a site-to-site IPsec VPN change considerably once the underlying transit media changes. Consider the preceding site-to-site IPsec VPN example—how would our design change if we were to replace the existing dedicated DS-3 links between ASs with DS-3 uplinks to an Internet service provider? Network designers face the challenge of dealing with multicast traffic in the crypto switching path.

Multicast traffic, including Interior Gateway Protocol (IGP) multicast hellos and multicast data feeds, cannot be sent natively across an IPsec VPN tunnel. Instead, the multicast data must be encapsulated with unicast header (such as IP generic routing encapsulation (GRE)) before being presented to the IPsec crypto engine.

Typically, these design considerations have encouraged the use of leased-line connectivity for VPN extension and the insertion of GRE tunnels through the IPsec tunnel (commonly referred to as IPsec+GRE) to accommodate the multicast traffic associated with the routing protocol updates and hellos. The need for enterprise connectivity extension across intermediate routed domains is growing rapidly. Two common enterprise IPsec deployments that are driving this growth are corporate extranet deployments and RAVPN deployments.

Consider the following example, in which a large automotive manufacturer wants to securely extend connectivity from its corporate headquarters network to a series of smaller home offices over an independently maintained routed domain, such as the Internet. The smaller branch offices consist of a number of routed nodes and, as such, would benefit from getting Route Processor (RP) updates from the campus network. Figure 3-3 demonstrates how the addition of a site-to-site IPsec VPN across the independently maintained routed domain would preclude the smaller home offices from exchanging RP updates with the campus network at the corporate HQ.

Due to IPsec's inability to natively encrypt multicast traffic, the design in Figure 3-3 presents the following design considerations:

• When the branches recover from Integrated Services Digital Network (ISDN) failover, routing protocol updates to from Branch1 and Branch2 will not be encrypted. In this scenario, IGP updates are multicast based and will not be included in the crypto switching path.
• Any changes that occur in Branch1 Net and Branch2 Net will trigger RP update information to the corporate HQ. These updates will be sent in the clear.
• Any changes within the "HQ Campus Net" will trigger RP updates to the branches that will be sent in the clear.

The solution to these design considerations is to add GRE tunnels to the IPsec VPN implementation. RP traffic between the corporate HQ and branch networks will then be encapsulated with GRE headers and forwarded in the crypto switching path across the ISP network. We will discuss IPsec+GRE architectures in greater detail later in this chapter.

Consider the following example, in which a corporation, a large global financial organization, wants to allow extranet connectivity to its partners. The primary use of this extranet connection is to stream multicast data containing video and market information to decision makers within the global financial organization. This must be done securely and with confidentiality. The insertion of an independently maintained routed domain between the corporate extranet partner and the global financial organization breaks the multicast tree between the two parties, as illustrated in Figure 3-4.

The extranet model breaks multicast in two areas. First, underlying media is not configured to support peripheral interface manager (PIM) or multicast routing. Therefore, even without IPsec, the multicast tree would never form properly with this deployment. Second, assuming that the multicast tree could be established, IPsec would fail to send multicast flow in ciphered format. Again, the addition of GRE to the corporate extranet would allow extension of PIM traffic across the Internet. Additionally, because the PIM updates are encapsulated in GRE prior to encryption, the PIM packets encapsulated in GRE would be processed in the crypto switching path and forwarded securely across the IPsec VPN.