Organizations use virtual private networks (VPNs) to create an end-to-end private network connection (tunnel) over third-party networks such as the Internet or extranets. The tunnel eliminates the distance barrier and enables remote users to access central site network resources. However, VPNs cannot guarantee that the information remains secure while traversing the tunnel. For this reason, modern cryptographic methods are applied to VPNs to establish secure, end-to-end, private network connections.
The IP Security (IPsec) protocol provides a framework for configuring secure VPNs and is commonly deployed over the Internet to connect branch offices, remote employees, and business partners. It is a reliable way to maintain communication privacy while streamlining operations, reducing costs, and allowing flexible network administration.
Secure site-to-site VPNs, between central and remote sites, can be implemented using the IPsec protocol. IPsec can also be used in remote-access tunnels for telecommuter access. The Cisco VPN Client is one method for establishing the IPsec remote-access VPN. In addition to IPsec, the Secure Sockets Layer (SSL) protocol can be used to established remote-access VPN connections.
In the first hands-on lab for the chapter, Configuring a Site-to-Site VPN Using Cisco IOS and SDM, learners configure IPsec VPN settings with the CLI on perimeter routers and then verify IPsec VPN operation. Another site-to-site IPsec VPN is configured and verified using SDM.
In a second hands-on lab, Configuring a Remote Access VPN Server and Client, learners configure ZPF with SDM on a perimeter router, followed by Cisco Easy VPN Server. Next, Cisco VPN client is installed and configured on a PC. A remote access VPN connection is then tested.
The labs are found in the lab manual on Academy connection at cisco.netacad.net.
A Packet Tracer activity, Configure and Verify a Site-to-Site IPsec VPN Using CLI, provides learners additional practice implementing the technologies introduced in this chapter. Learners secure and test a WAN connection between two remote networks with a site-to-site IPsec VPN. Packet Tracer activities for CCNA Security are found on Academy Connection at cisco.netacad.net.
Solutions, such as the various encryption methods and PKI, enable businesses to securely extend their networks through the Internet. One way in which businesses accomplish this extension is through Virtual Private Networks (VPNs).
A VPN is a private network that is created via tunneling over a public network, usually the Internet. Instead of using a dedicated physical connection, a VPN uses virtual connections routed through the Internet from the organization to the remote site. The first VPNs were strictly IP tunnels that did not include authentication or encryption of the data. For example, Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco that can encapsulate a wide variety of Network Layer protocol packet types inside IP tunnels. This creates a virtual point-to-point link to Cisco routers at remote points over an IP internetwork. Other examples of VPNs that do not automatically include security measures are Frame Relay, ATM PVCs, and Multiprotocol Label Switching (MPLS) networks.
A VPN is a communications environment in which access is strictly controlled to permit peer connections within a defined community of interest. Confidentiality is achieved by encrypting the traffic within the VPN. Today, a secure implementation of VPN with encryption is what is generally equated with the concept of virtual private networking.
VPNs have many benefits:
In the simplest sense, a VPN connects two endpoints over a public network to form a logical connection. The logical connections can be made at either Layer 2 or Layer 3 of the OSI model. VPN technologies can be classified broadly on these logical connection models as Layer 2 VPNs or Layer 3 VPNs. Establishing connectivity between sites over a Layer 2 or Layer 3 VPN is the same. A delivery header is added in front of the payload to get it to the destination site. This chapter focuses on Layer 3 VPN technology.
Common examples of Layer 3 VPNs are GRE, MPLS, and IPsec. Layer 3 VPNs can be point-to-point site connections such as GRE and IPsec, or they can establish any-to-any connectivity to many sites using MPLS.
Generic routing encapsulation (GRE) was originally developed by Cisco and later standardized as RFC 1701. An IP delivery header for GRE is defined in RFC 1702. A GRE tunnel between two sites that have IP reachability can be described as a VPN, because the private data between the sites is encapsulated in a GRE delivery header.
Pioneered by Cisco, MPLS was originally known as tag switching and later standardized via the IETF as MPLS. Service providers are increasingly deploying MPLS to offer MPLS VPN services to customers. MPLS VPNs use labels to encapsulate the original data, or payload, to form a VPN.
How does a network administrator prevent eavesdropping of data in a VPN? Encrypting the data is one way to protect it. Data encryption is achieved by deploying encryption devices at each site. IPsec is a suite of protocols developed with the backing of the IETF to achieve secure services over IP packet-switched networks. The Internet is the most ubiquitous packet-switched public network; therefore, an IPsec VPN deployed over the public Internet can provide significant cost savings to a corporation as compared to a leased-line VPN.
IPsec services allow for authentication, integrity, access control, and confidentiality. With IPsec, the information exchanged between remote sites can be encrypted and verified. Both remote-access and site-to-site VPNs can be deployed using IPsec.
There are two basic types of VPN networks:
A site-to-site VPN is created when connection devices on both sides of the VPN connection are aware of the VPN configuration in advance. The VPN remains static, and internal hosts have no knowledge that a VPN exists. Frame Relay, ATM, GRE, and MPLS VPNs are examples of site-to-site VPNs.
A remote-access VPN is created when VPN information is not statically set up, but instead allows for dynamically changing information and can be enabled and disabled. Consider a telecommuter who needs VPN access to corporate data over the Internet. The telecommuter does not necessarily have the VPN connection set up at all times. The telecommuter's PC is responsible for establishing the VPN. The information required to establish the VPN connection, such as the IP address of the telecommuter, changes dynamically depending on the location of the telecommuter.
Site-to-Site VPN
A site-to-site VPN is an extension of a classic WAN network. Site-to-site VPNs connect entire networks to each other, for example, they can connect a branch office network to a company headquarters network. In the past, a leased line or Frame Relay connection was required to connect sites, but because most corporations now have Internet access, these connections can be replaced with site-to-site VPNs.
In a site-to-site VPN, hosts send and receive normal TCP/IP traffic through a VPN gateway, which can be a router, firewall, Cisco VPN Concentrator, or Cisco ASA 5500 Series Adaptive Security Appliance. The VPN gateway is responsible for encapsulating and encrypting outbound traffic from a particular site and sending it through a VPN tunnel over the Internet to a peer VPN gateway at the target site. Upon receipt, the peer VPN gateway strips the headers, decrypts the content, and relays the packet toward the target host inside its private network.
Remote-Access VPN
Remote-access VPNs are an evolution of circuit-switching networks, such as plain old telephone service (POTS) or ISDN. Remote-access VPNs can support the needs of telecommuters, mobile users, and extranet consumer-to-business traffic. Remote-access VPNs support a client / server architecture where a VPN client (remote host) requires secure access to the enterprise network via a VPN server device at the network edge.
In the past, corporations supported remote users by using dial-in networks and ISDN. With the advent of VPNs, a mobile user simply needs access to the Internet to communicate with the central office. In the case of telecommuters, their Internet connectivity is typically a broadband connection.
In a remote-access VPN, each host typically has Cisco VPN client software. Whenever the host tries to send traffic intended for the VPN, the Cisco VPN Client software encapsulates and encrypts that traffic before sending it over the Internet to the VPN gateway at the edge of the target network. Upon receipt, the VPN gateway behaves as it does for site-to-site VPNs.
An emerging remote-access technology is Cisco IOS SSL VPN. This technology provides remote-access connectivity from almost any Internet-enabled host using a web browser and its native Secure Sockets Layer (SSL) encryption. SSL VPNs allow users to access web pages and services, including the ability to access files, send and receive email, and run TCP-based applications without IPsec VPN Client software. They provide the flexibility to support secure access for all users, regardless of the host from which they establish a connection. This flexibility enables companies to extend their secure enterprise networks to any authorized user by providing remote-access connectivity to corporate resources from any Internet-enabled host.
SSL VPN currently delivers two modes of access: clientless and thin client. With clientless SSL VPN, a remote client needs only an SSL-enabled web browser to access HTTP- or HTTPS-enabled web servers on the corporate LAN. In a thin client SSL VPN environment, a remote client must download a small, Java-based applet for secure access of TCP applications that use static port numbers. UDP is not supported in a thin client environment.
SSL VPNs are appropriate for user populations that require per-application or per-server access control, or access from non-enterprise-owned desktops. SSL VPNs are not a complete replacement for IPsec VPNs. IPsec VPNs allow secure access to all of an organization's client/server applications. Additionally, SSL VPNs do not support the same level of cryptographic security that IPsec VPNs support. While SSL VPNs cannot replace IPsec VPNs, in many cases, they are complementary because they solve different problems. This complementary approach allows a single device to address all remote-access user requirements.
The primary benefit of SSL VPNs is that they are compatible with Dynamic Multipoint VPNs (DMVPNs), Cisco IOS Firewalls, IPsec, intrusion prevention systems (IPSs), Cisco Easy VPN, and Network Address Translation (NAT).
The primary restriction of SSL VPNs is that they are currently supported only in software. The router CPU processes the SSL VPN connections. The onboard VPN acceleration that is available in integrated services routers accelerates only IPsec connections.
The Cisco VPN product line includes several devices to support remote and site-to-site VPN:
In most networks, devices are already in place. If this is the case, it is necessary to verify if interoperability among the different devices is possible. For example, a customer network might have a Cisco ASA 5500 Series Adaptive Security Appliance at one site and a Cisco router at another. This site-to-site VPN interoperability is possible by choosing, at a minimum, the following software versions: Cisco IOS Release 12.2(8)T and Cisco ASA 5500 Series Adaptive Security Appliance Version 8.0.
With Cisco routers running Cisco IOS software, organizations can deploy and scale site-to-site VPNs of any topology, from hub-and-spoke to the more complex, fully meshed VPNs. In addition, the Cisco IOS security features combine the VPN feature set with firewall, intrusion prevention, and extensive Cisco IOS capabilities, including quality of service (QoS), multiprotocol, multicast, and advanced routing support.
Cisco provides a suite of VPN-optimized routers. Cisco IOS software for routers combines VPN services with routing services. The Cisco VPN software adds strong security using encryption and authentication. These Cisco VPN-enabled routers provide high performance for site-to-site, intranet, and extranet VPN solutions.
The Cisco IOS feature sets incorporate many VPN features:
For VPN services, Cisco ASA 5500 Series Adaptive Security Appliances offer flexible technologies that deliver tailored solutions to suit remote-access and site-to-site connectivity requirements. These appliances provide easy-to-manage IPsec and SSL VPN-based remote-access and network-aware, site-to-site VPN connectivity. Businesses can create secure connections across public networks to mobile users, remote sites, and business partners.
As an important component of the Cisco Self-Defending Network, Cisco ASA 5500 Series Adaptive Security Appliances provide proactive threat mitigation, control network activity and application traffic, and deliver flexible VPN connectivity while remaining cost effective.
Cisco ASA 5500 Series Adaptive Security Appliances offer other services, such as intrusion prevention, Cisco SSL VPN, and advanced integration module (AIM) to enhance the processing capabilities of the appliances. These are some of the features that Cisco ASA 5500 Series Adaptive Security Appliances provide:
Each Cisco ASA 5500 Series Adaptive Security Appliance supports a number of VPN peers:
Cisco remote-access VPNs can use four IPsec clients:
To enhance performance and offload the encryption task to specialized hardware, the Cisco VPN family of devices offers hardware acceleration modules:
Generic routing encapsulation (GRE) is a tunneling protocol defined in RFC 1702 and RFC 2784. It was originally developed by Cisco Systems for creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork.
GRE supports multiprotocol tunneling. It can encapsulate multiple protocol packet types inside an IP tunnel. Adding an additional GRE header between the payload and the tunneling IP header provides the multiprotocol functionality. IP tunneling using GRE enables network expansion by connecting multiprotocol subnetworks across a single-protocol backbone environment. GRE also supports IP multicast tunneling. Routing protocols that are used across the tunnel enable dynamic exchange of routing information in the virtual network.
GRE tunnels are stateless. Each tunnel endpoint keeps no information about the state or availability of the remote tunnel endpoint. This feature helps service providers (SPs) provide IP tunnels to customers who are not concerned about the internal tunneling architecture at the SP end. Customers then have the flexibility to configure or reconfigure their IP architecture but still maintain connectivity. It creates a virtual point-to-point link to routers at remote points over an IP internetwork. GRE does not include any strong security mechanisms to protect its payload.
GRE encapsulates the entire original IP packet with a standard IP header and GRE header. A GRE tunnel header contains at least two 2-byte mandatory fields:
GRE uses a protocol type field in the GRE header to support the encapsulation of any OSI Layer 3 protocol. The GRE header, together with the tunneling IP header, creates at least 24 bytes of additional overhead for tunneled packets.
There are five steps to configuring a GRE tunnel:
Step 1. Creating a tunnel interface using the interface tunnel 0 command.
Step 2. Assigning the tunnel an IP address.
Step 3. Identifying the source tunnel interface using the tunnel source command.
Step 4. Identifying the destination of the tunnel using the tunnel destination command.
Step 5. Configuring which protocol GRE will encapsulate using the tunnel mode gre command.
The advantages of GRE are that it can be used to tunnel non-IP traffic over an IP network. Unlike IPsec, which only supports unicast traffic, GRE supports multicast and broadcast traffic over the tunnel link. Therefore, routing protocols are supported in GRE.
GRE does not provide encryption. If that is needed, IPsec should be configured.
IPsec is an IETF standard (RFC 2401-2412) that defines how a VPN can be configured using the IP addressing protocol. IPsec is not bound to any specific encryption, authentication, security algorithms, or keying technology. IPsec is a framework of open standards that spells out the rules for secure communications. IPsec relies on existing algorithms to implement the encryption, authentication, and key exchange.
IPsec works at the Network Layer, protecting and authenticating IP packets between participating IPsec devices (peers). As a result, IPsec can protect virtually all application traffic because the protection can be implemented from Layer 4 through Layer 7. All implementations of IPsec have a plaintext Layer 3 header, so there are no issues with routing. IPsec functions over all Layer 2 protocols, such as Ethernet, ATM, Frame Relay, Synchronous Data Link Control (SDLC), and High-Level Data Link Control (HDLC).
The IPsec framework consists of five building blocks:
IPsec provides the framework, and the administrator chooses the algorithms that are used to implement the security services within that framework. By not binding IPsec to specific algorithms, it allows newer and better algorithms to be implemented without patching the existing IPsec standards.
IPsec can secure a path between a pair of gateways, a pair of hosts, or a gateway and host. Using the IPsec framework, IPsec provides these essential security functions:
Confidentiality
Confidentiality is achieved through encryption of traffic as it travels down the VPN. The degree of security depends on the length of the key of the encryption algorithm. If someone tries to hack the key through a brute-force attack, the number of possibilities to try is a function of the length of the key. The time to process all the possibilities is a function of the computer power of the attacking device. The shorter the key, the easier it is to break. A 64-bit key can take approximately one year to break with a relatively sophisticated computer. A 128-bit key with the same machine can take roughly 10^19 years to decrypt.
The following are some encryption algorithms and key lengths that VPNs use:
Integrity
The next VPN-critical function is data integrity. Assume that a check for $100 is written to Sonya from Jeremy. The check is then mailed to Sonya but intercepted by an attacker. The attacker changes the name and amount on the check and attempts to cash it. Depending on the forged quality of the altered check, the attacker could be successful.
This scenario applies to VPNs because data is transported over the public Internet. Potentially, this data could be intercepted and modified. A method of proving data integrity is required to guarantee that the content has not been altered. A data integrity algorithm can provide this guarantee.
Hashed Message Authentication Codes (HMAC) is a data integrity algorithm that guarantees the integrity of the message using a hash value. At the local device, the message and a shared-secret key are processed through a hash algorithm, which produces a hash value. This value is appended to the message, and the message is sent over the network. At the remote device, the hash value is recalculated and compared to the sent hash value. If the transmitted hash matches the received hash, the message integrity is verified. However, if they do not match, the message was altered and is invalidated.
There are two common HMAC algorithms:
HMAC-SHA-1 is considered cryptographically stronger than HMAC-MD5. It is recommended when slightly superior security is important.
Authentication
When conducting business over long distance, it is necessary to know (authenticate) the individual at the other end of the phone, email, or fax. The same is true of VPN networks. The device on the other end of the VPN tunnel must be authenticated before the communication path is considered secure.
In the middle ages, a seal guaranteed the authenticity of a document. In modern times, a signed document is notarized with a seal and a signature. In the electronic era, a document is signed using the sender's private encryption key called a digital signature. A signature is authenticated by decrypting the signature with the sender's public key.
There are two primary methods of configuring peer authentication.
A third way to accomplish authentication is through RSA-encrypted nonces. A nonce is a random number that is generated by the peer. RSA-encrypted nonces use RSA to encrypt the nonce value and other values. This method requires that the public key of the two peers be present on the other peer before the third and fourth messages of an IKE exchange can be accomplished. For this reason, public keys must be manually copied to each peer as part of the configuration process. This method is the least used of the authentication methods.
Secure Key Exchange
Encryption algorithms such as DES, 3DES, and AES as well as the MD5 and SHA-1 hashing algorithms require a symmetric, shared secret key to perform encryption and decryption. How do the encrypting and decrypting devices get the shared secret key?
Email, courier, or overnight express can be used to send the shared secret keys to the administrators of the devices. But the easiest key exchange method is a public key exchange method between the encrypting and decrypting devices.
The Diffie-Hellman (DH) key agreement is a public key exchange method that provides a way for two peers to establish a shared secret key that only they know, even though they are communicating over an insecure channel.
Variations of the DH key exchange algorithm are known as DH groups. There are four DH groups: 1, 2, 5, and 7.
During tunnel setup, VPN peers negotiate which DH group to use.
IPsec is a framework of open standards. IPsec spells out the messaging to secure the communications but relies on existing algorithms. The two main IPsec framework protocols are AH and ESP. The IPsec protocol is the first building block of the framework. The choice of AH or ESP establishes which other building blocks are available:
Authentication Header
AH achieves authenticity by applying a keyed one-way hash function to the packet to create a hash or message digest. The hash is combined with the text and is transmitted. The receiver detects changes in any part of the packet that occur during transit by performing the same one-way hash function on the received packet and comparing the result to the value of the message digest that the sender supplied. The fact that the one-way hash also involves a shared secret key between the two systems means that authenticity is assured.
The AH function is applied to the entire packet, except for any mutable IP header fields that change in transit. For example, Time to Live (TTL) fields that are modified by the routers along the transmission path are mutable fields.
The AH process occurs in this order:
1. The IP header and data payload are hashed using the shared secret key.
2. The hash builds a new AH header, which is inserted into the original packet.
3. The new packet is transmitted to the IPsec peer router.
4. The peer router hashes the IP header and data payload using the shared secret key, extracts the transmitted hash from the AH header, and compares the two hashes.
The hashes must match exactly. If one bit is changed in the transmitted packet, the hash output on the received packet changes and the AH header will not match.
AH supports the HMAC-MD5 and HMAC-SHA-1 algorithms. AH can have problems if the environment uses NAT.
ESP
ESP provides confidentiality by encrypting the payload. It supports a variety of symmetric encryption algorithms. If ESP is selected as the IPsec protocol, an encryption algorithm must also be selected. The default algorithm for IPsec is 56-bit DES. Cisco products also support the use of 3DES, AES, and SEAL for stronger encryption.
ESP can also provide integrity and authentication. First, the payload is encrypted. Next, the encrypted payload is sent through a hash algorithm, HMAC-MD5 or HMAC-SHA-1. The hash provides authentication and data integrity for the data payload.
Optionally, ESP can also enforce anti-replay protection. Anti-replay protection verifies that each packet is unique and is not duplicated. This protection ensures that a hacker cannot intercept packets and insert changed packets into the data stream. Anti-replay works by keeping track of packet sequence numbers and using a sliding window on the destination end. When a connection is established between a source and destination, their counters are initialized at zero. Each time a packet is sent, a sequence number is appended to the packet by the source. The destination uses the sliding window to determine which sequence numbers are expected. The destination verifies that the sequence number of the packet is not duplicated and is received in the correct order. For example, if the sliding window on the destination is set to one, the destination is expecting to receive the packet with the sequence number one. After it is received, the sliding window moves to two. When detection of a replayed packet occurs, such as the destination receiving a second packet with the sequence number of one, an error message is sent, the replayed packet is discarded, and the event is logged.
Anti-replay is typically used in ESP, but it is also supported in AH.
The original data is well protected by ESP because the entire original IP datagram and ESP trailer are encrypted. With ESP authentication, the encrypted IP datagram and trailer, and the ESP header, are included in the hashing process. Last, a new IP header is attached to the authenticated payload. The new IP address is used to route the packet through the Internet.
When both authentication and encryption are selected, encryption is performed first. One reason for this order of processing is that it facilitates rapid detection and rejection of replayed or bogus packets by the receiving device. Prior to decrypting the packet, the receiver can authenticate inbound packets. By doing this, it can quickly detect problems and potentially reduce the impact of DoS attacks.
ESP and AH can be applied to IP packets in two different modes, transport mode and tunnel mode.
Transport Mode
In transport mode, security is provided only for the Transport Layer of the OSI model and above. Transport mode protects the payload of the packet but leaves the original IP address in plaintext. The original IP address is used to route the packet through the Internet.
ESP transport mode is used between hosts. Transport mode works well with GRE, because GRE hides the addresses of the end devices by adding its own IP.
Tunnel Mode
Tunnel mode provides security for the complete original IP packet. The original IP packet is encrypted and then it is encapsulated in another IP packet. This is known as IP-in-IP encryption. The IP address on the outside IP packet is used to route the packet through the Internet.
ESP tunnel mode is used between a host and a security gateway or between two security gateways. For gateway-to-gateway applications, rather than load IPsec on all of the computers at the remote and corporate offices, it is easier to have the security gateways perform the IP-in-IP encryption and encapsulation.
ESP tunnel mode is used in the IPsec remote-access application. A home office might not have a router to perform the IPsec encapsulation and encryption. In this case, an IPsec client running on the PC performs the IPsec IP-in-IP encapsulation and encryption. At the corporate office, the router de-encapsulates and decrypts the packet.
The VPN process involves selecting and applying many parameters. How does IPsec actually negotiate these security parameters?
The IPsec VPN solution negotiates key exchange parameters, establishes a shared key, authenticates the peer, and negotiates the encryption parameters. The negotiated parameters between two devices are known as a security association (SA).
Security Associations
An SA is a basic building block of IPsec. Security associations are maintained within a SA database (SADB), which is established by each device. A VPN has SA entries defining the IPsec encryption parameters as well as SA entries defining the key exchange parameters.
All cryptographic systems, including the Caesar cipher, Vigenere cipher, Enigma machine, to modern encryption algorithms, must deal with key management issues. Diffie-Hellman (DH) is used to create the shared secret key. However, IPsec uses the Internet Key Exchange (IKE) protocol to establish the key exchange process.
Instead of transmitting keys directly across a network, IKE calculates shared keys based on the exchange of a series of data packets. This disables a third party from decrypting the keys even if the third party captured all exchanged data that is used to calculate the keys.
IKE is layered on UDP and uses UDP port 500 to exchange IKE information between the security gateways. UDP port 500 packets must be permitted on any IP interface involved in connecting a security gateway peer.
IKE is defined in RFC 2409. It is a hybrid protocol, combining the Internet Security Association and Key Management Protocol (ISAKMP) and the Oakley and Skeme key exchange methods. ISAKMP defines the message format, the mechanics of a key-exchange protocol, and the negotiation process to build an SA for IPsec. ISAKMP does not define how keys are managed or shared between the two IPsec peers. Oakley and Skeme have five defined key groups. Of these groups, Cisco routers support Group 1 (768-bit key), Group 2 (1024-bit key), and Group 5 (1536-bit key).
IKE combines these protocols to build secure IPsec connections between devices. It establishes SAs that are mutually agreeable to each peer. Each peer must have identical ISAKMP and IPsec parameters to establish an operational and secure VPN. Note that the terms ISAKMP and IKE are commonly used by industry people to refer to IKE.
An alternative to using IKE is to manually configure all parameters required to establish a secure IPsec connection. This process is impractical because it does not scale.
How does IKE work?
To establish a secure communication channel between two peers, the IKE protocol executes two phases:
In Phase 1, the transform sets, hash methods, and other parameters are determined. An IKE session begins with a router (the initiator) sending a proposals to another router (the responder). The proposal sent by the initiator defines which encryption and authentication protocols are acceptable, how long keys should remain active, and whether perfect forward secrecy (PFS) should be enforced. PFS is a property that states that keys used to protect data are not used to derive any other keys. PFS ensures that if one key is compromised, previous and subsequent keys remain secure.
Three exchanges transpire during IKE Phase 1. These are referred to as the first, second, and third exchanges.
First Exchange
The first exchange between the initiator and the responder establishes the basic security policy. Peers negotiate and agree on the algorithms and hashes that are used to secure the IKE communications. Rather than negotiate each protocol individually, the protocols are grouped into sets, called IKE policy sets. The IKE policy sets are exchanged first.
The initiator first transmits proposals for the encryption and authentication schemes to be used. The responder looks for a matching ISAKMP policy. The responder chooses a proposal that is best suited to the security situation and then sends that proposal to the initiator. If a policy match is found between the peers, IKE Phase 1 continues. If no match is found, the tunnel is torn down.
Policy set numbers are only locally significant to a VPN device. The policy set numbers do not have to match between two VPN peers. In a point-to-point application, each end might need only a single IKE policy set to be defined. In a hub-and-spoke environment, the central site might require multiple IKE policy sets to satisfy all the remote peers.
Second Exchange
The second exchange creates and exchanges the DH public keys between the two endpoints. DH allows two parties that have no prior knowledge of each other to establish a shared secret key over an insecure communications channel.
The two peers run the DH key exchange protocol to acquire the keying material that is needed by the various encryption and hashing algorithms upon which IKE and IPsec will ultimately agree.
Several levels of DH key exchanges are available in Cisco IOS Software:
It is important to have sufficient keying material for the algorithms chosen. Using the DH algorithm, each peer generates a shared secret without actually exchanging secrets. All further negotiations are encrypted using the DH-generated secret key.
Third Exchange
Each end device must authenticate the other end device before the communication path is considered secure. The last exchange of IKE Phase 1 authenticates the remote peer.
The initiator and recipient authenticate each other using one of the three data-origin authentication methods:
The Phase 1 SA negotiations are bidirectional, which means that data can be sent and received using the same encryption key. Even if the SA negotiation data stream between the two IPsec peers is compromised, there is little chance that the encryption keys could be decrypted.
The three exchanges of IKE Phase 1 transpire in what is called main mode. The outcome of main mode is a secure communication path for subsequent exchanges between the peers.
IKE Phase 1 can also transpire in aggressive mode. Aggressive mode is faster than main mode because there are fewer exchanges. Aggressive mode compresses the IKE SA negotiation phases into one exchange with three packets. Main mode requires three exchanges with six packets.
Aggressive mode packets include:
Aggressive mode negotiation is quicker, and the initiator and responder IDs pass in plaintext.
After the IKE SA is established, Phase 2 negotiation begins.
The purpose of IKE Phase 2 is to negotiate the IPsec security parameters that will be used to secure the IPsec tunnel. IKE Phase 2 is called quick mode and can only occur after IKE has established the secure tunnel in Phase 1. SAs are negotiated by the IKE process ISAKMP on behalf of IPsec, which needs encryption keys for operation. Quick mode negotiates the IKE Phase 2 SAs. In this phase, the SAs that IPsec uses are unidirectional; therefore, a separate key exchange is required for each data flow.
IKE Phase 2 performs the following functions:
Quick mode also renegotiates a new IPsec SA when the IPsec SA lifetime expires. Basically, quick mode refreshes the keying material that creates the shared secret key based on the keying material that is derived from the DH exchange in Phase 1.
A VPN is a communications channel that is used to form a logical connection between two endpoints over a public network. VPNs do not necessarily include encryption or authentication. IPsec VPNs rely on the IKE protocol to establish secure communications.
IPsec VPN negotiation involves several steps, which include Phase 1 and Phase 2 of IKE negotiation.
1. An IPsec tunnel is initiated when host A sends "interesting" traffic to host B. Traffic is considered interesting when it travels between the IPsec peers and meets the criteria that is defined in the crypto access control list (ACL).
2. IKE Phase 1 begins. The IPsec peers negotiate the established IKE security association (SA) policy. When the peers are authenticated, a secure tunnel is created using Internet Security Association and Key Management Protocol (ISAKMP).
3. IKE Phase 2 begins. The IPsec peers use the authenticated secure tunnel to negotiate IPsec SA transforms. The negotiation of the shared policy determines how the IPsec tunnel is established.
4. The IPsec tunnel is created and data is transferred between the IPsec peers based on the IPsec parameters that are configured in the IPsec transform sets.
5. The IPsec tunnel terminates when the IPsec SAs are deleted or when their lifetime expires.
Some basic tasks must be completed to configure a site-to-site IPsec VPN.
Task 1. Ensure that ACLs configured on the Interface are compatible with IPsec configuration. Usually there are restrictions on the interface that the VPN traffic uses; for example, block all traffic that is not IPsec or IKE.
Task 2. Create an ISAKMP policy to determine the ISAKMP parameters that will be used to establish the tunnel.
Task 3. Define the IPsec transform set. The definition of the transform set defines the parameters that the IPsec tunnel uses. The set can include the encryption and integrity algorithms.
Task 4. Create a crypto ACL. The crypto ACL defines which traffic is sent through the IPsec tunnel and protected by the IPsec process.
Task 5. Create and apply a crypto map. The crypto map groups the previously configured parameters together and defines the IPsec peer devices. The crypto map is applied to the outgoing interface of the VPN device.
The first step in configuring Cisco IOS ISAKMP is to ensure that the existing ACLs on perimeter routers, firewalls, or other routers do not block IPsec traffic. Perimeter routers typically implement a restrictive security policy with ACLs, where only specific traffic is permitted, and all other traffic is denied. Such a restrictive policy blocks IPsec traffic. Therefore, specific permit statements must be added to the ACL.
Ensure that the ACLs are configured so that ISAKMP, Encapsulating Security Payload (ESP), and Authentication Header (AH) traffic is not blocked at the interfaces used by IPsec.
To permit AH, ESP, and ISAKMP on an IPsec interface while denying any other unnecessary traffic, an existing ACL must be edited or a new ACL created.
Use the show access-list command to verify the entries.
The second major task in configuring Cisco IOS ISAKMP support is to define the parameters within the IKE policy. IKE uses these parameters during negotiation to establish ISAKMP peering between two IPsec endpoints.
Multiple ISAKMP policies can be configured on each peer participating in IPsec. When configuring policies, each policy must be given a unique priority number. Use the command crypto isakmp policy priority, where the priority is a number that uniquely identifies the IKE policy and assigns a priority to the policy. Use an integer from 1 to 10,000, with 1 being the highest priority and 10,000 the lowest. Assign the most secure policy the smallest available number.
The crypto isakmp policy command invokes ISAKMP policy configuration command mode. Set the ISAKMP parameters in this mode. If commands are not explicitly configured, default values are used. For example, if the hash command is not explicitly configured, IKE uses the default SHA value.
Two endpoints must negotiate ISAKMP policies before they agree on the SA to use for IPsec.
When the ISAKMP negotiation begins in IKE Phase 1 main mode, the peer that initiates the negotiation sends all its policies to the remote peer, and the remote peer tries to find a match with its own policies. The remote peer looks for a match by comparing its own highest priority policy against the policies it received from the other peer. The remote peer checks each of its policies in order of its priority (highest priority first) until a match is found.
A match is made when both policies from the two peers contain the same encryption, hash, authentication, DH parameter values, and when the policy of the remote peer specifies a lifetime less than or equal to the lifetime of the policy that is being compared. If the lifetimes are not identical, the shorter lifetime from the remote peer policy is used. Assign the most secure policy the smallest available priority number so that the most secure policy finds a match before any less secure policies are configured.
If an acceptable match is not found, ISAKMP refuses negotiation, and IPsec is not established. If a match is found, ISAKMP completes the main mode negotiation, and IPsec SAs are created during IKE Phase 2 quick mode.
PSKs are required for encryption. At a given peer, the same key can be configured to be shared with multiple remote peers. A more secure approach is to specify different keys to share between different pairs of peers.
Configure a PSK with the crypto isakmp key global configuration command. This key must be configured if the authentication pre-share command was configured in the ISAKMP policy.
crypto isakmp key keystring address peer-address
crypto isakmp key keystring hostname hostname
By default, the ISAKMP identity is set to use the IP address. To use the hostname parameter, the ISAKMP identity must be configured to use the host name with the crypto isakmp identity hostname global configuration mode command. In addition, DNS must be accessible to resolve the hostname.
A transform set is a combination of individual IPsec transforms that are designed to enact a specific security policy for traffic. During the ISAKMP IPsec SA negotiation that occurs in IKE Phase 2 quick mode, the peers agree to use a particular transform set for protecting a particular data flow.
Transform sets consist of a combination of an AH transform, an ESP transform, and the IPsec mode (either tunnel or transport mode). Transform sets are limited to one AH transform and one or two ESP transforms. Multiple transform sets can be configured. Then one or more of these transform sets can be specified in a crypto map entry. The IPsec SA negotiation uses the transform set that is defined in the crypto map entry to protect the data flows that are specified by the ACL of that crypto map entry.
To define a transform set, specify one to four transforms using the crypto ipsec transform-set global configuration command. This command invokes crypto-transform configuration mode.
crypto ipsec transform-set transform-set-name transform1 [transform2] [transform3] [transform4]
Each transform represents an IPsec security protocol (AH or ESP) plus the associated algorithm. These protocols and algorithms are specified within the crypto-transform configuration mode. In a transform set, specify the AH protocol, the ESP protocol, or both. If an ESP protocol is specified in a transform set, an ESP encryption transform set or an ESP encryption transform set and an ESP authentication transform set must be specified.
During the negotiation, the peers search for a transform set that has the same criteria (the combination of protocols, algorithms, and other settings) at both peers. When a transform set is found, it is selected and applied to the protected traffic as part of the IPsec SAs of both peers.
When ISAKMP is not used to establish SAs, a single transform set must be used. In this instance, the transform set is not negotiated.
Transform sets are negotiated during IKE Phase 2 quick mode. When configuring multiple transform sets, configure the transforms from most to least secure, according to the network security policy.
IPsec peers search for a transform set that matches at both ends and agree on one unidirectional transform proposal per SA. For example, assume R1 and R2 are negotiating a transform set. R1 has transform sets ALPHA, BETA, and CHARLIE configured, while R2 has RED, BLUE, and YELLOW configured. Each R1 transform set is compared against each R2 transform set in succession. R1 transform sets ALPHA, BETA, and CHARLIE are compared to R2 transform set RED. The result is no match. All the R1 transform sets are then compared against R2 transform set BLUE. Finally, the R1 transform sets are compared to R2 transform set YELLOW. YELLOW is matched against the R1 transform set CHARLIE. When a transform set match is found, it is selected and applied to the protected traffic as part of the IPsec SAs of both peers.
Crypto ACLs identify the traffic flows to protect. Outbound crypto ACLs select outbound traffic that IPsec should protect. Traffic that is not selected is sent in plaintext. If desired, inbound ACLs can be created to filter and discard traffic that should have been protected by IPsec.
Extended IP ACLs select IP traffic to encrypt based on protocol, IP address, network, subnet, and port. Although the ACL syntax is unchanged from extended IP ACLs, the meanings are slightly different for crypto ACLs. For example, permit specifies that matching packets must be encrypted, and deny specifies that matching packets are not encrypted. Traffic is not necessarily dropped because of a deny statement. Crypto ACLs are processed in a similar fashion to an extended IP ACL applied to outbound traffic on an interface.
The command syntax for the basic form of an extended IP ACL is:
access-list access-list-number {permit | deny} protocol source source-wildcard destination destination-wildcard
Outbound crypto ACLs define the interesting traffic to be encrypted. All other traffic passes as plaintext.
Inbound crypto ACLs inform the router of which traffic should be received as encrypted traffic. When traffic matches the permit statement, the router expects that traffic to be encrypted. If inbound plaintext traffic is received that matches a permit statement in the crypto ACL, that traffic is dropped. This drop occurs because the plaintext traffic was expected to be protected by IPsec and encrypted, but was not.
An administrator might want certain traffic to receive one combination of IPsec protection (authentication only) and other traffic to receive a different combination (both authentication and encryption). To do so, create two different crypto ACLs to define the two different types of traffic. Different crypto map entries then use these ACLs to specify different IPsec policies.
Try to be as restrictive as possible when defining which packets to protect in a crypto ACL. Using the any keyword to specify source or destination addresses is not recommended. The permit any any statement is strongly discouraged because it causes all outbound traffic to be protected and all protected traffic to be sent to the peer that is specified in the corresponding crypto map entry. Then, all inbound packets that lack IPsec protection are silently dropped, including packets for routing protocols, NTP, echo, echo response, and others. If the any keyword must be used in a permit statement, preface the statement with a series of deny statements to filter out traffic that should not be protected.
The crypto ACL is associated with a crypto map, which in turn is assigned to a specific interface.
Symmetric crypto ACLs must be configured for use by IPsec. When a router receives encrypted packets back from an IPsec peer, it uses the same ACL to determine which inbound packets to decrypt by viewing the source and destination addresses in the ACL in reverse order. The ACL criteria are applied in the forward direction to traffic exiting a router, and in the backward direction to traffic entering the router, so that the outbound ACL source becomes the inbound ACL destination.
For example, assume that for Site 1, IPsec protection is applied to traffic between hosts on the 10.0.1.0/24 network as the data exits the R1 S0/0/0 interface in route to Site 2 hosts on the 10.0.2.0/24 network. For traffic from Site 1 hosts on the 10.0.1.0/24 network to Site 2 hosts on the 10.0.2.0/24 network, the ACL entry on R1 is evaluated as follows:
For incoming traffic from Site 2 hosts on the 10.0.2.0/24 network to Site 1 hosts on the 10.0.1.0/24 network, that same ACL entry on R1 is evaluated as follows:
Crypto map entries that are created for IPsec combine the needed configuration parameters of IPsec SAs, including the following parameters:
Crypto map entries with the same crypto map name but different map sequence numbers are grouped into a crypto map set.
Only one crypto map can be set to a single interface. The crypto map set can include a combination of Cisco Encryption Technology (CET) and IPsec using IKE. Multiple interfaces can share the same crypto map set if the same policy is applied to multiple interfaces. If more than one crypto map entry is created for a given interface, use the sequence number (seq-num) of each map entry to rank the map entries. The smaller the sequence number, the higher the priority. At the interface that has the crypto map set, traffic is evaluated against higher priority map entries first.
Create multiple crypto map entries for a given interface if any of these conditions exist:
Use the crypto map global configuration command to create or modify a crypto map entry and enter crypto map configuration mode. Set the crypto map entries that reference dynamic maps to the lowest priority in a crypto map set (they should have the largest sequence numbers).The command syntax and parameter definitions are as follows:
crypto map map-name seq-num cisco
crypto map map-name seq-num ipsec-manual
crypto map map-name seq-num ipsec-isakmp [dynamic dynamic-map-name]
no crypto map map-name [seq-num]
Using the crypto map command in global configuration mode enters crypto-map configuration mode. From here, various IPsec components are configured, including which crypto ACL, peer address, and transform set to use.
ACLs for crypto map entries that are tagged as IPsec-manual are restricted to a single permit entry, and subsequent entries are ignored. The SAs that are established by that particular crypto map entry are for a single data flow only. To support multiple manually established SAs for different kinds of traffic, define multiple crypto ACLs and then apply each one to a separate IPsec-manual crypto map entry. Each ACL includes one permit statement that defines the traffic that it must protect.
Two peers can be specified in a crypto map for redundancy. If the first peer cannot be contacted, the second peer is used. There is no limit to the number of redundant peers that can be configured.
After the crypto map parameters are configured, assign the crypto map set to interfaces using the crypto map interface configuration command.
The crypto map is applied to the outgoing interface of the VPN tunnel using the crypto map command in interface configuration mode.
crypto map map-name
map-name is the name of the crypto map set to apply to the interface.
Make sure that the routing information that is needed to send packets into the tunnel is also configured.
All IP traffic passing through the interface where the crypto map is applied is evaluated against the applied crypto map set. If a crypto map entry sees outbound IP traffic that should be protected and the crypto map specifies the use of IKE, an SA is negotiated with the remote peer according to the parameters that are included in the crypto map entry.
VPNs can be complex and sometimes do not operate as expected. For this reason, there are a variety of useful commands to verify the operation of VPNs and to troubleshoot when necessary.
The best time to become familiar with these commands and their output is when the network is operating correctly. This way, anomalies can be detected when using them for troubleshooting.
To view all configured crypto maps, use the show crypto map command. This command verifies configurations and shows the SA lifetime. The show running-config command also reveals many of these same settings.
Use the show crypto isakmp policy command to display configured IKE policies and the default IKE policy settings. This command is useful because it reveals all ISAKMP (IKE) configuration information.
Use the show crypto ipsec transform-set command to show all configured transform sets. Because transform sets determine the level of protection that the data will have as it is tunneled, it is important to verify the strength of the IPsec protection policy.
One of the more useful commands is show crypto ipsec sa. If the output indicates that an SA is established, the rest of the configuration is assumed to be working. Within the output, the pkts encrypt and pkts decrypt values indicate that traffic is flowing through the tunnel.
A similar useful command is show crypto isakmp sa. This command displays all current IKE SAs. QM_IDLE status indicates an active IKE SA.
To use debugging commands to troubleshoot VPN connectivity, connect to the Cisco IOS router with a terminal connection.
The debug crypto isakmp command displays detailed information about the IKE Phase 1 and IKE Phase 2 negotiation processes. The debug crypto ipsec command displays detailed information about IPsec events.
As with other debug commands, use the debug crypto isakmp command with caution, because debug processes can cause performance problems on the device. Use the undebug all command to turn off the debug as soon as possible.
In addition to configuring IPsec VPNs via CLI, it is possible to configure them using an SDM wizard.
To select and start a VPN wizard, follow these steps:
Step 1. Click Configure in the main toolbar.
Step 2. Click the VPN button on the left to open the VPN page.
Step 3. Choose a wizard from the VPN window.
Step 4. Click the VPN implementation subtype.
Step 5. Click the Launch the selected task button to start the wizard.
The Cisco SDM VPN wizards use two sources to create a VPN connection: user input during a step-by-step wizard process, and preconfigured VPN components.
The Cisco SDM provides some default VPN components: two IKE policies and an IPsec transform set for the quick setup wizard.
The VPN wizards create other components during the step-by-step configuration process. Some components must be configured before the wizards can be used. For instance, PKI components must be configured before using the PKI wizard.
The VPN navigation bar contains three major sections:
Use a web browser to start the Cisco SDM on a router. Select the VPN wizard by choosing Configure > VPN > Site-to-Site VPN.
To create and configure a classic site-to-site VPN, click the Create a Site-to-Site VPN radio button on the Create Site-to-Site VPN tab. Then click the Launch the selected task button.
A window displays the Quick setup option and the Step by step wizard option.
The Quick setup option uses the Cisco SDM default IKE policies and IPsec transform sets. It enables a junior administrator to quickly set up an IPsec VPN using best practice security parameters.
The Step by step wizard allows the administrator to specify all the finer details of the IPsec VPN.
Click the Next button to configure the parameters of the VPN connection.
The quick setup option uses a single window to configure the VPN connection and includes the following parameters:
Cisco SDM provides a default IKE policy to govern authentication, a default transform set to control data encryption, and a default IPsec rule that encrypts all traffic between the router and the remote device.
When all parameters are set, verify the configuration on the summary page before clicking Finish.
Quick setup is best used when both the local router and the remote system are Cisco routers using Cisco SDM. Quick setup configures 3DES encryption if it is supported by the Cisco IOS image. Otherwise, it configures DES encryption. If AES or SEAL encryption is required, the Step-by-Step wizard must be used.
The Step-by-Step wizard requires multiple steps to configure the VPN connection and includes the following parameters:
The first task in the Step-by-Step wizard is to configure the connection settings.
Step 1. Choose the outside interface to connect to the IPsec peer over the untrusted network.
Step 2. Specify the IP address of the peer.
Step 3. Choose the authentication method and specify the credentials. Use long and random PSKs to prevent brute-force and dictionary attacks against IKE.
Step 4. Click Next to proceed to the next task.
The second task in the Step-by-Step wizard is to configure IKE proposals. A custom IKE proposal can be created, or the default IKE proposal can be used.
Custom IKE Proposal
To create a custom IKE proposal, a new IKE must be added.
Step 1. Click the Add button to define a proposal and specify the IKE proposal priority, encryption algorithm, hashing algorithm, IKE authentication method, DH group, and IKE lifetime.
Step 2. Click OK when configuring the IKE proposal is completed.
Step 3. When finished with adding IKE policies, choose the proposal to use. Click Next to proceed to the next task.
Predefined IKE Proposal
To use the predefined IKE proposal, click Next on the IKE Proposal page. The predefined IKE proposal is chosen by default.
The third task in the Step-by-Step wizard is to configure a transform set. A custom IPsec transform set can be created, or a predefined IPsec transform set can be used.
Custom IPsec Transform Set
To create a custom IPsec transform set, a new IPsec transform set must be added.
Step 1. Click the Add button to define the transform set and specify the name, integrity algorithm, encryption algorithm, mode of operation, and optional compression.
Step 2. Click OK when configuring the transform set is completed.
Step 3. When finished adding transform sets, choose the transform set to use, and click Next to proceed to the next task.
Predefined IPsec Transform Set
To use the IPsec transform set, click Next on the Transform Set page. The predefined transform set is chosen by default.
The fourth task in the Step-by-Step wizard is to configure which traffic needs protection.
To protect all traffic from one IP subnet to another:
Step 1. From the Traffic to Protect window, click the Protect all traffic between the following subnets radio button.
Step 2. Define the IP address and subnet mask of the local network where IPsec traffic originates.
Step 3. Define the IP address and subnet mask of the remote network where IPsec traffic is sent.
To specify a Custom ACL (IPsec rule) that defines the traffic types to be protected:
Step 1. From the Traffic to Protect window, click the Create/Select an access-list for IPSec traffic radio button.
Step 2. Click the ellipsis (...) button to choose an existing ACL or to create a new one.
Step 3. To use an existing ACL, choose the Select an existing rule (ACL) option. To create a new ACL, choose the Create a new rule (ACL) and select option.
When creating a new ACL to define traffic that needs protection, a window that lists the created access rule entries is displayed:
Step 1. Give the access rule a name and description.
Step 2. Click the Add button to start adding rule entries.
After a new ACL is created, entries must be specified within the ACL.
Step 1. Choose an action from the Select an Action list box and enter a description of the rule entry in the Description text box.
Step 2. Define the source hosts or networks in the Source Host/Network pane, and the destination hosts or networks in the Destination Host/Network pane. Each rule entry defines one pair of source and destination addresses or networks. Be sure to use wildcard bits and not the subnet mask bits in the Wildcard Mask field.
Step 3. (Optional) To provide protection for a specific protocol, choose the protocol radio button (TCP, UDP, or ICMP) and the port numbers. If IP is chosen as the protocol, the rule applies to all IP traffic.
At the end of the configuration, the wizard presents a summary of the configured parameters. To modify the configuration, click the Back button. Click the Finish button to complete the configuration.
After the IPsec VPN is configured, it is necessary to test the VPN to verify operation.
To test the configuration of the VPN tunnel, choose Configure > VPN > Site-to-Site VPN > Edit Site-to-Site VPN and click the Test Tunnel button.
The Generate Mirror button can also be clicked to generate a mirroring configuration that is required on the other end of the tunnel. This is useful if the other router does not have Cisco SDM and must use the command-line interface (CLI) to configure the tunnel.
To see all IPsec tunnels, their parameters, and status, choose Monitor > VPN Status > IPsec Tunnels.
How many hours are spent by employees traveling to and from work everyday? What if there are traffic jams? How could these hours be put to productive use? The answer is telecommuting.
Telecommuting is sometimes referred to as teleworking. Telecommuting employees have flexibility in location and hours. Employers offer telecommuting because they can save on real estate, utility, and other overhead costs. Organizations that have the greatest success with a telecommuting program ensure that telecommuting is voluntary, subject to management discretion, operationally feasible, and results in no additional costs.
Telecommuting organizations take full advantage of new technologies and new ways of working. With telecommuting, the focus is on the actual work performed rather than on the location where it is performed. This aspect of telecommuting moves us closer to a global society, allowing individuals across the world to work together. As one of the key workplace transformers of the next decade, there is little doubt that it will inevitably and dramatically reshape how work is performed.
Telecommuting offers organizational, social, and environmental benefits. Studies have shown that telecommuting improves employee lifestyles by decreasing job-related stresses. It can also accommodate those with health problems or disabilities. Telecommuting helps reduce energy consumption by decreasing transportation related pollution. It also increases organizational profits, improves recruitment and retention, and can offer possibilities for increased service and international reach. Telecommuters in different time zones can ensure that a company is virtually open for business around the clock.
Although telecommuting has many benefits, there may be some drawbacks. For example, telecommuters working from home can experience distractions that they would not have at work. Additionally, companies that offer telecommuting programs have to manage more risk, because data must travel across public networks, and organizations must rely on employees to maintain secure systems.
Telecommuters typically need high-speed access to the Internet. This access can be provided using broadband connections, such as DSL, Cable or satellite Internet connections. Although a dialup connection can be used to access the Internet, the access speed is very slow and is not generally considered adequate for telecommuting.
Laptop or desktop computers are also required, and many implementations also require a VoIP phone to provide seamless telephone services.
Security is a huge concern for companies. Remote access to corporate locations is implemented using remote VPN access.
The ubiquity of the Internet, combined with today's VPN technologies, allows organizations to cost-effectively and securely extend the reach of their networks to anyone, anyplace, anytime.
VPNs have become the logical solution for remote-access connectivity for many reasons. VPNs provide secure communications with access rights tailored to individual users, such as employees, contractors, and partners. They also enhance productivity by extending the corporate network and applications securely while reducing communication costs and increasing flexibility.
Using VPN technology, employees can essentially take their office, including access to emails and network applications, with them. VPNs can also allow contractors and partners to have limited access to the specific servers, web pages, or files required. This network access allows them to contribute to business productivity without compromising network security.
There are two primary methods for deploying remote-access VPNs:
The type of VPN method implemented is based on the access requirements of the users and the organization's IT processes.
Both IPsec and SSL VPN technologies offer access to virtually any network application or resource. SSL VPNs offer such features as easy connectivity from non-company-managed desktops, little or no desktop software maintenance, and user-customized web portals upon login.
IPsec exceeds SSL in many significant ways:
When security is an issue, IPsec is the superior choice. If support and ease of deployment are the primary issues, consider SSL.
IPsec and SSL VPN are complementary because they solve different problems. Depending on its needs, an organization can implement one or both. This complementary approach allows a single device such as an ISR router or an ASA firewall appliance to address all remote-access user requirements. While many solutions offer either IPsec or SSL, Cisco remote-access VPN solutions offer both technologies integrated on a single platform with unified management. Offering both IPsec and SSL technologies enables organizations to customize their remote-access VPN without any additional hardware or management complexity.
Cisco IOS SSL VPN is an emerging technology that provides remote-access connectivity from almost any Internet-enabled location using a web browser and its native SSL encryption. Originally developed by Netscape, SSL has been universally accepted on the Web.
SSL VPN does not require a software client to be preinstalled on the endpoint host. It provides remote-access connectivity for corporate resources to any authorized user from any Internet-enabled location.
The SSL protocol supports a variety of different cryptographic algorithms for operations such as authenticating the server and client to each other, transmitting certificates, and establishing session keys. Cisco SSL VPN solutions can be customized for businesses of any size. These solutions deliver many remote-access connectivity features and benefits:
SSL VPNs provide different types of access:
SSL VPN provides three modes of remote access on Cisco IOS routers: clientless, thin client, and full client. ASA devices have two modes: clientless (which includes clientless and thin client port forwarding) and AnyConnect client (which replaces full tunnel).
Clientless Access Mode
In clientless mode, the remote user accesses the internal or corporate network using a web browser on the client machine. Clientless access requires no specialized VPN software or applet on the user desktop. All VPN traffic is transmitted and delivered through a standard web browser. No other software is required, eliminating many support issues. Using a clientless connection, all web-enabled and some client/server applications, such as intranets, applications with Web interfaces, email, calendaring, and file servers, can be accessed.
Not all client/server applications are accessible to SSL clients; however, this limited access is often a perfect fit for business partners or contractors who should have access only to a limited set of resources on the organization's network. It does not work for employees that require full network access.
Thin Client Mode
Thin client mode, sometimes called TCP port forwarding, assumes that the client application uses TCP to connect to a well-known server and port. In this mode, the remote user downloads a Java applet by clicking the link provided on the portal page. The Java applet acts as a TCP proxy on the client machine for the services configured on the SSL VPN gateway. The Java applet starts a new SSL connection for every client connection.
The Java applet initiates an HTTP request from the remote user client to the SSL VPN gateway. The name and port number of the internal email server is included in the HTTP request. The SSL VPN gateway creates a TCP connection to that internal email server and port.
Thin client mode is often referred to as a type of clientless mode and can be used anywhere that clientless VPNs are supported. It extends the capability of the cryptographic functions of the web browser to enable remote access to TCP-based applications such as POP3, SMTP, IMAP, Telnet, and SSH.
Full Tunnel Client Access Mode
Full tunnel client mode enables access to the corporate network completely over an SSL VPN tunnel, which is used to move data at the Network (IP) Layer. This mode supports most IP-based applications, such as Microsoft Outlook, Microsoft Exchange, Lotus Notes Email, and Telnet. Being part of the SSL VPN is transparent to the applications run on the client. A Java applet is downloaded to handle the tunneling between the client host and the SSL VPN gateway. The user can use any application as if the client host was on the internal network.
This VPN client, because it is dynamically downloaded and updated without any manual software distribution or interaction from the end user, requires little or no desktop support by IT organizations, thereby minimizing deployment and operations costs. Like clientless access, full network access offers full access control customization based on the access privileges of the end user. Full network access is a natural choice for employees who need remote access to the same applications and network resources that they use when in the office or for any client/server application that cannot be delivered across a web-based clientless connection.
Establishing an SSL session involves a few steps:
Step 1. The user makes an outbound connection to TCP port 443.
Step 2. The router responds with a digital certificate, which contains a public key that is digitally signed by a trusted certificate authority (CA).
Step 3. The user's computer generates a shared secret key that both parties use.
Step 4. The shared secret is encrypted with the public key of the router and transmitted to the router. The router software is able to easily decrypt the packet using its private key. Now both participants in the session know the shared secret key.
Step 5. The key is used to encrypt the SSL session.
SSL utilizes encryption algorithms with key lengths from 40 to 128 bits.
Before SSL VPN services are implemented in Cisco IOS routers, the current environment must be analyzed to determine which features and modes might be useful in the implementation.
There are many SSL VPN design considerations:
SSL VPNs are a viable option for many organizations, however, the configuration of SSL VPNs is beyond the scope of this course. Visit www.cisco.com to learn about the required configuration commands to implement SSL VPNs as well as to download reference guides.
While SSL VPNs are useful in many instances, many applications require the security of an IPsec VPN connection for authentication and to encrypt data. Establishing a VPN connection between two sites can be complicated and typically requires coordination between the network administrators at each site to configure the VPN parameters. When deploying VPNs for telecommuters and small branch offices, ease of deployment is critical if technical resources are not available for VPN configuration on the remote site router.
The Cisco Easy VPN solution feature offers flexibility, scalability, and ease of use for site-to-site and remote-access VPNs. It consists of three components:
Most of the VPN parameters are defined on the Cisco IOS Easy VPN Server to simplify deployment. When a remote client initiates a VPN tunnel connection, the Cisco Easy VPN Server pushes the IPsec policies to the client and creates the corresponding IPsec VPN tunnel connection.
The remote devices can be mobile workers running the Cisco Easy VPN client software on PCs to easily establish VPN connections with the Cisco Easy VPN Server-enabled device through the Internet. It can also be a Cisco device running the Cisco Easy VPN Remote feature, enabling it to be a client of the Easy VPN Server. This means that individuals at small branch offices no longer need to run VPN client software on their PCs.
The Cisco Easy VPN Server makes it possible for mobile and remote workers using VPN Client software on their PCs to create secure IPsec tunnels to access their headquarters' intranet where critical data and applications exist. It enables Cisco IOS routers and Cisco PIX and ASA Firewalls to act as VPN head-end devices in site-to-site or remote-access VPNs. Remote office devices use the Cisco Easy VPN Remote feature or the Cisco VPN Client application to connect to the server, which then pushes defined security policies to the remote VPN device. This ensures that those connections have up-to-date policies in place before the connection is established.
The Cisco Easy VPN Remote enables Cisco IOS routers, Cisco PIX Firewalls, and Cisco VPN 3002 hardware clients or software clients to act as remote VPN clients. These devices can receive security policies from a Cisco Easy VPN Server, minimizing VPN configuration requirements at the remote location. This cost-effective solution is ideal for remote offices with little IT support or for large customer premises equipment (CPE) deployments where it is impractical to individually configure multiple remote devices.
When a client connects to a server, the negotiation to secure the VPN occurs:
1. The VPN client initiates the IKE Phase 1 process. If a pre-shared key is used for authentication, the VPN Client initiates aggressive mode. If digital certificates are used for authentication, the VPN Client initiates main mode.
2. The VPN client establishes an ISAKMP SA. To reduce the amount of manual configuration on the VPN Client, Easy VPN ISAKMP proposals include every combination of encryption and hash algorithms, authentication methods, and DH group sizes.
3. The Easy VPN Server accepts the SA proposal. The ISAKMP policy can consist of several proposals, but the Easy VPN Server uses the first match, so always configure the most secure policies first. Device authentication ends and user authentication begins at this point.
4. The Easy VPN Server initiates a username and password challenge. The information that is entered is checked against authentication entities using authentication, authorization, and accounting (AAA) protocols such as RADIUS and TACACS+. Token cards can also be used via AAA proxy. VPN devices that are configured to handle remote VPN clients should always enforce user authentication.
5. The mode configuration process is initiated. The remaining system parameters (IP address, DNS, split tunnel attributes, and so on) are pushed to the VPN client at this time using mode configuration.
6. The reverse route injection (RRI) process is initiated. RRI ensures that a static route is created on the Cisco Easy VPN Server for the internal IP address of each VPN client.
7. IPsec quick mode completes the connection. The connection is complete after IPsec SAs have been created.
Configuring Cisco Easy VPN Server functionality using SDM consists of two major tasks:
Task 1. Configure prerequisites, such as AAA, privileged users, and the enable secret password, based on the chosen VPN design.
Task 2. Configure the Cisco Easy VPN Server.
From the SDM main page, click the Configure button, then click the VPN Task button and select the Easy VPN Server option. If AAA has not been previously configured, the wizard asks to configure it. If AAA is disabled on the router, configure AAA before Easy VPN Server configuration begins and create at least one administrative user.
After the Easy VPN Server wizard is launched, the Interface and Authentication window displays. Specify the router interface where the VPN connection will terminate (e.g., Unnumbered to Serial 0/0/1) and the authentication method (e.g., pre-shared keys or digital certificates).
Click Next to display the IKE Proposals window. When configuring IKE proposals, use the default policy that is predefined by SDM or add a custom IKE Policy specifying these required parameters:
Cisco SDM provides a default transform set. Use the default or create a new IPsec transform set configuration using these parameters:
The Group Authorization and Group Policy Lookup window appears next. There are three options to choose from for the location where Easy VPN group policies can be stored:
Click Next to configure the Group Authorization parameters. Click the Add button to add a new group policy. The General tab allows configuration of the following parameters:
Other tabs address the following options:
After all the steps are completed, the Easy VPN Server wizard presents a summary of the configured parameters. Click Back to correct any errors in the configuration. Otherwise, click Finish to apply the configuration to the router.
The Easy VPN Server configuration can then be verified. Run a test to confirm the correct tunnel configuration by clicking the Test VPN Server button at the bottom of the Edit Easy VPN Server page. This will present the VPN Troubleshooting window which displays the VPN validation results.
The Cisco VPN Client is simple to deploy and operate. It allows organizations to establish end-to-end, encrypted VPN tunnels for secure connectivity for mobile employees or telecommuters. This thin design IPsec-implementation is compatible with all Cisco VPN products.
When preconfigured for mass deployments, initial logins require little user intervention. Cisco VPN Client supports the innovative Cisco Easy VPN capabilities, delivering a uniquely scalable, cost-effective, and easy-to-manage remote access VPN architecture that eliminates the operational costs associated with maintaining a consistent policy and key management method.
The Cisco Easy VPN feature allows the Cisco VPN Client to receive security policies on a VPN tunnel connection from the central site VPN device (Cisco Easy VPN Server), minimizing configuration requirements at the remote location. This simple and highly scalable solution is ideal for large remote access deployments where it is impractical to configure policies individually for multiple remote PCs.
When the Cisco Easy VPN client is installed, open the Cisco Easy VPN client window to start an IPsec VPN connection on a PC.
The application lists the available preconfigured sites. Double-click a site. In the user authentication dialog box, authenticate to the site. After authentication, the Cisco Easy VPN Client displays a connected status.
Configuring the Easy VPN client is beyond the scope of this course. Check www.cisco.com for more information.