IPsec VPN Termination On-a-Stick

When referring to technologies "on-a-stick," we are typically describing a scenario in which the device performing that technical function is attached to the network using a single interface. Common examples that can reside "on-a-stick" include router-on-a-stick, NAT-on-a-stick, and IPsec VPN termination-on-a-stick. In this section, we will discuss the latest of the three, focusing on IPsec Virtual Private Network (VPN) deployment scenarios in which one or both IPsec VPN tunnel termination points are attached out-of-path using a single physical interface for network connectivity.

IPsec with Router-on-a-Stick Design Overview

Although they do exist in many network deployments, cases in which administrators would opt for IPsec VPN tunnel termination "on-a-stick" are rare. Furthermore, of those existing cases, this design option is most commonly used as an alternative to accommodate other areas of the network architecture, rather than as an option that an administrator would choose over in-path IPsec VPN design options discussed previously.

IPsec termination on-a-stick refers to a deployment scenario in which the IPsec tunnel termination point is attached to the network using a single network interface. As such, this design option places crypto and IPsec functionality outside of the data path, as illustrated in Figure 10-1.

Figure 10-1. IPsec VPN Tunnel Termination "On-a-Stick"

Figure 10-1 depicts a rare scenario in which IPsec using router-on-a-stick is required. Let's now discuss some of the circumstances that force this scenario to exist.

Single, Flatly Addressed L3 Domain

The key design driver here is that the cable modem and integrated bridge provides only one flat Layer 2 domain for devices to attach to. Although it is rare to see a VPN concentrator with one interface (most devices will ship with multiple interfaces to reside in-path), the bridged layout of this network design on the LAN side presents only one interface from a L3 perspective. In other words, a second interface on the VPN concentrator or router would yield no benefit, as one would be unable to assign it an IP address (it would conflict with the other interface connected to the bridged domain).

Lack of In-Path Design Options

The flat L3 network forces the IPsec VPN tunnel outside of the data path. Due to the fact that only one L3 interface can be attached to this bridged LAN, the encryptor is unable to reside inside the unencrypted data path.

Note

In-Path and Out-of-Path refer to the path of the unencrypted data flows. The encrypted data must flow through the IPsec VPN tunnel endpoint, even in "on-a-stick" implementations. In-Path versus Out-of-Path comparisons are discussed later in this chapter.

In this situation, IPsec VPN tunnel termination "on-a-stick" can be used to provide encryption for resources on the bridged LAN in Figure 10-1. This design option involves several components, some of which are unique to this design.

Single Interface to the Bridged LAN

This interface resides outside of the unencrypted data path. This requires that network resources traversing the VPN tunnel use the IP address of the IPsec VPN tunnel termination point that connects to the bridged LAN as their default gateways.

Crypto-Enabled Loopback Interface

This interface essentially serves as the crypto interface used to terminate the IPsec VPN tunnel. In Chapter 6, "Solutions for Local Site-to-Site High Availability," we discussed the use of a loopback interface to terminate the IPsec VPN tunnel for local High Availability (HA). In this situation, we will actually apply the crypto map to the loopback interface itself and loop encrypted traffic back onto the bridged LAN. Figure 10-2 displays this operation.

Figure 10-2. IPsec VPN Tunnel Termination On-a-Stick Using Loopback Interfaces for Crypto

The process in Figure 10-2 is as follows:

1.	The IPsec VPN gateway (router-on-a-stick) in Figure 10-2 receives traffic from the bridged LAN. This traffic is in cleartext format.
2.	The router forwards the traffic to its loopback interface. The router inspects the traffic, matching it to a crypto ACL referenced in the crypto map that is applied to the crypto interface. The crypto engine applies the appropriate transform to the data matching the crypto ACL.
3.	The router forwards the traffic from step 2 on to the bridged LAN. The traffic is now in ciphered format, destined for the other end of the IPsec VPN tunnel.

Note

These steps described vary slightly from the ones outlined in the ensuing case study, as the case study includes IPsec VPN tunnel termination on-a-stick and Network Address Translation (NAT) on-a-stick, while the example we have just discussed includes only IPsec VPN tunnel termination on-a-stick without NAT.

Let's now take a look at a case study that will illustrate the operation of IPsec VPN tunnel termination "on-a-stick," including a real-world scenario in which this rare choice of IPsec design is used and working configurations.

Case Study: Small Branch IPsec VPN Tunnel Termination with NAT On-a-Stick

In this section, we will discuss a scenario in which a large company in retail wants to deploy secure, low-cost IP communications at each of its stores globally. At each branch location, there are server applications that collect and store customer information and financial data. That data must be reliably relayed to centralized data storage facilities in the company's data center, which is centrally located at the corporation's headquarters. For this reason, the customer is interested in a simple, low-cost solution for relaying this information from their many retail locations over the WAN to the data center at the corporate HQ. The corporate IT staff is interested in using an Internet managed service to provide the WAN connectivity to HQ to meet several critical business objectives, including:

• Support for many branches makes a low-cost managed solution a business requirement, as scaling the solution to the many branches will drive costs up regardless of the per-unit cost.

• Data confidentiality is a business requirement, as confidential customer information (account numbers, marketing data) is required to be transmitted across a public domain (the Internet).

• Multiple point-of-sale machines and small-scale servers at the remote retail location require a low-cost LAN solution (multiple Ethernet ports at the retail branch).

The corporation's IT staff has been in contact with several service providers who will offer managed services that may meet the retailer's business requirement. The managed service offers basic IP connectivity using a cable modem at the remote retail location. The service also includes a workgroup switch for connecting devices together on the retailer's LAN, but the functionality of the switch is very basic and therefore does not include support VLANs or 802.1q trunking. Given the retailer's business objectives, these circumstances present design challenges at the retailer's remote locations, including the following:

• Limited publicly routable IP addressing space at the remote retail locations

• No NAT functionality integrated in to the managed service offering

• Lack of capabilities for providing data confidentiality (such as using IPsec or crypto) between the remote retail location and the corporate HQ

• Lack of VLAN awareness on the managed service switch at the remote retail location supports only one L3 broadcast domain at the remote retail LAN

The retailer agrees to a small pilot of the Internet service provider's (ISP's) managed service. As depicted in remote retail store LAN pilot topology in Figure 10-1, the corporate IT staff elects to use a small IPsec-enabled router, such as the Cisco 1845 ISR, to enable two key services at the remote retail locationData Confidentiality (IPsec) and NAT. Let us take a quick step-by-step look at the life of a packet on egress from the remote retail LAN en route to centralized corporate resources before diving in to some configuration examples for enabling data confidentiality and NAT in "on-a-stick" environments:

1.	Hosts and servers on the remote retail branch LAN initiate communications with centralized corporate resources using a default gateway of 192.168.1.2 on the 1845ISR.
2.	The 1845 receives the traffic from step 1 and matches it to an ACL referenced in a route-map that is used for policy routing. The policy route sets the output interface for traffic matching the ACL to router's loopback201 address.
3.	Before making the forwarding decision described in step 2, the 1845ISR applies the NAT rules defined on the router, as the traffic matches the ACL referenced in the NAT configuration on the router and was received on the inside NAT interface (FastEthernet0/0).
4.	The traffic is forwarded to the loopback201 interface based on the rules defined in the policy routing configuration on the 1845ISR. The privately addressed source IP is translated in to the loopback201 IP (the outside NAT interface), which is publicly routable.
5.	The traffic translated using NAT in step 4 matches a crypto ACL referenced by a crypto map applied to the loopback201 interface. Before forwarding the traffic, the 1845ISR processes the traffic with the appropriate transform.
6.	The 1845ISR forwards the crypto-processed transform to the opposite end of the IPsec VPN tunnel. The packet is now encapsulated with Encapsulating Security Payload (ESP), and the outer IP header is populated with publicly routable IP addresses (the IP addresses of the IPsec peers agreed upon in Phase 2 SA negotiation).

Data confidentiality is required across the WAN using IPsec VPN tunnel termination. The IPsec VPN gateway at the remote branch resides out-of-path, and is therefore considered to be deployed "on-a-stick." This out-of-path design option was selected for the retailer's pilot program due to the fact that the branch LAN switch is incapable of providing multiple L3 domains. As such, only one L3 domain is presented to the IPsec VPN-enabled router on-a-stick, supporting only a single L2 connection between the router and the switch.

Example 10-1 provides a configuration for the retail branch LAN's IPsec VPN gateway. The IPsec VPN gateway is configured to use the ESP-3DES with MD5 HMAC authentication on data sent to and received from the remote IPsec VPN gateway at 24.10.100.1, as illustrated in configuration lines 10 and 20, respectively. Note that, in line 20, the crypto map is applied to the loopback interface rather than a physical interface. It is important to note that the crypto map matches ACL 102 specifying the inside global IP address space as the source. This is because encryption occurs after NAT when the two are configured concurrently. As illustrated in Example 10-2, all traffic to be translated on-a-stick is policy routed to loopback 201. This enables traffic from the 10.0.0.0/8 address space on the retailer's LAN to be NAT'd between inside (e0/0) and outside (lo201) before being encrypted using the crypto map on loopback 201. Provided in line 26 is the crypto ACL used by the retail branch LAN VPN gateway. Note that the source IP address space is the inside global address space. This configuration is required for IPsec to properly agree upon consistent protected address space when negotiating a Phase 2 SA, as encryption occurs after NAT. If not properly configured with the correct addresses, a crypto ACL scope inconsistency can cause Phase 2 negotiation to fail.

Example 10-1. IPsec VPN Tunnel Termination "On-a-Stick" Using Logical (Loopback) Interfaces

C1845-VPN10-A#show running-config Building configuration... ! #<--Output Suppressedà ! crypto isakmp policy 10 authentication pre-share crypto isakmp key cisco address 24.10.100.1 ! crypto IPsec transform-set c10-on-a-stick esp-3des esp-md5-hmac ! crypto map on-a-stick 10 IPsec-isakmp  set peer 24.10.100.1  set transform-set c10-on-a-stick  match address 102  !  #<--Output Suppressedà  !  interface Loopback201   ip address 201.1.1.1 255.255.255.0   ip nat outside   crypto map on-a-stick  !  #<--Output Suppressedà  !  access-list 102 permit ip 200.1.1.0 0.0.0.3 11.0.0.0 0.255.255.255  !  #<--Output Suppressedà

NAT on-a-stick supports IP communications with privately addressed devices across a publicly addressed infrastructure. In this case, the retailer has not been given enough publicly routable address space for all of the IP-enabled resources to communicate across the Internet. Therefore NAT must be used to translate the privately addressed IP addresses in to public ones so that they can be routed across the Internet to the retailer's data center at its HQ. Because there is only one connection between the IPsec VPN-enabled router and the remote retail site's LAN switch, like IPsec VPN tunnel termination, this service must also exist "on-a-stick." Example 10-2 provides a sample NAT on-a-stick configuration that the retail branch LAN IPsec VPN gateway uses in conjunction with its IPsec VPN tunnel termination configuration on-a-stick in Example 10-1.

Example 10-2. Network Address Translation "On-a-Stick" Using Logical (Loopback) Interfaces

C1845-VPN10-A#sh run Building configuration... ! #<--Output Suppressedà ! interface Loopback10  ip address 10.1.2.1 255.255.255.252  ip nat outside ! interface Ethernet0/0  ip address 192.168.1.2 255.255.255.248 secondary  ip address 10.1.1.1 255.255.255.0  ip nat inside  ip policy route-map on-a-stick  half-duplex ! #<--Output Suppressedà ! ip nat pool public 200.1.1.1 200.1.1.4 prefix-length 29 ip nat inside source list 1 pool public overload ! #<--Output Suppressedà ! ip route 0.0.0.0 0.0.0.0 192.168.1.1 ! ! access-list 1 permit 10.0.0.0 0.255.255.255 access-list 101 permit ip any 200.1.1.0 0.0.0.7 access-list 101 permit ip 10.0.0.0 0.255.255.255 any ! route-map on-a-stick permit 10  match ip address 101  set interface Loopback10 ! #<--Output Suppressedà

Once the appropriate configurations have been put in place, the retailer takes several measures to ensure that the operation of the IPsec VPN router on-a-stick is working correctly with NAT:

• Verify that private addresses are being translated in to routable address space as in Example 10-3.

  Example 10-3. Verifying NAT "On-a-Stick" Operations

  C1845-VPN10-A#debug ip nat IP NAT debugging is on crvpn-3600-b# *Mar  2 23:23:21.732: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [400] *Mar  2 23:23:21.748: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [400] *Mar  2 23:23:21.756: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [401] *Mar  2 23:23:21.768: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [401] *Mar  2 23:23:21.776: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [402] *Mar  2 23:23:21.792: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [402] *Mar  2 23:23:21.796: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [403] *Mar  2 23:23:21.812: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [403] *Mar  2 23:23:21.816: NAT: s=10.1.1.100->200.1.1.1, d=11.1.1.1 [404] *Mar  2 23:23:21.832: NAT: s=11.1.1.1, d=200.1.1.1->10.1.1.100 [404]

• Verify that Internet Key Exchange (IKE) and IPsec security associations (SAs) can be established between the device on-a-stick and the opposite endpoint of the IPsec VPN tunnel as in Example 10-4.

  Example 10-4. Verifying Phase 1 and 2 IPsec SA Establishment

  C1845-VPN10-A#show crypto isakmp sa dst             src             state          conn-id slot 24.10.100.1     201.1.1.1       QM_IDLE              4    0 C3800-VPN10-A#sh crypto IPsec sa interface: Loopback201     Crypto map tag: on-a-stick, local addr. 201.1.1.1     protected vrf:     local ident (addr/mask/prot/port): (200.1.1.0/255.255.255.252/0/0)     remote ident (addr/mask/prot/port): (11.0.0.0/255.0.0.0/0/0)     current_peer: 24.10.100.1:500       PERMIT, flags={origin_is_acl,}      #pkts encaps: 14, #pkts encrypt: 14, #pkts digest 14      #pkts decaps: 14, #pkts decrypt: 14, #pkts verify 14      #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.: 201.1.1.1, remote crypto endpt.: 24.10.100.1       path mtu 1514, ip mtu 1514, ip mtu idb Loopback201       current outbound spi: CD72F170       inbound esp sas:        spi: 0xF8F64DEB(4176891371)          transform: esp-3des esp-md5-hmac ,          in use settings ={Tunnel, }          slot: 0, conn id: 2000, flow_id: 1, crypto map: on-a-stick          sa timing: remaining key lifetime (k/sec): (4535979/1289)          IV size: 8 bytes          replay detection support: Y       inbound ah sas:       inbound pcp sas:       outbound esp sas:        spi: 0xCD72F170(3446862192)          transform: esp-3des esp-md5-hmac ,          in use settings ={Tunnel, }          slot: 0, conn id: 2001, flow_id: 2, crypto map: on-a-stick          sa timing: remaining key lifetime (k/sec): (4535979/1287)          IV size: 8 bytes          replay detection support: Y      outbound ah sas:      outbound pcp sas: C1845-VPN10-A#show crypto engine connections active   ID Interface            IP-Address      State  Algorithm           Encrypt  Decrypt    4 Loopback201          201.1.1.1       set    HMAC_SHA+DES_56_CB        0        0 2000 Loopback201          201.1.1.1       set    HMAC_MD5+3DES_56_C        0       14 2001 Loopback201          201.1.1.1       set    HMAC_MD5+3DES_56_C       14        0

• Verify that the negotiation of the IPsec VPN tunnel can be initiated from either endpoint, and that no conflicts reside with NAT at the remote retail branch running IPsec and NAT on-a-stick.