Home > Articles > Cisco Network Technology > IP Communications/VoIP > Basic IPsec VPN Topologies and Configurations

Basic IPsec VPN Topologies and Configurations

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Sep 29, 2006.

Chapter Description

In this chapter, you will review several common deployments of IPsec virtual private networks (VPNs).

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.

vp460301.gif

Figure 3-1 High-Level Configuration Process for IPsec VPN

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.)
  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.

vp460302.gif

Figure 3-2 Site-to-Site IPsec VPN Topology Using Dedicated T-1 Circuits for Communications

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.

vp460303.gif

Figure 3-3 IPsec RAVPN Extension to Small Home Office over the Internet

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.

vp460304.gif

Figure 3-4 Corporate Extranet Connection Using Internet Uplinks and IPsec VPNs

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.

2. Site-to-Site IPsec VPN Deployments and GRE (IPsec+GRE) | Next Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020