CCNP Route Notes Mobile Worker Connectivity

Mobile workers might be in a home office, with an always-on secure connection to the corporate network, managed centrally by the corporation (business-ready mobile worker.) Or they might be truly mobile, connecting via a laptop or public computer to the corporate network (traditional mobile worker.) In planning for either type of mobile worker, consider the network access technologies and infrastructure services needed, such as the following:

Bandwidth requirements: Because mobile workers use the same applications as office workers—email, other applications, voice, video, real-time collaboration—they need sufficient bandwidth. Typical remote access technologies include residential cable, DSL, and wireless.
Connection security: Use site-to-site VPNs for permanent home users and remote access VPNs for mobile users.
These can be either IPsec or Secure Sockets Layer (SSL) VPNs.
Corporate security: Because a remote environment is less controlled than an office environment, use firewalls,
intrusion prevention services (IPS), and URL filtering to protect the corporate network from remote users.
User authentication: Use network access control (NAC), AAA servers, or other authentication mechanisms to protect access to corporate resources.
QoS: If voice and video are used, determine how you will prioritize that traffic, and how you will address the differences in upload and download speeds of common broadband connections.
Management: Support for remote workers is more complex when they are not under corporate control. Provide methods to push security policies and updates to mobile workers.

Table 8-1 compares the two types of mobile workers and the ability to offer these services to each.

Table 8-1 Comparison of Traditional and Business-Ready Mobile Workers:

	Traditional Mobile Worker	Business-Ready Mobile Worker
Access to applications and services	Basic	Full
Voice and video support	Limited to none	Yes
QoS	No (best effort)	Yes
Security	Relies on end-user	Controlled by corporate IT
Remote management	No	Yes

Components of a Mobile Worker Solution

There are three major groups of components in a mobile worker solution: corporate devices, devices located at the remote
site, and optional additional services.

The corporate components include headend routers, devices to terminate the VPNs such as ASA firewalls, authentication services, and central management devices.

The remote site components for a Business-ready solution include broadband access, a VPN router with QoS capabilities,
and a computer. There can also be a wireless access point, an IP phone, and a video telephony camera. A traditional
mobile worker might have only a laptop, perhaps with a softphone on it.

The corporation might offer additional services to the mobile worker, such as IP telephony, voice mail, or contact center.
The corporation also needs to decide which type of VPN services to offer: IPsec, SSL, or both. IPsec requires a client on the endpoint (computer or router), but it is a well-proven technology that provides full access to all network applications. It is a good choice for mobile workers using company-managed devices.

SSL is also a well-proven technology and can be used with or without a client. When used from a web browser, it provides access even from nonmanaged devices, and the portals can be customized to provide appropriate access for employees or business partners. Some applications might not work well through the web portal, however.

Implementing a Mobile Worker Solution

Some of the things you need to implement in a mobile worker solution are

The VPN solution, either IPsec or SSL
A firewall solution, for stateful Layer 3–7 protection
Intrusion prevention to defend against worms and viruses
Wireless security, if wireless is used, with encryption and 802.1x authentication.
QoS for voice and video
Ports at the remote site for printers and other devices
PoE ports for IP phones

Cisco Easy VPN can simplify the deployment of all these services and policies to remote users. Easy VPN enables a server to push down VPN configuration to a client. It is a way to create site-to-site VPNs without manually configuring each remote router. Thus it is good for remote sites without technical support. It can also be used with software clients for remote users.

Cisco Easy VPN dynamically handles the following items:

Negotiating VPN tunnel parameters
Establishing the VPN tunnel based on those parameters
NAT, PAT, or ACL configuration
User authentication
Managing encryption and decryption keys
Authenticating, encrypting, and decrypting traffic

Cisco Easy VPN has two components: a server and a remote client. The Easy VPN Server can be a Cisco router, ASA Firewall, or Cisco VPN concentrator. It contains security policies and pushes those to remote clients. The Easy VPN Remote can be a Cisco router, ASA Firewall, a hardware client, or a software client. It contacts the server and receives policies from it to establish the IPsec tunnel. The steps to configure the headend for Easy VPN are

Allow IPsec traffic through the edge firewall or access list.
Create the IP address pool for the VPN clients.
Verify the IPsec VPN configuration.
Ensure that corporate devices have routes to the VPN subnets.
Tune NAT to bypass VPN traffic.

Allow IPsec Traffic

IPsec uses the following ports and protocols:

Encapsulating Security Payload (ESP)—IP protocol 50
Authentication Header—IP protocol 51
ISAKMP—UDP port 500
NAT Traversal (NAT-T)—UDP port 4500

These protocols and ports must be allowed in through the firewall from the outside for an IPsec tunnel to be established. If your network is protected by a firewall appliance or module, coordinate these changes with your security personnel. If your network is protected by an IOS firewall, determine whether you have a zone-based firewall or a classic IOS firewall. The command show zone-pair security produces output if you have a zone-based firewall. The command show ip inspect interfaces produces output if you have a classic IOS Firewall. The command show access-lists will show you any access lists associated with the firewall that will need to be modified to allow IPsec traffic.

Fortunately, configuring IPsec and firewalls is outside the scope of this exam, so you need to understand it only in concept.

Create the Address Pool

VPN clients have a public Internet address until they reach your network but need a private inside address to access network resources. The addresses can be given by a router acting as a DHCP server, by other DHCP servers, or by AAA servers.

Plan your address pool so that you have enough client addresses for the maximum number of users and so that the subnets can be summarized when their routes are advertised to internal devices. Be sure that the client address range is not used anyplace else in the network.

To configure a DHCP pool on a router, use the command:

ip local pool pool- name first-address last-address [ mask subnet-mask]

For the exam, you are not required to add this IP address pool to the VPN configuration. In theory you would request a change ticket for your VPN support team to make that change.

Verify the IPsec VPN

You are likewise required to understand only the components of a VPN, not to know how to configure it. The two main things you need to know are the function of a crypto map and the commands to verify IPsec connectivity.

A crypto map is described in Chapter 7, “Branch Office Connectivity.” It basically groups the VPN settings to apply them to an interface. It consists of the crypto ACL, which defines the traffic to be encrypted, security policies such as how to protect the data, and other security parameters such as peer IP address or tunnel lifetime. The crypto map is applied to the exit interface for traffic needing to be protected.

Commands to verify IPsec connectivity include

show crypto map: Shows the crypto ACLs, any peers, and the interface where the crypto map is applied
show crypto isakmp sa: Shows information about the ISAKMP security associate negotiation process
show crypto IPsec sa: Shows the settings used by current SAs, including tunnel status and peers
show crypto engine connections active: Shows the status of any IPsec tunnels

Route to the VPN Subnets

Internal resources need to have a route to the VPN subnets. One way to do this is to make the VPN subnet a part of an existing subnet applied to a router interface. This subnet should already be advertised to the rest of the network, so no changes to routing are needed. The disadvantage is that you need to enable proxy-ARP on the router interface connected to the subnet.

A second option is to use a separate subnet for the VPN clients and then inject that subnet into the routing protocol. An IPsec feature called Reverse Route Injection (RRI) does that dynamically. It injects a host route into the routing table for each client while they are connected and then withdraws that route when they disconnect. You would then redistribute those routes into the routing protocol. Alternatively, you can create a static route for the VPN subnets and redistribute the static route into your routing protocol.

Tune NAT

VPN traffic should bypass the NAT process as it leaves your network. If the same edge router is doing NAT and terminating the VPNs, the router processes the NAT service before the IPsec service. It is simple to configure NAT bypass because NAT uses an access list to identify which traffic to translate. Modify the access list to deny traffic destined to the VPN subnet. Be sure to permit all other traffic. You can then match that access list in a route-map and use the route-map to modify the NAT traffic. Your final configuration might look something like this:

access-list 101 deny ip any vpn-subnet vpn-mask
access-list 101 permit ip any any
!
route-map NAT permit 10
match ip address 101
!
ip nat inside source route-map NAT pool NAT-POOL overload

Be sure to verify your configuration by checking the IP address of a VPN client, pinging internal resources, checking the routing table, and the IPsec SAs.

More Resources