Planning for Mobile Worker Implementations
This section examines the challenges of connecting an increasingly mobile workforce. Mobile workers have become power users who may not even need a full-time office but require a professional environment and support services on-demand. From collaboration to presence services, remote-access solutions are an extension of the converged network and present similar requirements in terms of security, quality of service (QoS), and management transparency.
Connecting a Mobile Worker
The enterprise mobile worker solution provides an always-on, secure, centrally managed connection from multiple global locations to the corporate network. It enables businesses to meet several requirements, including the following:
-
Provide continuity of operations in case of loss of access to the workplace by inclement weather, commuter issues, man-made and natural disasters, and so on
-
Increase responsiveness across geographical, functional, business, and decision-making boundaries
-
Provide secure, reliable, manageable employee access to critical network assets and confidential information
-
Cost-effectively extend data, voice, video, and real-time applications over a common network connection
-
Increase employee productivity, satisfaction, and retention
The first consideration that needs to be addressed when connecting the mobile worker is the choice of a suitable network access technology.
The mobile worker typically uses diverse applications, such as e-mail, web-based applications, mission-critical applications, real-time collaboration, voice, video, and videoconferencing, many of which require a high-bandwidth connection. Therefore, the first factors to consider in a remote connectivity solution are the access network technology and the bandwidth availability.
Possible options to provide high bandwidth include residential cable, DSL, and wireless solutions. Further considerations involve infrastructure services options, such as the following:
-
IPsec and Secure Sockets Layer (SSL) VPNs— Establish a secure tunnel over existing broadband connections between the mobile worker’s remote sites, and from laptops and desktops, and the central site. Site-to-site VPNs are used to achieve an always-on transparent VPN connection for home users. Remote-access VPNs are used to provide an on-demand secured connection from multiple locations. The choice of IPsec or SSL VPNs depends on multiple factors such as choice of applications, end-point management issues, and others.
-
Security— You want security to safeguard the corporate network and prevent unguarded back doors. The security measures are achieved by deploying firewall, intrusion prevention, and URL filtering services. Depending on the enterprise corporate security policy, split tunneling may be used to share the broadband connection between secured corporate access and unsecured Internet access at the same time. Split tunneling allows the remote worker to access public Internet sites while connected to the private network, and might result in security concerns.
-
Authentication— Authentication defines who gets access to resources and is achieved by deploying identity-based network services with authentication using AAA servers, 802.1X port-based access control, Cisco security, and trust agents.
-
QoS— Quality of service addresses application availability and behavior. The QoS mechanisms have to be used to prioritize the traffic, optimize the use of WAN bandwidth, address the difference in uplink and downlink speed of a broadband connection, and achieve adequate performance for applications sensitive to delay and jitter, such as voice and video.
-
Management— Management addresses the complexity of support and the loss of corporate control. IT centrally manages and supports the mobile worker connection and equipment, and transparently configures and pushes security and other policies to the remote devices. Tools can be used to implement performance and fault management and to monitor service level agreements (SLAs).
Components for Mobile Workers
The mobile worker solution is made up of three major components: components located at the mobile worker’s remote site; corporate components, and optional IP telephony and other services; which are sometimes embedded into the worker’s laptop via soft phones and other applications.
The required home office components are broadband access (cable, satellite, or DSL), remote VPN router with QoS functionality, and laptop or desktop. The optional components include IP phone, wireless LAN (WLAN) access point, and Cisco video telephony (VT) camera. However, mobile workers may want to connect from multiple locations, and in some of those locations a laptop is all they have. The rest of the infrastructure is facilitated by an increasingly welcoming business and public infrastructure that provides broadband access and basic wireless connectivity.
Corporate components are a VPN headend router or a multifunction security appliance such as the Cisco Adaptive Security Appliance (ASA), authentication, and central management devices for resilient aggregation and termination of the IPsec and SSL VPN tunnels.
The optional IP telephony components are Cisco Unified CallManager for call processing, signaling, and device control; voice gateway for interconnection of traditional phone networks with VoIP environments; IP phones for voice and added-value services; and a voice messaging platform for diverse message consolidation. And, do not forget, Cisco Contact Center for advanced call treatment.
The traditional mobile worker solution is based on a software VPN client on the remote user laptop or desktop PC. This setup is characterized by these drawbacks:
-
Lower level of accessibility (for example, the inability to deploy and support advanced applications, such as voice, video, and videoconferencing)
-
No QoS for efficient delivery and prioritization of traffic
-
Inadequate security, with security relying on the end user (with IT maintaining no control)
-
Absence of controlled configuration, management, and support by IT (and end users having to perform these functions)
The business-ready mobile worker solution overcomes all the weak points of the traditional mobile worker solution. Business-Ready model replaces the traditional model for mobile worker connectivity.
Business-Ready Mobile Worker and VPN Options
The business-ready mobile worker solution is driven by the explosion in broadband access, especially wireless connectivity in recent years. From Wi-Fi to WiMAX to 3G and 4G efforts on the cellular wireless spectrum, more and more mobile workers can connect to corporate resources. As workers roam across wireless networks, their connectivity might be affected because of automatic IP address changes, performed by DHCP or different IP address pools. Roaming transparency is required to make transitions smooth and allow for uninterrupted connectivity across wireless cells, even inside the organization campus.
With the advent of SSL VPNs, the mobile worker obtains access from unmanaged devices and from a multitude of locations. This results in a variety of security concerns. The likelihood of connecting from vulnerable or even already infected machine makes integrated endpoint security one of the most important features of any mobile worker solution. Cisco’s NAC (Network Admission Control) overcomes this issue.
Central management of the mobile worker and his components is also crucial. The challenge becomes providing support to potentially thousands of users connecting from all over the world 24x7. Cisco efforts such as Easy VPN and the Cisco Security Manager (CSM) allow for central policy management and automated deployment of those policies. A reliable architecture complements the solution, typically using multiple VPN concentrators acting as headends and providing redundancy and resiliency.
Ultimately, mobility solutions must contemplate all the resources and conditions the mobile worker finds at the physical office. The tools of the trade for this virtual office must include the security, management, flexibility, and transparency features we have discussed.
When we consider remote-access and mobile worker solutions, IPsec and SSL VPNs become clear options. Table 7-12 presents a condensed view of the characteristics of both IPsec VPN and SSL VPN solutions.
Table 7-12: Characteristics of IPsec and SSL VPN Solutions
Open table as spreadsheet | IPsec VPN | SSL VPN |
| Is a client-based technology | Is a clientless technology—reduces operations costs associated with managing client software |
| Provides full tunnel access, with all applications supported | Provides optional full tunnel access, but may suffer from application interoperability issues |
| Uses IPsec—a well-proven technology | Uses SSL—a well-proven technology |
| Operates well for extending access to employees using company-managed devices | Simplifies business partner access |
| — | Provides “anywhere” access from unmanaged devices |
| — | Enables customized access portals |
The transparency of IPsec VPNs in terms of application support is offset by the need for client software installed at the connecting machine. SSL VPNs provide clientless technology, if we consider the web browser application to be ubiquitous and already installed in the most popular laptop and desktop operating systems. This comes at the expense of application support, as some nonweb applications may require additional components to the solution. When looked at from the security perspective, both technologies allow access into mission critical assets, and both require integrated endpoint security controls. SSL VPNs may need to enforce more stringent security policies, because they are typically used to connect from nonmanaged devices.
Ultimately, both technologies will integrate into your remote-access solution, to provide effective connectivity for both managed and unmanaged devices.
Routing Traffic to the Mobile Worker
Now that you have learned about the components and technologies used by mobile workers, this section describes the preparation and configuration necessary to provide them access to the corporate network. This section shows you, using a simple scenario, the tasks for the implementation plan, focusing on the configuration of network elements such as routers and switches.
In a real-world scenario, deploying remote-access networks for mobile worker connectivity requires careful planning. If we look at the overall, end-to-end solution, we must consider several steps and service areas in building such solution. Perhaps our first decision is the choice of VPN solutions. For business-ready teleworkers, this will probably be an IPsec site-to-site VPN, from their home office router into the headend VPN router. For mobile, traveling users, SSL VPNs are gaining ground as the solution of choice.
Any remote-access solution must consider security and access control. VPNs provide confidentiality, integrity, and authentication, but the private network will require access control and threat mitigation. So from identity management via AAA services, to firewall deployment, to intrusion prevention technologies, our mobile worker solution must consider these services as part of the overall security policy.
The remote teleworker will require local services that facilitate the VPN connection and enable productivity. Mobility through wireless, along with the support services encompassing wireless solutions, is key. This includes wireless security through authentication and encryption, such as using 802.1X.
In most cases, the remote user will enhance productivity by using data, voice, presence, and multimedia services. QoS becomes crucial, and must be carefully planned. It is also important to provision all of these services to be automated, centralized, and policy based. The Cisco Easy VPN solution centralizes policy in the headend device, such as a Cisco VPN router or the ASA firewall, and pushes those policies to connecting clients at the moment of connection.
The following components are required to provide remote access to mobile workers:
-
VPN router (for example, Cisco Easy VPN server)
-
Mobile worker device (for example, Cisco Easy VPN client)
-
IPsec VPN tunnel
-
Internet connectivity
Now let’s take a look at how we can configure the VPN router and the mobile worker device and the necessary IPsec VPN tunnel, starting with the VPN router configuration.
VPN Headend Configuration
The headend VPN router is also known as the Easy VPN server in Easy VPN terminology. It concentrates the bulk of the remote-end configuration, which “pushes” the policies to the client at the moment of connection. The remote end, the device used by the mobile worker, is known in Easy VPN terminology as the Easy VPN remote or Easy VPN client. The Easy VPN remote device starts an IPsec VPN tunnel to connect to the Easy VPN server across the public network.
The following steps are required to configure a router as an Easy VPN server:
We first need to allow IPsec traffic through the Internet-facing device, such as a perimeter router or a firewall. It is also possible that our headend VPN router is the Internet-facing device.
To provide VPN services, we will define a pool of addresses that will provide routing and addressing for remote users. We will define address pools for connecting clients in the private network. The address pools defined in this step will be used as part of the VPN configuration.
Next, we will confirm that the address pools configured in Step 2 are known across the network, and therefore proper routing of remote clients’ return traffic is assured. This is sometimes a hidden and obscure part of the configuration, because it is often assumed that the VPN architecture will provide routing to its subnets.
Then, we will tune NAT so that VPN traffic bypasses that function and it is not translated. As mentioned earlier, one of the functions of IPsec is to tunnel the traffic. The traffic is tunneled into a new IP header expressly so the original header is not changed.
The last step is to verify VPN configuration and operations, using verification commands that will help us identify the main components and proper operation of the VPN service.
The following subsection cover, in detail, each VPN router configuration step. Remember that our network security team has already configured the routers for VPN access. It is our responsibility as the routing team to check that it works. This verification will be done with show commands, and with tools such as ping and trace. When required, we will amend the routing configuration of the router, but will not touch its security configuration.
Allowing IPsec Traffic
Our first step is to make sure we are allowing IPsec traffic in our VPN router. This router is probably an Internet edge network element. It is in an ideal position to provide access control services through firewalling. Most likely, this router is running some sort of firewall service, or at least ACLs to implement antispoofing mechanisms and other security controls.
To check whether ACLs are filtering traffic on the router, use the show ip interface command and the show access-lists commands.
IPsec traffic needs to be allowed through those security controls on the Internet-facing interface so that the router can, in fact, terminate IPsec VPN tunnels. There are different types of Cisco IOS firewalls:
-
A classic firewall is based on ACLs, and is the more traditional approach to firewalling in a Cisco IOS router. This classical approach is referred to context-based access control (CBAC).
-
A zone-based firewall (ZBF) is based on security zones and access, and it is the more recent approach to implementing the service in routers. It is important to identify which type of firewall we have, to determine the component we need to change to allow IPsec traffic through the firewall.
The show ip inspect command gives you the details on the classic firewall. A subset of the show ip inspect command is explained in Table 7-13.
Table 7-13: show ip inspect Command
Open table as spreadsheet | Parameter | Description |
| name inspection-name | Displays the configured inspection rule with the name inspection-name |
| interfaces | Displays the interface configuration with respect to applied inspection rules and access lists |
Use the show zone-pair security command, shown in Table 7-14, to display information about the zone-based firewall.
Table 7-14: show zone-pair security Command
Open table as spreadsheet | Parameter | Description |
| source source-zone-name | (Optional) Name of the source zone |
| destination destination-zone-name | (Optional) Name of the destination zone |
Figure 7-25 illustrates the commands discussed in Table 7-13 and Table 7-14.
Example 7-55 shows the result of the show ip interface fa0/1 command, that there is an inbound access list called FIREWALL-INBOUND applied to interface Fa0/1.
Example 7-55: show ip interface Command on R1
R1#show ip interface fa0/1
Now, using the show access-lists command, shown in Example 7-56, we will find the details of the FIREWALL-INBOUND access list applied on interface fa0/1 of R1.
Example 7-56: show access-lists Command on R1
R1#show access-lists
Extended IP access list FIREWALL-INBOUND
10 permit eigrp any any (1452 matches)
20 permit tcp any any eq telnet
30 permit icmp any any (20 matches)
40 permit tcp any host 192.168.1.10 eq www
50 permit tcp any host 192.168.1.10 eq ftp
60 permit udp any any eq domain
Extended IP access list NAT-ACL
10 permit ip 10.6.6.0 0.0.0.255 any (2 matches)
Extended IP access list SPLIT
10 permit ip 10.6.6.0 0.0.0.255 172.31.7.0 0.0.0.255
20 deny ip any any
R1#
The access list called FIREWALL-INBOUND, currently configured in R1, could be part of a bigger firewalling strategy, and therefore we need to investigate further whether our IOS router is configured to act as a firewall.
Using the show ip inspect interfaces command, shown in Example 7-57, we find out that we have a classic firewall configured inbound on R1. We can also see which access lists are involved in the access control process, so we can quickly make a note and proceed to change the ACLs to allow IPsec traffic. In Example 7-57, the access list is conveniently called FIREWALL-INBOUND, which we looked at earlier.
Example 7-57: show ip inspect interfaces Command on R1
R1#show ip inspect interfaces
Interface Configuration
Interface FastEthernet0/0
Inbound inspection rule is INSPECTION
tcp alert is on audit-trail is off timeout 3600
udp alert is on audit-trail is off timeout 30
icmp alert is on audit-trail is off timeout 10
Outgoing inspection rule is not set
Inbound access list is ALL
Outgoing access list is not set
Interface FastEthernet0/1
Inbound inspection rule is INSPECTION
tcp alert is on audit-trail is off timeout 3600
udp alert is on audit-trail is off timeout 30
icmp alert is on audit-trail is off timeout 10
Outgoing inspection rule is not set
Inbound access list is FIREWALL-INBOUND
Outgoing access list is not set
R1#
If we attempt to do the show zone-pair security command on R1, we will see that zone-based firewall has not been configured, as shown in Example 7-58.
Example 7-58: show zone-pair security Command on R1
R1#show zone-pair security
R1#
| Note | It is possible to have both ZBF and CBAC configured on the same router but on a different interface. An interface cannot be configured with CBAC and ZBF at the same time. |
Now that we know what kind of firewall we are dealing with for R1, let’s add the IPsec support to the ACL. IPsec uses ESP to provide confidentiality through encryption. ESP, found at Layer 4 of the OSI model, uses protocol 50. IPsec can also AH if only integrity is required. AH uses protocol 51.
| Note | Many publications refer to ESP as using port 50 and AH as using port 51. This is wrong, because at Layer 4 we are referring to protocols not ports, such as in TCP being protocol 6 and UPD being protocol 17. See http://www.iana.org/assignments/protocol-numbers/ for confirmation. |
During the first stage of IPsec, peer negotiations and credentials are exchanged using a protocol called ISAKMP, UDP port 500 (sometimes erroneously called IKE, or Internet Key Exchange). ISAKMP is one of three components that make up IKE. Finally, UDP 4500 will need to be opened for NAT Traversal (NAT-T), another IPsec service. To recapitulate, here are the additional configurations to be added to the ACLs to prepare for VPN tunnels:
-
Protocol 50 (ESP)
-
Protocol 51 (AH)
-
UDP port 500 (ISAKMP)
-
UDP port 4500 (NAT-T)
Example 7-59 shows how to add those lines to our access list.
Example 7-59: Modifying the ACL on R1 to Support IPsec Protocols
R1(config)#ip access-list extended FIREWALL-INBOUND
R1(config-ext-nacl)#4 permit 50 any any
R1(config-ext-nacl)#5 permit 51 any any
R1(config-ext-nacl)#6 permit udp any any eq 500
R1(config-ext-nacl)#7 permit udp any any eq 4500
Defining Address Pools
The second step is to define IP address pools for the remote connecting clients. One might wonder why we need address pools for these VPN users. Of course, they already have an IP address to start with, which allows them to connect to the IP network, but we need to provide for the fact that we are using IPsec VPNs. With IPsec tunnels, IPsec VPNs encapsulate original traffic within an additional packet, to allow that private traffic to be routed across a public network.
But this is a virtual private network, so ultimately traffic needs to go between a private host and a private resource. The private host happens to be virtual in a VPN; it is really located outside of the private network. The encapsulation process will use private addressing in the original (encapsulated) packet and public addressing for the “outer” (encapsulation) packet. The private address of the connecting host is typically assigned dynamically for flexibility reasons.
The address pool should be planned carefully. It should be unused in the network and follow best practices in address assignment. For instance, you should define it to be a summarizable address block, so that is can later be easily and efficiently identified in access lists, or properly summarized by routing protocols.
The address pool is created locally at the VPN router, and later assigned to the VPN configuration.
The local pool at the router level is commonly used as a configuration alternative. Other options include DHCP servers sitting behind the router and the VPN client requesting the private address via DHCP. The router, at that point, acts as a DHCP relay agent. AAA servers, such as the Cisco Access Control Server (ACS), can also be used to provide a per-user or per-group address pool.
Use the ip local pool poolname first-address—last-address global command, described in Table 7-15, to create address pools.
Table 7-15: ip local pool Command
Open table as spreadsheet | Parameter | Description |
| source source-zone-name | (Optional) Name of the source zone |
| destination destination-zone-name | (Optional) Name of the destination zone |
Example 7-60 shows how to configure the address pool in R1. The global command used is ip local pool, as explained in Table 7-15. The pool must be given a name that will be assigned later to the IPsec VPN configuration. Notice that under the Easy VPN framework you could have a separate local pool for different user profiles using the IPsec VPN. This configuration granularity allows for even more flexibility in differentiating traffic from each user profile. In addition, you can apply different path, routing, and access policies to each profile.
Example 7-60: ip local pool Command on R1
R1#config t
Enter configuration commands, one per line. End with CNTL/Z
R1(config)#ip local pool EZVPN 10.254.254.1 10.254.254.254
R1(config)#
In Example 7-60, the address pool receives the name EZVPN. The range of addresses for the pool is 10.254.254.1 to 10.254.254.254. In this example, we allocated numbers that are easy to identify so that administrators can quickly know that this is the remote-access users when they see source addresses within this range when looking at various screen outputs such as routing tables, access lists, or in parts of the network configuration.
Providing Routing Services for VPN Subnets
The third step is to provide effective routing services so that traffic coming from VPN clients can reach internal resources and the return traffic can find its way back to those remote users.
It is worth saying that the VPN subnets, defined by the IP address pools allocated for remote-access clients, are ephemeral. They appear and disappear as VPN clients connect and disconnect. They must be known, though, to all routers in the internal network, or at least along the path of traffic flows that VPN clients will use.
Several methods, including the following, can be used to make those address pools known to routers in the internal network:
Proxy ARP is one of the simplest methods. It involves selecting the address pool as a subnet of an existing physical segment. An example of this method, shown in Figure 7-26, would consist of using for remote users the subnet 192.168.1.128/26 when the internal network is using subnet number 192.168.1.0/24.
One advantage of the method shown in Figure 7-26 is that you do not have to use additional subnets. Another advantage is that no changes are required to routers or routing protocols, because they already know this network. This reduces the complexity of the configuration. However, you must enable Proxy ARP on the VPN router’s interface connected to the internal segment containing the borrowed subnet.
Other methods are more dynamic but are also more complex. They will designate a separate, nonoverlapping subnet to be the address pool for remote-access VPN clients, as shown in Figure 7-27. This would require advertising that subnet using routing protocols.
A commonly used dynamic approach is to use a method known as reverse route injection (RRI). RRI is the ability for static routes to be automatically inserted into the routing process for those networks and hosts that are protected by a remote tunnel endpoint. This method injects the client’s host address in the routing table with the next hop to this network being the remote tunnel endpoint. After the static route is created on the VPN router, this information is propagated to upstream devices, allowing them to determine the appropriate VPN router to which to send returning traffic to maintain IPsec state flows. This “dynamic” injection happens only when a client is connected. If the client disconnects, the entry is removed from the routing table. RRI is an IPsec feature, configured within crypto map statements. The configuration of crypto map statements is beyond the scope of this book.
Finally, another way to provide routing services to remote users is a hybrid solution using static and dynamic features. This is achieved by creating a static route pointing to the remote-access address pool and then redistributing that particular static route into your routing protocol. The commands used are ip route and redistribute static metric {metric_value}, as described in Table 7-16.
Table 7-16: redistribute static Command
Open table as spreadsheet | Parameter | Description |
| metric metric_value | An optional parameter that specifies the EIGRP base metric, also referred to as the seed metric, in the order of bandwidth, delay, reliability, load, and maximum transmission unit, for the redistributed route, such as redistribute static metric 3000 100 255 1 1500 |
The configuration shown in Example 7-61 is a simple implementation of the commands appearing in Table 7-16.
Example 7-61: Configuring Static Route and Redistribution
R1(config)#ip route 10.254.254.0 255.255.255.0 192.168.1.2
R1(config)#
R1(config)#do show ip protocols
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 1
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.6.6.0 255.255.255.0
10.7.7.0 255.255.255.0
192.168.1.0
Passive Interface(s):
FastEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
10.5.7.10 90 3d03h
10.7.7.2 90 04:55:02
10.2.7.1 90 3d03h
10.3.7.1 90 3d00h
R1(config)#router eigrp 1
R1(config-router)#redistribute static
R1(config-router)#
In the example, we create a static route using the IP route 10.254.254.0 255.255.255.0 209.165.200.2. Notice that our static route points to R1 as the next hop, which is 209.165.200.2. This next hop is responsible for initiating and terminating VPN tunnels. We also use the show ip protocols command to confirm which routing protocol is already in use on R1. We discover that we are using EIGRP. Therefore, within EIGRP, we redistribute the static route. It is best practice to use route filters to ensure that only the desired routes are redistributed. It is also recommended that an appropriate metric be applied to these redistributed routes.
To verify proper redistribution, we look at the routing table of R2, shown in Example 7-62. We can see that R2 is aware of the remote-access VPN subnet, 10.254.254.0/24. As soon as our VPN clients connect to our corporate network, R2 will be able to route traffic back to them.
Example 7-62: Looking at the R2 Routing Table Following Redistribution of the Static Route
R2#sh ip route
Codes: C – connected, S- static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * - candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route
Gateway of last resort is not set
172.31.0.0/24 is subnetted, 1 subnets
D 172.31.7.0 [90/20517120] via 10.7.7.1, 04:57:56, Serial2/5
10.0.0.0/24 is subnetted, 5 subnets
D EX 10.254.254.0 [170/20514560] via 10.7.7.1, 00:00:29, Serial2/5
C 10.200.200.0 is directly connected, Loopback0
C 10.7.7.0 is directly connected, Serial2/5
D 10.6.6.0 [90/20514560] via 10.7.7.1, 04:57:21, Serial2/5
C 192.168.1.0 is directly connected, FastEthernet0/0
D 209.165.200.0/24 [90/20514560] via 10.7.7.1, 04:53:46, Serial2/5
R2#
Tuning NAT for VPN Traffic Flows
We will now turn our attention to tuning NAT for proper VPN operations. The tuning is often necessary because
-
The VPN router might be an Internet edge router providing NAT services.
-
VPN traffic need not be translated. It remains private when tunneled across the VPN.
-
A packet is processed through the NAT engine before it is forwarded to the IPsec engine.
-
NAT should be bypassed for VPN traffic because mobile worker VPN traffic is easily identified. It uses the VPN address pool as a destination.
Recall that IPsec encapsulates packets that use private addresses within a larger packet that uses public addressing to be routed across a public network. This action creates the IPsec tunnel.
The edge router shown in Figure 7-25 is providing NAT services for Internet traffic to acquire a public address. You can use the show ip nat statistics command, shown in Example 7-63, to verify this, and we confirm that R1 is configured for NAT with its Fa0/0 and S0/0/0 interfaces configured as inside NAT and its Fa0/1 configured as outside NAT. Also, notice the ACL used by the NAT rule. The NAT-ACL access list is defining which source address will have the privilege of being translated by an address found in the NAT pool named NAT-POOL.
Example 7-63: show ip nat statistics on R1
R1#show ip nat statistics
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Outside interfaces:
FastEthernet0/1
Inside interfaces:
FastEthernet0/1, Serial0/0/0
Hits: 20 Misses: 0
CEF Translated packets: 10, CEF Punted packets: 0
Expired translations: 0
Dynamic mappings:
— Inside Source
[Id: 1] access-list NAT-ACL pool NAT-POOL refcount 0
pool NAT-POOL: netmask 255.255.255.0
start 172.16.250.1 end 172.16.250.1
type generic, total addresses 1, allocated 0 (0%), misses 0
Queued Packets: 0
R1#
When we think about it, VPN traffic is not really Internet traffic. It happens to be private traffic using the Internet as a medium. But the traffic is not destined for an Internet, public site. The VPN-bound traffic, generated by our users, does not require a public address because it is intended to have a destination in the private network. Therefore, the traffic exchanged through the VPN tunnel, between our mobile worker and some internal corporate resources, should not be translated.
If we consider a router, packets are processed in a certain order, according to the services running on that router. NAT is processed before outbound IPsec encryption, so VPN traffic would be translated before it is sent through the tunnel. But as discussed in the preceding paragraph, we do not want translation to be done on the VPN traffic. Therefore, the router needs to be tuned for VPN traffic to bypass the NAT function. This is accomplished using an extended ACL. All other traffic that does not meet the criteria of the extended ACL will be processed by NAT.
NAT tuning is achieved by using either access lists or route map commands to define the traffic that will bypass translation. In any case, whether we use access lists or route maps, a permit line means “translate” and a deny line means “do not translate.”
Use the access-list command to define the addresses that will be subjected to translation in the route-map command. We will then need to apply the route map to the ip nat inside source command.
Example 7-64 demonstrates how an ACL and a route map are used to identify the traffic that will not be translated. We first create the access list, referencing the IP address pool as a destination address.
First, using an extended ACL, numbered 100, we define that traffic originating from any IP address, but with a destination of 10.254.254.0/24, addresses of our remote users, will be denied translation. We also add a second line to the ACL, specifying that all other IP traffic will be subjected to translation. The command is access-list 100 deny ip any 10.254.254.0 0.0.0.255. The VPN pool address is set as a destination, because the NAT configuration is relative to the view from the router, whose main job is to route packets, and therefore for the router, the VPN clients are from the outside interface, so they are destinations. An additional line is required: access-list 100 permit ip any any. Only VPN destinations should bypass translation. All other Internet-bound traffic must be translated. In Example 7-64, the route map called VPNTRAFFIC is set to match traffic according to an ACL 100, using the route-map VPNTRAFFIC command.
The next step is to apply the route map to the NAT configuration using the ip nat inside source route-map VPNTRAFFIC pool NAT-POOL overload command.
Example 7-64: Configuring VPN User Traffic to Bypass Address Translation
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#access-list 100 deny ip any 10.254.254.0 0.0.0.255
R1(config)#access-list 100 permit ip any any
R1(config)#route-map VPNTRAFFIC permit 10
R1(config-route-map)#match ip address 100
R1(config-route-map)#exit
R1(config)# ip nat inside source route-map VPNTRAFFIC pool NAT-POOL overload
Verifying IPsec VPN Configuration
The last step is to verify the existence and proper operations of the IPsec VPN. This will be achieved by having a look at the main configuration components and some commands to verify that the VPN is working.
There are three generic steps to provision a router for VPN connectivity:
As you can see, one of the main components of IPsec VPNs is the crypto map. Crypto maps are configuration objects that group and gather the VPN settings to apply them to an interface. Only then, when the crypto map is applied to router interfaces, will the router start encrypting and tunneling traffic through those interfaces. A detailed look at crypto maps and IPsec configurations is beyond the scope of this routing book.
Broadly explained, crypto maps have three components:
-
Crypto ACL
-
Security policies
-
SA parameters
A crypto map uses ACLs to define the type of traffic to encrypt. A permit statement in a crypto ACL will result in the traffic being encrypted, whereas a deny statement will result in the traffic being sent out by the Internet-facing interface in clear text. Examples of encryption algorithms that would be used for encrypting traffic are DES, 3DES, and AES.
Notice that with the remote worker crypto map components, we did not include the VPN peer address as we did for the branch office deployment. The reason is that crypto maps cannot use the VPN peer address to associate the proper crypto map to a peer, because by definition, mobile workers are connecting from different locations and therefore do not always use the same IP address. In this situation, the crypto map is referred to as a dynamic crypto map, a concept that is beyond the scope of this book.
Traffic defined by the ACL used by the crypto map will be encrypted according to configured cryptographic algorithms and policies, called security policies. Security policies are therefore also part of the crypto map. Finally, additional parameters, called security association (SA) parameters, such as tunnel lifetime in terms of time and volume, become part of the overall configuration of crypto maps.
Recall that crypto maps operate like a funnel, as shown in Figure 7-28.
This funnel channels all configuration components to the appropriate interface, serving as initiation and termination point of IPsec tunnels. You configure the IPsec settings, group them together in a crypto map, and then apply the crypto map to the interface. When traffic meets the criteria, it passes through the funnel, and its policies are enforced. Traffic that does not meet the criteria configured in the crypto maps leaves the Internet-facing interface unencrypted.
This crypto map-to-interface association will indicate where initiation and termination of the tunnel occur, thus identifying the interface requiring additional configuration for VPN to work, such as allowing dynamic routing and tuning address translations. Crypto maps are applied to the VPN router interface facing the public.
To verify if the VPN configuration is functioning properly, use the show crypto map command, the show crypto isakmp sa command, the show crypto sa command, and the show crypto engine connections active command. It is also important to test the full connectivity, by having a remote user attempting to connect. Use the commands as follows:
-
Use the show crypto map command to display the crypto map configuration.
-
Use the show crypto isakmp sa command to display all current IKE SAs at a VPN peer. This command has no arguments or keywords.
-
Use the show crypto ipsec sa command to display the settings used by current SAs.
-
Use the show crypto engine connections active command to view the current active encrypted session connections for all crypto engines.
Example 7-65, displays the result of executing the show crypto map command on R1. R1 output indicates that the interface to which the crypto map is applied is Fa0/1. This information tells us that the IPsec VPN tunnels will terminate on interface Fa0/1.
Example 7-65: Example of the show crypto map Command
R1#show crypto map
Crypto Map "RAVPN" 10 ipsec-isakmp
Dynamic map template tag: DYNO
Interfaces using crypto map RAVPN:
FastEthernet0/1
R1#
Having a crypto map assigned to an interface is a good start but does not prove that IPsec connectivity is fully functional. To be able to fully confirm the proper configuration and working of an IPsec VPN for mobile workers, it is imperative to have a remote user test the connection.
In our example, the VPN tunnel will be initiated by a remote user, using the Cisco VPN Client. The main window of the Cisco VPN Client, already installed on the mobile worker’s computer, is depicted in Figure 7-29. The user clicks the Connect button after highlighting the HQ connection entry. This particular HQ connection entry was created ahead of time, providing it with the parameters to establish the IPsec connection, among which is the IP address of the headend VPN device, the Internet-facing interface of R1 at 209.165.200.1.
After a brief moment of negotiation between the client’s software and the headend VPN router, the user will be asked to authenticate. After providing a successful authentication, the users will be connected on the corporate network via IPsec VPN. To confirm connectivity and that packets are passing through the VPN tunnel, the user can pull down the Status menu and select Statistics. Then, the user can click the Tunnel Details tab. The VPN Client will then show IP security information, listing the IPsec statistics for this VPN tunnel to the private network, as shown in Figure 7-30.
Referring to Figure 7-30, we can confirm that the client is connected to the VPN server at address 192.168.1.1. The client received the IP address of 10.254.254.3, which belongs to the VPN pool. Moreover, we are encrypting and decrypting traffic.
The user will then confirm full connectivity with the corporate network by trying to reach internal resources using ping. In Figure 7-31, the VPN user is successful at using ping against an internal resource 10.6.6.7. At this point, the remote user could go back to the statistics windows of the client software and would notice that the encrypted and decrypted packets counters would have increased in value compared to the statistics shown in Figure 7-30.
An effective way to confirm IPsec connectivity, from the VPN router’s perspective, is to use the show crypto isakmp sa command. In Example 7-66, we see that R1 has one active tunnel, which initiated from 172.31.7.10 to terminate on 192.168.1.1, which is the Internet-facing interface of R1. Although not shown here, the show crypto ipsec sa command could also be used to confirm remote connectivity.
Example 7-66: show crypto isakmp sa Command
R1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
192.168.1.1 172.31.7.10 QM_IDLE 1012 0 ACTIVE
IPv6 Crypto ISAKMP SA
R1#
Example 7-67 shows the output of another useful command to check connectivity from the VPN router’s perspective. The show crypto session command enables you to confirm that there is an IPsec tunnel is established from any source address going to the destination of 10.254.254.3 which is the remote user’s VPN address.
Example 7-67: show crypto session Command
R1#show crypto session
Crypto session current status
Interface: FastEthernet0/1
Session status: UP-ACTIVE
Peer: 172.31.7.10 port 500
IKE SA: local 192.168.1.1/500 remote 172.31.7.10/500 Active
IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 host 10.254.254.3
Active SAs: 2, origin: dynamic crypto map
R1#
Earlier, in Figure 7-30, you saw how the client can see the statistics on the packets being encrypted and decrypted. Similar statistics can be seen from the VPN router by using the show crypto engine connections active command shown in Example 7-68.
Example 7-68: show crypto engine connections active Command
R1#show crypto engine connections active
Crypto Engine Connections
ID Interface Type Algorithm Encrypt Decrypt IP-Address
1012 Fa0/1 IKE SHA+3DES 0 0 192.168.1.1
2013 Fa0/1 IPsec 3DES+SHA 0 56 192.168.1.1
2014 Fa0/1 IPsec 3DES+SHA 42 0 192.168.1.1
R1#
We also need to confirm that packets reaching further down in the corporate network can be routed back to the router user. We would like to test full connectivity between the remote users and the loopback address of R2. Success of this step would prove that proper routing is taking place on the network, where R2 can make a routing decision for destination address of 10.254.254.0/24. Figure 7-32 shows the successful result of a ping from the remote host to IP address 10.200.200.1.
We have thus proven full connectivity from both the remote user’s end and the VPN router. Moreover, we have proven that our remote user can reach resources further down in the corporate network, thus confirming that proper routing is taking place.
Reviewing Alternatives for Mobile Worker Connectivity
In the previous sections, you saw how to provide mobile worker connectivity from the perspective of routing facilities. The functionality we implemented permitted the routing of VPN address pools. We also tuned NAT so that remote user traffic would not be translated. We proved the proper functioning by having our remote user reach the remote loopback address of R2. In addition, the show crypto isakmp sa command showed us that the VPN tunnel with the remote was up.
Our goal was not to know the details of IPsec functioning but rather to know how to fine-tune the related components, such as ACLs. We also discussed the routing options, and you learned that the most dynamic option is reverse route injection. Our configuration in the previous section followed a less-complex but more-static configuration of using static route and then redistributing it through the EIGRP domain. Example 7-69 displays the static route and the VPN pool called EZVPN, which was defined in Example 7-60.
Example 7-69: Routing Table on the Branch router with the Remote VPN Client
R1#show ip route static
10.0.0.0 255.255.255.0 is subnetted, 4 subnets
S 10.254.254.0 [1/0] via 192.168.1.2
R1# show ip local pool
Pool Begin End Free In use
EZVPN 10.254.254.1 10.254.254.254 253 1
R1#
Table 7-17 gives a summary of the alternative solutions for routing when dealing with remote workers. Example 7-70 shows a brief example of the preferred method of RRI, without getting into too many details of the commands.
Table 7-17: Alternative Solutions for Routing Remote Workers
Open table as spreadsheet | Solution | Advantages | Disadvantages |
| Use existing subnet | Simple. Saves IP address space. Does not require routing adjustment. | Requires Proxy ARP on VPN router |
| Use new subnet | Address pool easily identified, potentially one pool per user profile. | Uses the IP address space, requires dynamic routing or static routes |
| Advertise using static routes and redistribute | Simple. | Not dynamic |
| Advertise using RRI | VPN client routes automatically inserted in routing table. | Extra processing on routing table and routing process if connections too ephemeral |
In Example 7-70, we remove the static routing we saw Example 7-69. We then configure our crypto dynamic map to perform RRI, with the reverse-route command. We confirm with the show ip route static command that the static route no longer exists.
We will then bring up a connection from our remote host to R1.
Once the remote VPN user is connected, we reissue the show ip route static command to the router and witness that a static entry was automatically introduced in the routing table. The moment the remote client disconnects, the static route to 10.254.254.4 will disappear from the routing table.
Example 7-70: Removing Static Routing and Configuring RRI
R1#config t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#no ip route 10.254.254.0 255.255.255.0
R1(config)#
R1(config)#crypto dynamic-map DYNO 10
R1(config-crypto-map)#reverse-route
R1(config-crypto-map)#do show ip route static
R1(config-crypto-map)#
R1(config-crypto-map)#do show ip route static
10.0.0.0 255.0.0.0 is variably subnetted, 4 subnets, 2 masks
S 10.254.254.4 255.255.255.255 [1/0] via 172.31.7.10
R1(config-crypto-map)#
One drawback of RRI is that entries are added with a host mask, a mask of 32 bits in the routing table. If you have hundreds of remote clients that connect simultaneously, that could result in a very long routing table.
You have now learned to use basic IPsec verification commands to monitor the health of connections. Those verifications were not thorough and detailed, but they will prove useful as you move forward and learn more about VPN connectivity and maintenance.
In most cases, the simplest routing solution is the most suitable. As you saw, static routes worked well in the scenario in the previous section. You also saw that when you are establishing a VPN tunnel, traffic between the remote host and the LAN resources should not be subjected to NAT. This is not an issue because the original packets will be encrypted into a newer packet by the IPsec process.
Summary
In this chapter, you learned about implementing routing facilities for branch offices and mobile workers, including the following:
-
Planning the branch office implementation
-
Analyzing services in the branch office
-
Planning for mobile worker implementations
-
Routing traffic to the mobile worker
More precisely, you learned about the following:
-
Branch office design considerations, such as connectivity technologies, resiliency, routing protocols, service mix, security and compliance, mobility.
-
DSL broadband technologies, which are not complete end-to-end solutions, and therefore protocols such as PPPoE and PPPoA are used. You also saw a generic PPPoA configuration in this chapter.
-
Configuring static routing. Using the show ip protocols command to check routing protocol configuration and exchanges. More precisely, for floating static route, using the ip route prefix mask next-hop-ip-address distance command
-
Configuring NAT and tuning it, including the use of the following commands:
-
The ip nat pool name start-ip end-ip {netmask netmask | prefix-length prefix-length} command to define a pool of IP addresses for NAT.
-
The ip nat inside source {list {access-list-number | access-list-name} | route-map name} {interface type number | pool name} [overload] command to link the source IP address to the pool for translated address. If static translation is used, the command is ip nat inside source {static {local-ip global-ip} [vrf name] [extendable] [no-alias] [no-payload] [route-map] [redundancy group-name] | {esp local-ip interface type number}}.
-
The ip nat inside and ip nat outside interface configuration commands are used to designate that traffic originating from or destined for a specific interface is subject to NAT.
-
The show ip nat translations command used to display active NAT translation and the clear ip nat statistics command to reset the counters to zero.
-
The chapter briefly covered how HSRP can be used to decide to switch to another active router upon failure and how it would affect the traffic flow.
-
The four options to route dynamic routing protocols through an IPsec tunnel:
-
-
Point-to-point generic routing encapsulation (P2P GRE)
-
Virtual tunnel interface (VTI)
-
Dynamic multipoint VPN (DMVPN)
-
Group encrypted transport VPN (GET VPN)
-
IPsec, its major services of confidentiality, integrity, and authentication, and the benefits of encryption and encapsulation.
-
Protocol and port numbers used by IPsec: ESP (protocol 50), AH (protocol 51), IKE/ISAKMP (port UDP 500), and NAT-T (port UDP 4500).
-
Components of crypto maps (crypto ACL, remote peer IP address, security policies, and security association parameters), and how to verify the configuration with the show crypto map command, the debug crypto ipsec command, and the show crypto session command.
-
How the deny statement in a NAT ACL is not for blocking the traffic but rather specifying that translation is not to be performed on that traffic. Similarly, in a crypto ACL, the deny statement is not for blocking the traffic but rather specifies that encryption is not to be performed on that traffic.
-
Impact of NAT and IPsec, and how the NAT process takes place before the encryption process, and how the NAT ACL will need to be tuned with the access-list configuration command. You also learned how to verify whether translation was successful by using the show ip nat statistics command, debug ip nat command, and the show ip access-lists name command.
-
Impact of IPsec on dynamic routing, because it does not carry multicast or broadcast, and how GRE can be used to circumvent that problem.
-
GRE is a tunneling protocol developed by Cisco, capable of encapsulating a variety of network layer protocols packets inside IP tunnels, which makes it a common option to pass dynamic routing protocol traffic across an IPsec tunnel.
-
GRE configuration steps are as follows:
-
Create tunnel interfaces for GRE with the tunnel source {ip-address | interface-type interface-number} command, and define the origin of the tunnel with tunnel source {ip-address | interface-type interface-number} and the destination of the tunnel with the tunnel destination ip-address command. The tunnel mode gre ip command was not required in our scenario because the default of encapsulation of GRE is IP.
-
Configure routing protocols to route through the GRE tunnel, with the network subnet mask command.
-
Change the crypto ACL to encrypt GRE traffic.
-
There are two types of Cisco IOS firewalls: Classic firewalls are based on ACLs, and zone-based firewalls are based on security zones.
-
To check and provide traffic routing to mobile workers, there are five generic steps:
0 comments
Post a Comment