Design And Implementation Of A Virtual Private Network For An Organization 1.1 What is VPN? Virtual Private Network (VPN) is the technology that can use to access the office or home network remotely and securely over the Internet, so that the communication data is protected from hijacking by hackers. When the VPN connection is established between 2 parties (between a VPN client and vpn gateway or between 2 VPN gateways), a secured virtual tunnel will be created with capability to encrypt the data (so no hacker can see the data content), preserve data integrity (no data change during transmission) and ensure the communication only happen between that 2 authenticated parties. [1] Fig 1.1 A diagram for internet VPN 1.2 Benefits VPNs provide four main benefits over setting up a private WAN network, such as those used by Frame Relay, point-to-point circuits, and ATM: ■ Security Security is provided through data encryption to protect confidentiality, data integrity checking to validate packets, and authentication to prevent unauthorized access. ■ Cost Public networks, such as the Internet, can be used instead of building a private WAN infrastructure, greatly reducing a company’s WAN Infrastructure cost. ■ Bandwidth Inexpensive high-bandwidth connections, such as DSL and cable, can be used to interconnect offices to allow for fast and secure access to corporate resources. ■ Scalability Companies can easily add large numbers of users and offices without building a significant WAN infrastructure.
Transcript
Design And Implementation Of A Virtual Private Network For An Organization
1.1 What is VPN?Virtual Private Network (VPN) is the technology that can use to access the office or home network remotely and securely over the Internet, so that the communication data is protected from hijacking by hackers.
When the VPN connection is established between 2 parties (between a VPN client and vpn gateway or between 2 VPN gateways), a secured virtual tunnel will be created with capability to encrypt the data (so no hacker can see the data content), preserve data integrity (no data change during transmission) and ensure the communication only happen between that 2 authenticated parties. [1]
Fig 1.1 A diagram for internet VPN
1.2 Benefits
VPNs provide four main benefits over setting up a private WAN network, such as those used by Frame Relay, point-to-point circuits, and ATM:■ Security Security is provided through data encryption to protect confidentiality, data integrity checking to validate packets, and authentication to prevent unauthorized access.■ Cost Public networks, such as the Internet, can be used instead of building a private WAN infrastructure, greatly reducing a company’s WAN Infrastructure cost.■ Bandwidth Inexpensive high-bandwidth connections, such as DSL and cable, can be used to interconnect offices to allow for fast and secure access to corporate resources.■ Scalability Companies can easily add large numbers of users and offices without building a significant WAN infrastructure.
1.3 VPN TypesVPNs fall under two implementation types:■ Site-to-Site■ Remote AccessThe following sections will expand on these types.
1.3.1 Site to Site:Site-to-Site VPNs, sometimes called LAN-to-LAN or L2L VPNs connect two locations or sites together, extending a classical WAN design. Two intermediate devices, commonly called VPN gateways, protect the traffic between the two LANs. This type of VPN tunnels packets between the locations: the original IP packet from one LAN is encrypted by one gateway, forwarded to the destination gateway, and then decrypted and forwarded to the local LAN at its end to the destination.
From the real source and destination’s perspective, the VPN is virtual—they do not even know their traffic is being protected between the two VPN gateways. The most common
Site-to-site protocol used to protect traffic is IPSec Routers are commonly used as the VPN gateway product, though other products can be used, such as firewalls. Cisco products that support IPSec L2L VPNs include routers, ASA and PIX security appliances, and the VPN 3000 concentrators. Because of scalability features such as dynamic multipoint VPNs (DMVPNs), Cisco routers are the preferred choice for IPSec L2L gateways. L2Ls come in two flavors: intranet and extranet. An intranet L2L basically connects two offices of the same company together, such as a corporate office and a regional or branch office. An extranet is an L2L VPN that connects two different companies together, such as a corporate office and another company that is a business partner. Address translation is commonly required here because the two companies might be using the same private address space. [1]
Fig 1.2 Site to site VPN1.3.2 Remote AccessRemote access VPNs are an extension of the classic circuit-switching networks, such as POTS and ISDN. They securely connect remote users, SOHOs to a corporate, or branch office. With a remote access VPN, the VPN provides a virtualization process, making it appear that the remote access user or office is physically connected to the corporate office network. Common protocols used for remote access VPNs include IPsec, SSL, PPTP, and L2TP. Cisco supports all four of these protocols; however, most of the Cisco’s development effort is based on IPSec and SSL. Provide remote access to an enterprise customer’s intranet or extranet over a shared infrastructure. Access VPNs use analog, dial, ISDN, DSL, mobile IP, and cable technologies to securely connect mobile users, telecommuters, and branch offices. Still, using VPN is not the same as being in the office. Most office networks are fast. Most Internet connections are not. Even the fastest DSL and cable connections are around one-tenth the speed of your average office LAN. This means that accessing resources on the LAN will be much slower over VPN. It would also depend on the "upstream" or upload speed of your office's network connection
Fig 1.3 Remote Access VPN
1.4 Objectives of VPNThe main objective is to prevent outsiders from interfering with messages sent among hosts in the interior network There is also a need to protect the privacy and integrity of messages going through untrusted networks. Privacy will ensure that messages intercepted within the untrusted network remain undisclosed. Integrity assures that the message received did indeed originate from the specified sender and that the message has not been modified in any way since transmission. VPNs must also be capable of handling the whole range of Internet protocols currently in use. New security measures must not require extensive software replacement.One important objective pursued by VPN is the issue of cost. With a high bandwidth, dedicated Internet connection is often available for a lower cost than a point-to-point leased line.
1.5 Outline of the projectChapter 2 discussed about IPSec VPN, Objectives of IPsec and how IPsec work? IPsec component, VPN architecture, VPN authentication, Key management, VPN protocol, Application of VPN, Advantage and disadvantage of VPN etc.
Chapter 3 discussed about Design overview of VPN, Design component, IPsec Direct Encapsulation deployment, Tunnel initiation etc.
Chapter 4 discussed about how to configure and implement of site-to-site VPN in CLI mode.
Chapter 5 discussed about the performance of a site-to-site VPN design and implementation.
Chapter 6 discussed about the conclusion and future work of site-to-site VPN.2.1 What is IPSec VPN?Internet Protocol Security (IPSec) VPN technology is predicated on the existence of a trusted relationship between networks or between users. It accomplishes these goals through tunneling, encryption and authentication, but allows enterprises to select the specific security policy appropriate for their business. This suite of protocols provides security for IP traffic at the network layer. IPSec VPN technology was originally developed to protect data communication between private, trusted networks over the Internet. IPSec solutions were later extended to protect data communication between mobile workers gaining remote access to an enterprise’s internal network in a more efficient manner than legacy dial-in methods. With an IPSec VPN, an IT department installs and maintains individual VPN clients on each PC from which a user needs access. An IPSec VPN may also require changes to the desktop. These factors result in higher management and support cost.
IPSec-based VPNs can be created over any type of IP network, including the Internet, Frame Relay, ATM, and MPLS, but only the Internet is ubiquitous and inexpensive. VPNs are traditionally used for:• Access VPNs—Provide remote access to an enterprise customer’s intranet or extranet over a shared infrastructure. Access VPNs use analog, dial, ISDN, DSL, mobile IP, and cable technologies to securely connect mobile users, telecommuters, and branch offices.• Intranet VPNs—Link enterprise customer headquarters, remote offices, and branch offices to an internal network over a shared infrastructure using dedicated connections. Intranet VPNs differ from extranet VPNs in that they only allow access to the enterprise customer’s employees.• Extranet VPNs—Link outside customers, suppliers, partners, or communities of interest to an enterprise customer’s network over a shared infrastructure using dedicated connections. Extranet VPNs differ from intranet VPNS in that they allow access to users outside the enterprise.
2.1.1 Objectives of IPSecIt must be able to protect traffic between trusted hosts from forgery or eavesdropping.Another important goal is to achieve application transparency. By this, we mean that implementation of IPSec should not affect all existing network applications using TCP/IP. [1]
2.1.2 How Does IPSec Work? IPSec is an Internet Engineering Task Force (IETF) standard suite of protocols that provides data authentication, integrity, and confidentiality as data is transferred between communication points across IP networks. IPSec provides data security at the IP packet level. A packet is a data bundle that is organized for transmission across a network, and it includes a header and payload (the data in the packet). IPSec emerged as a viable network security standard because enterprises wanted to ensure that data could be securely transmitted over the Internet. IPSec protects against possible security exposures by protecting data while in transit. [1]
2.1.3 IPSec Security FeaturesIPSec is the most secure method commercially available for connecting network sites. IPSec was designed to provide the following security features when transferring packets across networks: • Authentication: Verifies that the packet received is actually from the claimed sender • Integrity: Ensures that the contents of the packet did not change in transit.• Confidentiality: Conceals the message content through encryption.• Access control: limiting unauthorized users from accessing the network.
2.1.4 IPSec Components IPSec contains the following elements: ISAKMP (IKE): Internet Security Association and Key Management Protocol (ISAKMP) provides a means for authenticating the peers in a secure communication.
It typically uses Internet Key Exchange (IKE), but other technologies can also be used. Public keys or a pre-shared key are used to authenticate the parties to the communication.
MD5: Message-Digest algorithm 5 (MD5) is an often used, but partially insecure cryptographic hash function with a 128-bit hash value. A cryptographic hash function is a way of taking an arbitrary block of data and returning a fixed-size bit string, the hash value based on the original block of data. The hashing process is designed so that a change to the data will also change the hash value. The hash value is also called the message digest.
SHA: Secure Hash Algorithm (SHA) is a set of cryptographic hash functions designed by the National Security Agency (NSA). The three SHA algorithms are structured differently and are distinguished as SHA-0, SHA-1, and SHA-2. SHA-1 is a commonly used hashing algorithm with a standard key length of 160 bits.
ESP: Encapsulating Security Payload (ESP) is a member of the IPSec protocol suite that provides origin authenticity, integrity, and confidentiality protection of packets. ESP also supports encryption-only and authentication-only configurations, but using encryption without authentication is strongly discouraged because it is insecure. Unlike the other IPSec protocol, Authentication Header (AH), ESP does not protect the IP packet header. This difference makes ESP preferred for use in a Network Address Translation configuration. ESP operates directly on top of IP, using IP protocol number 50.
DES: The Data Encryption Standard (DES) provides 56-bit encryption. It is no longer considered a secure protocol because its short key-length makes it vulnerable to brute-force attacks.
3DES: Three DES was designed to overcome the limitations and weaknesses of DES by using three different 56-bit keys in an encrypting, decrypting, and re-encrypting operation. 3DES keys are 168 bits in length. When using 3DES, the data is first encrypted with one 56-bit key, and then decrypted with a different 56-bit key, the output of which is then re-encrypted with a third 56-bit key.
AES: The Advanced Encryption Standard (AES) was designed as a replacement for DES and 3DES. It is available in varying key lengths and is generally considered about six times faster than 3DES.
HMAC: The Hashing Message Authentication Code (HMAC) is a type of message authentication code (MAC). HMAC is calculated using a specific algorithm involving a cryptographic hash function in combination with a secret key. [2]
2.2 VPN Architecture
VPN implementations actually tend to decrease availability somewhat because they add more components and services to the existing network infrastructure. This is highly dependent upon the chosen VPN architecture model and the details of the implementation. The following sections describe each of the three primary VPN architectures: host-to-host, host-to-gateway, and gateway-to-gateway.
2.2.1 Gateway-to-Gateway Architecture
IPSec-based VPNs are often used to provide secure network communications between two networks. This is typically done by deploying a VPN gateway onto each network and establishing a VPN connection between the two gateways. Traffic between the two networks that needs to be secured passes within the established VPN connection between the two VPN gateways. The VPN gateway may be a dedicated device that only performs VPN functions, or it may be part of another network device. Fig 2.1 shows an example of an IPSec network architecture that uses the gateway-to-gateway model to provide a protected connection between the two networks.
Fig 2.1 Gateway-to-Gateway Architecture Example [2]
This model is relatively simple to understand. To facilitate VPN connections, one of the VPN gateways issues a request to the other to establish an IPSec connection. The two VPN gateways
exchange information with each other and create an IPSec connection. Routing on each network is configured so that as hosts on one network need to communicate with hosts on the other network, their network traffic is automatically routed through the IPSec connection, protecting it appropriately. A single IPSec connection establishing a tunnel between the gateways can support all communications between the two networks, or multiple IPSec connections can each protect different types or classes of traffic. [2]
Fig 2.1 illustrates that a gateway-to-gateway VPN does not provide full protection for data throughout its transit. In fact, the gateway-to-gateway model only protects data between the two gateways, as denoted by the solid line. The dashed lines indicate that communications between VPN clients and their local gateway, and between the remote gateway and destination hosts (e.g., servers) are not protected
The other VPN models provide protection for more of the transit path. The gateway-to-gateway model is most often used when connecting two secured networks, such as linking a branch office to headquarters over the Internet. Gateway-to-gateway VPNs often replace more costly private wide area network (WAN) circuits.
The gateway-to-gateway model is the easiest to implement, in terms of user and host management. Gateway-to-gateway VPNs are typically transparent to users, who do not need to perform separate authentication just to use the VPN. In addition, the users systems and the target hosts (e.g., servers) should not need to have any VPN client software installed, nor should they require any reconfiguration, to be able to use the VPN.
2.2.2 Host-to-Gateway Architecture
An increasingly common VPN model is the host-to-gateway model, which is most often used to provide secure remote access. The organization deploys a VPN gateway onto their network; each remote access user then establishes a VPN connection
Between the local computer (host) and the VPN gateway. As with the gateway-to-gateway model, the VPN gateway may be a dedicated device or part of another network device. Figure 2-3 shows an example of an IPSec host-to-gateway architecture that provides a protected connection for the remote user.
Fig 2.2 Host-to-Gateway Architecture Example [2]
In this model, IPSec connections are created as needed for each individual VPN user. Remote user’s hosts have been configured to act as IPSec clients with the organization’s IPSec gateway. When a remote user wishes to use computing resources through the VPN, the host initiates communications with the VPN gateway. The user is typically asked by the VPN gateway to authenticate before the connection can be established. The VPN gateway can perform the authentication itself or consult a dedicated authentication server. The client and gateway exchange information, and the IPSec connection are established and the VPN gateway will be protected by the IPSec connection.
Traffic between the user and systems not controlled by the organization can also be routed through the VPN gateway; this allows IPSec protection to be applied to this traffic as well if desired.
As shown in Fig 2.2 the host-to-gateway VPN does not provide full protection for data throughout its transit. The dashed lines indicate that communications between the gateway and the destination hosts (e.g., servers) are not protected. The host-to- gateway model is most often used when connecting hosts on unsecured networks to resources on secured networks, such as linking traveling employees around the world to headquarters over the Internet. Host-to-gateway VPNs often replace dial-up modem pools. The host-to-gateway model is somewhat complex to implement and maintain in terms of user and host.
2.2.3 Host-to-Host Architecture
The least commonly used VPN architecture is the host-to-host model, which is typically used for special purpose needs, such as system administrators performing remote management of a single server. In this case, the organization configures the server to provide VPN services and the system administrators. Hosts to act as VPN clients. The system administrators use the VPN client when needed to establish encrypted connections to the remote server. Figure 2-4 shows an example of an IPsec network architecture that uses the host-to-host model to provide a protected connection to a server for a user.
Fig 2.3 Host-to-Host Architecture Example [2]
In this model, IPSec connections are created as needed for each individual VPN user. User hosts have been configured to act as IPSec clients with the IPSec server. When a user wishes to use resources on the IPSec server, the users host initiates communications with the IPSec server. The user is asked by the IPSec server to authenticate before the connection can be established. The client and server exchange
Information, and if the authentication is successful, the IPSec connection is established. The user can now use the server, and the network traffic between the users host and the server will be protected by the IPSec connection.
As shown in Fig 2.3 the host-to-host VPN is the only model that provides protection for data throughout its transit. 2.2.4 Model Comparison
Table 2-1 provides a brief comparison of the three VPN architecture models.
Table 2.1 Comparison of VPN Architecture Models
Feature Gateway-to-gateway Host-to-gateway Host-to-host Provides protection between client and local
No N/A (client is VPN endpoint)
N/A (client is VPN endpoint)
gateway Provides protection between VPN endpoints
Yes Yes Yes
Provides protection between remote gateway and remote server (behind gateway)
No No N/A (server is VPN endpoint)
Transparent to users
Yes No No
Transparent to users. systems
Yes No No
Transparent to servers
Yes Yes No
2.3 VPN authenticationAs an alternative, so-called digital certificates can be used for VPN authentication. A digital certificate can be thought of as a digital passport that can be issued to a network device or a person. In the case of a VPN, device certificates are necessary (issued to VPN gateways). A device certificate is not stored on a smart card, but in the internal memory of the device. Digital certificates are a lot easier to administer than secret keys, as they contain no secret information and can therefore be distributed over the network. For this reason, digital-certificate-based authentication easily scales to larger environments. In addition, digital certificates are considerably more secure. As all common VPN solutions on the market natively support digital certificates, it is usually easy to migrate from secret keys to digital certificates. In order to manage digital certificates, a special component (certification authority) is necessary. A certification authority (CA) is responsible for issuing digital certificates and for an appropriate certificate management. The entirety of components (especially the CA) and processes used for working with digital certificates is usually called PKI (Public Key Infrastructure
2.4 Crypto vision’s solutionCrypto vision provides the CA solution CV act PKI Integrated with highly sophisticated certificate management abilities, which covers the whole lifecycle of a digital certificate (certificate lifecycle management). CV act PKIntegrated supports an extensible variety of certificate formats, smart cards, certificate revocation lists, online certificate validation via OSCP, certificate registration via SCEP and a range of cryptographic methods and key lengths. In contrast to almost any other CA solution, CV act PKI Integrated was from the beginning not designed as stand-alone component, but as an add-on to user and device management systems. When it comes to VPN protection, this is a considerable benefit, because virtually every large enterprise manages their VPN gateways with a device management tool. [3]
IPsec is a general-purpose security technology that can be used to help secure network traffic in many scenarios. However, you must balance the need for security with the complexity of configuring IPsec policies. Additionally, due to a lack of suitable standards, IPsec is not appropriate for some types of connectivity. This section describes IPsec scenarios that are recommended, IPsec scenarios that are not recommended, and IPsec scenarios that require special consideration.
Recommended Scenarios for IPsec :IPsec is recommended for the following scenarios:
Packet filtering
End-to-end security between specific hosts End-to-end traffic through a Microsoft Internet Security and Acceleration (ISA) Server-
secured network address translator Secure server Layer Two Tunneling Protocol (L2TP) over IPsec (L2TP/IPSec) for remote access and site-
2.5 Packet FilterThe purpose of the packet filter is to specify how each type of incoming and outgoing traffic should be handled whether the traffic should be permitted or denied (usually based on IP addresses, protocols, and ports), and how permitted traffic should be protected (if at all). By default, IPsec implementations typically provide protection for all traffic. In some cases, this may not be advisable because of performance reasons. Encrypting traffic that does not need protection or is already protected (e.g., encrypted by another application) can be a significant waste of resources. For such traffic, the packet filter could specify the use of the null encryption algorithm for ESP, which would provide integrity checks and anti-replay protection, or the packet filter could simply pass along the traffic without any additional protection. One caveat is that the more complex the packet filter becomes, the more likely it is that a configuration error may occur, which could permit traffic to traverse networks without sufficient
2.6 How do the Two VPNs Compare Regarding Security?IPSec and SSL VPNs both provide flexibility in allowing enterprises to define the level of security that best meets their needs. However, based on its architecture, the SSL protocol is best suited for securing application based remote access. Sonic WALL Aventail E-Class SSL VPN technology provides employees, business partners and customers with secure everywhere access—including clientless access to Web applications, client/server applications and file shares, as well as back-connect applications such as those using Voice over Internet Protocol (VoIP). IPSec VPNs use tunneling and encryption to secure the data transfer over the Internet between a private network and a trusted computer. Therefore, IPSec assumes that the end is secure and authorizes users unless otherwise restricted. However, IPSec alone might not prevent a user from entering with a virus or keystroke logger. To help overcome the security limitations of IPSec, the recommended approach is to ensure the communication is secured by a network securityIPSec VPN is ideal for site-to-site connectivity such as between a corporate headquarters and a branch office. IPSec can be more complex when used to connect home networks, consultants or business partners, since the different networks demand changes in configuration each time they are accessed. Furthermore, IPSec’s network-based connection model does not apply to determining application-layer access. IPSec solutions are not designed to provide granular access control due to their lack of application layer support.IPSec configuration choices include:
Tunneling—Authentication Header (AH) or Encapsulating Security Payload (ESP)
Encryption—56-bit DES; 112- or 168-bit 3DES; 128-, 192- or 256-bit AES; or none Authentication—username/password (such as Active Directory or RADIUS); user name and token pin (such as RSA SecurID); Internet key exchange (IKE); or X.509 digital certificates (such as Entrust and VeriSign) and IAM (such as eTrust Site Minder and Clear Trust). SSL VPNs use proxies, tunneling and encryption combined with access control to secure communications between users, the devices they use and the resources they access. With SSL VPNs, end-user access to any given resource is restricted unless authorized, a vastly different approach from that of IPSec VPNs. As a result, SSL VPN technology provides the granular access control that requires all users, regardless of location, to be granted explicit permission to access specific network resources. With SSL VPN technology, access control to applications and networks can be as general
or specific as required. Some SSL VPN soffer name-based policy management, which enables administrators to set-up access policies based on the names of domains or resources. As long as resources stay within the same domain, no additional administration is required as resources are added, moved or changed. SSL VPN configuration choices include:
Encryption—40- or 128-bit RC4; 56-bit DES; 112- or 168-bit 3DES encryption; 128 or 256 AES encryptionAuthentication username/password (such as Active Directory or RADIUS); user name and token pin. [2]
2.7 Which of the two VPNs provide a greaterreturn on investment? The initial purchase price of an IPSec VPN is a little less than that of an SSL VPN. However, when organizations tally total cost of ownership (TCO), the return on investment (ROI) for an SSL VPN is much stronger for remote access. Because SSL VPNs have no client to deploy and manage and are much easier to use, the ongoing costs to IT for administration and support are significantly lower. In addition, since users have anywhere access, overall productivity increases. By using SSL VPN for remote access, you increase productivity by allowing users easier access to more corporate resources from more locations and devices, without interaction with IT. These users could be comprised of executive, sales, technical, consulting and healthcare professional staff, where even incremental increases in productivity will result in significant benefits. Other ancillary benefits may include faster time-to market, increased responsiveness to customers, enhanced reputation and reduced attrition of internal staff.Because SSL VPNs are clientless and rules-based—meaning you get highly granular access control—you can create a portal for your business partners so that they can access only the applications and resources they need. This scenario considers the potential cost savings and revenue enhancement from having a business partner extranet, resulting in lower costs and improved productivity, based upon fewer missed business opportunities, greater speed to market and eliminated overhead from paper-based transactions.
2.8 Encapsulating Security Payload (ESP)ESP provides authentication, integrity, and confidentiality, which protect against data tampering and, most importantly, provide message content protection. IPSec provides an open framework for implementing industry standard algorithms, such as SHA and MD5. The algorithms IPSec uses produce a unique and unforgeable identifier for each packet. Packets that are not authenticated are discarded and not delivered to the intended receiver. ESP also provides all encryption services in IPSec. Encryption translates a readable message into an unreadable format to hide the message content. The opposite process, called decryption, translates the message content from an unreadable format to a readable message. Encryption/ decryption allows only the sender and the authorized receive.
Fig 2.4 Encapsulation of packet [2]
The ESP header is inserted into the packet between the IP header and any subsequent packet contents. However, because ESP encrypts the data, the payload is changed. ESP does not encrypt the ESP header, nor does it encrypt the ESP authentication.
2.9 Authentication Header (AH)AH provides authentication and integrity, which protect against data tampering, using the same algorithms as ESP. AH also provides optional anti-replay protection, which protects against unauthorized retransmission of packets. The authentication header is inserted into the packet between the IP header and any subsequent packet contents. The payload is not touched. Although AH protects the packet’s origin, destination, and contents from being tampered with, the identity of the sender and receiver is known. In addition, AH does not protect the data’s confidentiality. If data is intercepted and only AH is used, the message contents can be read. ESP protects data confidentiality. For added protection in certain cases, AH and ESP can be used together. In the following table, IP HDR represents the IP header and includes both source and destination IP addresses. [2]
Fig 2.5 Authentication of packet [2]
2.10 Security Association IPSec introduces the concept of the Security Association (SA). An SA is a logical connection between two devices transferring data. An SA provides data protection for unidirectional traffic by using the defined IPSec protocols. An IPSec tunnel typically consists of two unidirectional SAs, which together provide a protected, full-duplex data channel. The SAs allow an enterprise to control exactly what resources may communicate securely, according to security policy. To do this an enterprise can set up multiple SAs to enable multiple secure VPNs, as well as define SAs within the VPN to support different departments and business partners. [3]
2.10.1 Mode SAs operate using modes. A mode is the method in which the IPSec protocol is applied to the packet. IPSec can be used in tunnel mode or transport mode. Typically, the tunnel mode is used for gateway-to-gateway IPSec tunnel protection, but transport mode is used for host-to-host IPSec tunnel protection. A gateway is a device that monitors and manages incoming and outgoing network traffic and routes the traffic accordingly. A host is a device that sends and receives network traffic. • Transport Mode: The transport mode IPSec implementation encapsulates only the packet’s payload. The IP header is not changed. After the packet is processed with IPSec, the new IP packet contains the old IP header (with the source and destination IP addresses unchanged) and the processed packet payload. Transport mode does not shield the information in the IP header; therefore, an attacker can learn where the packet is coming from and where it is going. Fig 2.4 and Fig 2.5 above show a packet in transport mode. • Tunnel Mode: The tunnel mode IPSec implementation encapsulates the entire IP packet. The entire packet becomes the payload of the packet that is processed with IPSec. A new IP header is created that contains the two IPSec gateway addresses. The gateways perform the encapsulation/decapsulation on behalf of the hosts. Tunnel mode ESP prevents an attacker from analyzing the data and deciphering it, as well as knowing whom the packet is from and where it is going.
Note: .AH and ESP can be used in both transport mode and tunnel mode.
Fig 2.6 Tunnel mode IPSec operation [2]
2.11 Key ManagementIPSec uses the Internet Key Exchange (IKE) protocol to facilitate and automate the SA setup and the exchange of keys between parties transferring data. Using keys ensures that only the sender and receiver of a message can access it. IPSec requires that keys be re-created, or refreshed, frequently so that the parties can communicate securely with each other. IKE manages the process of refreshing keys; however, a user can control the key strength and the refresh frequency. Refreshing keys on a regular basis ensures data confidentiality between sender and receiver. [3]
2.11.1 What are Keys?An Encryption Key is a series of numbers and letter used in conjunction with an encryption algorithm to turn plain text into encrypted text and back into plain text The longer the key, the stronger the encryption
Internet Key Exchange (IKE) IKE provides:
Automation and scalability
Improved security Encryption keys be changed frequently
Hybrid IKE Proposed standard designed by Check Point Allows use of existing authentication methods
2.12 VPN ProtocolsThe term "VPN" has taken on many different meanings in recent years. VPNC has a white paper about the VPN technology that describes many of the terms used in the VPN market today. In specific, it differentiates between secure VPNs and trusted VPNs, which are two very different technologies
For secure VPNs, the technologies that VPNC supports are
IPsec with encryption L2TP inside of IPsec SSL with encryption
For trusted VPNs, the technologies that VPNC supports are: MPLS with constrained distribution of routing information through BGP (layer 3 VPNs) Transport of layer 2 frames over MPLS (layer 2 VPNs)
IPsec is the most dominant protocol for secure VPNs. SSL gateways for remote-access users are also popular for secure VPNs. L2TP running under IPsec has a much smaller but significant deployment. For trusted VPNs, the market is split on the two
MPLS-based protocols. Companies want to do their own routing then to use layer 2 VPNs; companies that want to outsource their routing tend to use layer 3 VPNs. [2]
The various VPN protocols are defined by a large number of standards and recommendations that are codified by the Internet Engineering Task Force. There are many flavors of IETF standards, recommendations, statements of common practice, and so on. Some of the protocols used in IPsec are full IETF standards; however, the others are often useful and stable enough to be treated as standard by people writing IPsec software. Neither of the trusted VPN technologies are IETF standards yet, although there is a great deal of work being done on them to get them to become standards.
2.13 Applications of VPNApplications: Site-to-Site VPNs
Large-scale encryption between multiple fixed sites such as remote offices and central offices Network traffic is sent over the branch office Internet connection This saves the company hardware and management expenses
Applications: Remote Access Encrypted connections between mobile or remote users and their corporate networks. Remote user can make a local call to an ISP, as opposed to a long distance call to the
corporate remote access server. Ideal for a telecommuter or mobile sales people. VPN allows mobile workers & telecommuters to take advantage of broadband connectivity.
i.e. DSL, Cable
2.14 Advantages of VPN Eliminating the need for expensive long-distance leased lines. Reducing the long-distance telephone charges for remote access. Transferring the support burden to the service providers. Operational costs. Flexibility of growth. Efficiency with broadband technology.
2.15 Disadvantages of VPN VPNs require an in-depth understanding of public network security issues and proper deployment
of precautions Availability and performance depends on factors largely outside of their control Immature standards VPNs need to accommodate protocols other than IP and existing internal network technology
2.16 Industries That May Use a VPN Healthcare: enables the transferring of confidential patient information within the medical
facilities & health care provider Manufacturing: allow suppliers to view inventory & allow clients to purchase online safely Retail: able to securely transfer sales data or customer info between stores & the
headquarters. Banking/Financial: enables account information to be transferred safely within departments
& branches General Business: communication between remote employees can be securely exchanged
3.1 VPN Process OverviewEven though IPSec is standards-based, each vendor has its own set of terms and procedures for implementing the standard. Because of these differences, it may be a good idea to review some of the terms and the generic processes for connecting two gateways before diving into to the specifics.
3.2 Network Interfaces and AddressesThe VPN gateway is aptly named because it functions as a “gatekeeper” for each of the computers connected on the Local Area Network behind it.In most cases, each gateway will have a “public” facing address (WAN side) and a “private” facing address (LAN side). These addresses are referred to as the “network interface” in documentation regarding the construction of VPN communication. Please note that the addresses used in the example. [4]
3.2.1 Interface AddressingThis document uses example addresses provided the VPN Consortium. It is important to understand that you will be using addresses specific to the devices that you are attempting to connect via IPsec VPN. It is also important to make sure the addresses do not overlap or conflict. That is, each set of addresses should be separate and distinct.
Table 3.1 WAN (Internet/ public) and LAN (Internal/private) Addressing
It will also be important to know the subnet mask of both gateway LAN Connections. Use the worksheet in Appendix A to gather the necessary address and subnet mask information to aid in the configuration and troubleshooting process.3.3 FirewallsIt is important to understand that many gateways are also firewalls. VPN tunnels cannot function properly if firewall settings disallow all incoming traffic. Please refer to the firewall instructions for both gateways to understand how to open specific protocols, ports, and addresses that you intend to allow.3.4 Design OverviewThis design guide begins with an overview, followed by design recommendations and product selection and performance information. Finally, partial configuration examples are presented. The chart in Figure 3.1shows the IPsec VPN WAN architecture documentation, which is divided into multiple design guides based on the technologies used. Each technology uses IPsec as the underlying transport mechanism for the VPNs.
Fig 3.1 IPsec VPNdesign overview [4]
This document addresses the following applications and implementations of IPsec direct encapsulation VPNs:
•Dead Peer Detection (DPD) •Reverse Route Injection (RRI) •VPN high availability using Hot Standby Router Protocol (HSRP) with stateless and stateful failover •Data and VoIP converged traffic requirements •Quality of service (QoS) features
The primary topology discussed in this document is a hub-and-spoke model. In this deployment, primary enterprise resources are located in a large central site, with a number of smaller sites or branch offices connected directly to the central site over a VPN. A high-level diagram of this topology is shown in, [4]
Fig 3.2 Hub and Spoke VPN [4]
This guide makes the following design assumptions and recommendations: •The design supports a typical converged traffic profile for customers. See the Scalability Considerations used during scalability testing.•Built-in redundancy and failover with fast convergence are essential to help ensure high availability and resiliency.
•This design uses IPsec alone as the tunneling method, which is appropriate for enterprises that do not require an IGP routing protocol passing through the tunnel, IP multicast (IPmc) traffic, or multiprotocol traffic.•The design recommendations assume that the customer deploys current VPN technologies, including hardware-accelerated encryption. Cost considerations have been taken into account in the proposed design, but not at the expense of necessary performance. •Support for voice over IP (VoIP) and video are assumed requirements in the network design. Detailed design considerations for handling VoIP and other latency-sensitive traffic is not explicitly addressed in this design guide, but may be found in the Voice and Video Enabled IPsec VPN (V3PN) Design Guide, •Recommendations are for enterprise-owned VPNs. However, the concepts and conclusions are valid regardless of the ownership of the edge tunneling equipment, so the recommendations are also useful for VPNs managed by service providers.
3.5 Design ComponentsVPNs have the same requirements as traditional private WAN services, including multiprotocol support, high availability, scalability, and security. VPNs can often meet these requirements more cost-effectively and with greater flexibility than private WAN services.VPNs have many applications, including extending reach ability of an enterprise WAN, or replacing classic WAN technologies such as leased lines, Frame Relay, and ATM. Site-to-site VPNs are primarily deployed to connect branch office locations to the central site (or sites) of an enterprise. The key components of the recommended site-to-site VPN design are the following:
• High-end VPN routers serve as VPN headed termination devices at a central campus site. • VPN access routers serve as VPN branch termination devices at branch office locations. •IPsec direct encapsulation (with DPD, RRI, and HSRP) provides headed-to-branch interconnections. •Internet services from a third party ISP (or ISPs) provide the WAN interconnection medium.
Cisco VPN routers are a good choice for site-to-site VPN deployments because they can accommodate any network requirement inherited from a Frame Relay or private line network, such as support for latency-sensitive traffic and resiliency. Design and Implementation, page 8 describes how to select headend and branch devices.The network topology of the hub-and-spoke design is shown in Figure 3. The solution is a hub-and-spoke network with multiple headend devices for redundancy. Headends are high-end tunnel aggregation routers that service multiple IPsec tunnels for a prescribed number of branch office locations. In addition to terminating the VPN tunnels at the central site, headends can advertise routes to branch devices using RRI. To ensure authentication and encryption, IPsec tunnels are provisioned to interconnect branch offices to the central site. The way that network resiliency is provided depends on the initial network requirements. [4]
Fig 3.3 Hub and Spoke VPN Network Topology [4]
3.6 IPsec Direct Encapsulation DeploymentHead end sites are typically connected with DS3, OC3, or even OC12 bandwidth. Branch offices are typically connected by fractional T1, T1, T3, or fractional T3, and increasingly by broadband DSL or cable. Two possibilities are available for providing redundancy.
Figure 3.4 shows a typical IPsec direct encapsulation
Fig 3.4 IPsec Direct Encapsulation Deployment deployment [4]
•Box-to-box redundancy with HSRP and Stateful Failover (VPN High Availability) •Site-to-site stateless redundancy with geographically separated headend sites.
Typically, branch routers are configured with a list of possible headend crypto peers that are tried in succession until a tunnel is successfully established.
The IPsec control plane normally uses dynamic crypto maps at the headend to minimize configuration changes when new branches are added. Dynamic crypto maps are also used to support branches with a dynamic Internet addresses as their crypto peer. DPD automatically detects ISAKMP peer loss and tears down the IPsec SA (data tunnel) if the connection is lost completely.The routing control plane generally uses static routes at the branch locations, with RRI at the headends to inject routes into the routing table for advertisement. IGP dynamic routing protocols are
not exchanged over the VPN tunnel between headend and remote sites. [4] A routing protocol provides several vital features when deployed over a network. These include peer state detection, optimal routing, and the ability to facilitate alternate routes in the event of a link failure. IPsec VPNs implement this functionality without a routing protocol using DPD and RRI. The combined use of DPD and RRI is less network intensive than an actual routing protocol running over the VPN, but achieves a similar effect.
3.7 Dead Peer Detection
new Cisco IOS software feature that is an enhancement to the ISAKMP keep lives feature. DPD sends a hello message to a crypto peer from which it has not received traffic during a configurable period. If normal IPsec traffic is received from a crypto peer and decrypted correctly, the crypto peer is assumed alive, no hello message is sent, and the DPD counter for that crypto peer is reset. This produces lower CPU utilization than using ISAKMP keep lives. If no traffic is received during the specified period, an ISAKMP R_U_THERE message is sent to the other crypto peer. If no response is received after the specified number of tries, the connection is assumed dead, and the IPsec tunnel is disconnected. This feature is vital to prevent black holing traffic, in case the SA database on one peer is cleared manually or by rebooting the device. DPD is both a headend and branch technology and should be configured on both sides of each VPN tunnel. [5]
3.8 Reverse Route Injection
Another IPsec feature that has been added recently to Cisco IOS Software is Reverse Route Injection (RRI). RRI takes the information derived from the negotiated IPsec SAs and creates a static route to the networks identified in those SAs. Route redistribution then occurs between these static routes and whatever routing protocol is configured on the headend router. This makes the routes to the branch office networks available to networks behind the headend aggregation routers. RRI is a headend technology that allows static routes to be automatically generated in the headend router IP routing table. These static routes are then redistributed using a routing protocol into the enterprise network. DPD works in conjunction with RRI. In the event that DPD detects the loss of a crypto peer connection (after the specified ISAKMP R_U_THERE retries have expired), DPD triggers the IPsec tunnel to be torn down. This causes RRI to remove the associated static route from the route table. [6]
3.9 Dynamic Crypto MapsDynamic crypto maps eliminate the need to statically predefine every crypto peer. Dynamic crypto maps allow an IPsec connection between two crypto peers when one of the crypto peers (usually the central site crypto peer) does not have the complete configuration necessary to complete the IPsec negotiation. Dynamic crypto maps are required when the remote crypto peer has a dynamically assigned IP address, such as over a cable or ADSL connection. In this case, the remote peer cannot be preconfigured into the central site device because its IP address is unknown. The IKE authentication completes based on verification of identity through a pre-shared secret key or digital certificate. Information from the IPsec session is used to complete the current IP address of the remote branch router in the dynamic crypto map configuration on the headend. [7]
3.10 Tunnel InitiationWhen dynamic crypto maps are used on the headend, the IPsec connection can be initiated only by the branch router. However, because the headend device uses dynamic crypto maps, it does not have all the information necessary to create an IPsec SA by itself. This is of concern when traffic forwarding is required from a central site to a remote site without the remote site initiating the connection.Because an IPsec tunnel exists only when interesting traffic is transmitted, the tunnel may not be up when traffic arrives on the headend destined for the branch router. One way to work around this issue is to create a periodic traffic source that always keeps the tunnel active. Examples of this type of periodic traffic source include the following:
•Cisco IP SLA, formerly known as Service Assurance Agent (SAA)—This can be configured to send periodic probes •Network Time Protocol (NTP)—Periodically polls the configured NTP servers •Cisco Call Manager—IP phones behind the branch router send periodic keep alive packets to a central primary and secondary Cisco Call Manager
Of these options, the Cisco IP SLA feature offers the most robust capabilities.When the headend must initiate the IPsec tunnel, static crypto maps must be used. After the IPsec SA is established, data traffic can flow in either direction, regardless of which side initiated the tunnel. [8]
3.11 Setting up a VPN Tunnel between GatewaysAn SA, frequently called a tunnel, is the set of information that allows two entities (networks, PCs, routers, firewalls, gateways) to “trust each other” and communicate securely as they pass information over the Internet.
Fig 3.5 VPN Tunnel between Gateways
The SA contains all the information necessary for Gateway A to negotiate a secure and encrypted communication stream with Gateway B. This communication is often referred to as a “tunnel.” The gateways contain this information so that it does not have to be loaded onto every computer connected to the gateways.
Each gateway must negotiate its Security Association with another gateway using the parameters and processes established by IPSec. As illustrated below, the most common method of accomplishing this process is via the Internet Key Exchange (IKE) protocol, which automates some of the negotiation procedures. Alternatively, you can configure your gateways using manual key exchange, which involves manually configuring each parameter on both gateways. [9]
Fig 3.6 Gateways Tunnel
The IPSec software on Host A initiates the IPSec process in an attempt to communicate with Host B. The two computers then begin the Internet Key Exchange (IKE) process.IKE Phase I.a. The two parties negotiate the encryption and authentication algorithms to use in the IKE SAs.b. The two parties authenticate each other using a predetermined mechanism, such as preshared keys or digital certificates.c. A shared master key is generated by the Diffie-Hellman Public key algorithm within the IKE framework for the two parties. The master key is also used in the second phase toderive IPSec keys for the SAs.
IKE Phase II.a. The two parties negotiate the encryption and authentication algorithms to use in the IPSec SAs.b. The master key is used to derive the IPSec keys for the SAs. Once the SA keys are created and exchanged, the IPSec SAs are ready to protect user data between the two VPN gateways. Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database. IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out.
3.12 VPNC IKE Security ParametersIt is important to remember that both gateways must have the identical parameters set for the process to work correctly. The settings in these examples follow the examples given for Scenario 1 of the VPN Consortium.
VPNC IKE Phase I ParametersThe IKE Phase 1 parameters used:• Main mode• TripleDES• SHA-1• MODP group 1• Pre-shared secret of "hr5xb84l6aa9r6"• SA lifetime of 28800 seconds (eight hours)
VPNC IKE Phase II ParametersThe IKE Phase 2 parameters used in Scenario 1 are:• TripleDES• SHA-1• ESP4.1 Configuration overviewSome initial preparation should occur before we actually configure our IPSec session. The goal of this preplanning process is to minimize any misconfiguration that might occur, since Troubleshooting IPSec connection issues is not a simple task.There are nine basic tasks that we’ll perform in Order to set up an IPSec site-to-site connection to a remote IPSec peer:1. Handle design and policy issues.
2. Verify connectivity before configuring IPSec by using ping.3. Create an extended ACL to allow IPSec traffic.4. Configure ISAKMP/IKE Phase 1, using pre-shared keys for authentication.5. Create an extended ACL (crypto ACL) that defines which traffic is to be protected for the IPSec connection.6. Create a transform set.7. Create a crypto map that binds together our SA information.8. Activate our crypto map.9. Test our IPSec connectivity.
4.1.2 Site-to-site Connection Preparation Now that we have a basic understanding of the commands used to build an site-to-site IPSec tunnel, let’s look at an example configuration. This section shows an example of setting up an IPSec tunnel to a remote peer using the IPSec method.
Figure 4.1 shows the example network that will be used in this site-to-site IPSec configuration example. In this example, traffic between the 192.168.1.0/24 and192.168.2.0/24 networks should be protected.
Fig.4.1site-to-site network connection.
4.2 ISAKMP/IKE Phase 1 Configuration
In this section we’ll discuss the configuration of ISAKMP/IKE Phase 1. we’ll learnhow to
Enable IPSec Configure policies that will be used to negotiate how the management connection will be
protected Configure a pre-shared key for a remote peer
4.2.1 Management Connection PoliciesIn order to create a protected management connection we’ll need to create anISAKMP/IKE policy that defines the parameters that will be negotiated with theremote peer. Note that if we are connecting to Cisco devices, we can use the samepolicy for all the peers. However, if one of the peers is a non-Cisco device, we mightneed to create a separate policy for the non-Cisco device if it doesn’t support thesame level of security. For example, if one peer only supports DES for encryption, but all our other peers support AES, we would need to create two policies: one for each set of peers. To create a management policy, use the crypto isakmp policy command:Router(config)# crypto isakmp policy priority_# Router(config-isakmp)#
The priority number uniquely identifies the policy. The number does have significance: The smaller the policy number, the higher the priority. In other words, the policies are sorted numerically and sent in that order to the remote peer. Therefore, the order of the policies is important: make sure we
place the most secure policy at the top of the list (it has the lowest number). Also notice that the crypto isakmp policy command takes you into a subcommand mode. [10]
4.2.1.1 Creating Policy Parameters
Here are the commands to create a policy:Router(config)# crypto isakmp policy priority_#Router(config-isakmp)# authentication {rsa-sig | rsa-encr | pre-share} Router(config-isakmp)# encryption {des |3des | es | aes192 | aes 256} Router(config-isakmp)# group {1 | 2 | 5} Router(config-isakmp)# hash {md5 | sha} Router(config-isakmp)# lifetime #_of_secondsTo set the authentication method, use the authentication command:rsa-sig Digital certificatesrsa-encr RSA encrypted noncespre-share Symmetric preshared keys
If we specify pre-share, we ’ll need to create our shared key with the cryptoisakmp key command
4.2.1.2 Viewing Policy Parameters
To view our ISAKMP/IKE policies, use the show crypto isakmp policy command:
Router# show crypto isakmp policy Protection suite priority 1 encryption algorithm: DES - Data Encryption Standard (56 bit keys) hash algorithm: Message Digest 5 authentication method: preshared Key Diffie-Hellman Group: #1 (768 bit) lifetime: 86400 seconds, no volume limitIn the preceding example, this is the highest ranking policy (the priority is 1).The encryption algorithm is DES (the default); the HMAC function is MD5; the authentication method is pre-shared keys; the DH group is 1 (the default); and thelifetime is one day (the default).If a policy match is not found between the two peers, ISAKMP/IKE refuses thenegotiation and the establishment of the management connection fails. If a matchis found, ISAKMP/IKE will use the DH key group that was defined in the matchingpolicy to share the encryption and HMAC keys (which the tunnel originator creates) and authentication is performed based on what was found in the matching policy. to illustrate the configuration and use of ISAKMP/IKE Phase 1 policies, look at the following two code listings. Here are RTRA’s policies:RTRA(config)# crypto isakmp policy 1 RTRA(config-isakmp)# authentication pre-share RTRA(config-isakmp)# encryption 3des RTRA(config-isakmp)# group 2 RTRA(config-isakmp)# lifetime 3600 RTRA(config-isakmp)# exit RTRA(config)# crypto isakmp policy 2 RTRA(config-isakmp)# authentication rsa-sigRTRA(config-isakmp)# hash md5 RTRA(config-isakmp)# exit
If we are using an ISAKMP/IKE policy that uses pre-shared key authentication, we will need to configure a pre-shared key that will be used for authentication for the respective peer. Use the crypto isakmp key command to configure pre-shared keys for device authentication:
If the identity type is “address,” then use the address parameter; if the identity type is “hostname,” then specify the hostname parameter (the identity type is configured with the crypto isakmp identity command). A “0” indicates that the pre-shared key is not encrypted, and a “6” means the key is already encrypted (the service password-encryption command will encrypt the key). The key can be up to a 128-character alphanumeric value—if it is longer than this, the IOS only uses the first 128 characters.4.3 ISAKMP/IKE Phase 2 Configuration
The configuration for building the Phase 2 data connections. Topics covered includingthe configuration of global lifetime values for the data connections, crypto ACLs, transform sets, and crypto maps.
4.3.1 Data Connection Lifetimes
There are two lifetimes that determine when a data connection is torn down and rebuilt, if data still needs to be transferred: seconds and kilobytes. The default lifetime of a data SA is 3,600 seconds (one hour)—after this period, the router will tear it down and rebuild a new one. The default amount of traffic allowed to be sent across a data SA is 4,608,000KB—after this amount, the router will tear it down and rebuild a new one.
The lifetimes are negotiated during Phase 2. We can either configure the lifetimes globally, or override them on a peer-by-peer basis in a crypto map entry . Here are the commands to configure the global data SA lifetime values:Router(config)# crypto ipsec security-association lifetime seconds # of_secondsRouter(config)# crypto ipsec security-association lifetime kilobytes # of_kilobytes
4.3.2 Crypto ACLs
To define the traffic that is protected by the IPSec session, we need to create an extended ACL. This
ACL is commonly called a crypto ACL. Note that this ACL must use a unique number or name and is not applied to an interface on a router, but is referred to later on in the crypto map, which binds together the IPSec information for the secure data connection. In other words, the crypto ACL doesn’t filter traffic; it protects the traffic. [11] Here is the general syntax for our crypto ACL, which uses an extended ACL(this can be named or numbered):Router(config)# access-list ACL_ID permit IP_protocol local_addr wild_mask remote_addr wild_maskTraffic matching permit statements is protected, and traffic matching denies statements is not protected.Also, the ACL that we create should be mirrored on the remote IPSec peer—if it is not mirrored, this will cause one side or the other to protect certain packets that the other side will automatically drop. For example, if our ACL states an address of 192.168.1.0/24 as the source and 192.168.2.0/24 as the destination, these networks should be reversed on the remote peer.
4.3.3 Transform sets
Here is the syntax to create a transform set:Router(config)# crypto ipsec transform-set transform_set_name trans_#1 [trans_#2 [trans_#3[trans_#4]]] Router(config-crytpo-trans)# mode {tunnel | transport}
Within a transform set, we need to specify the transforms to protect the traffic. Basically, a transform is a security protocol and its protection method. There are four categories of transforms: AH, ESP encryption, ESP authentication, and compression.When specifying the transforms, we can choose one transform from each category. In other words, an invalid transform would be Router(config)# crypto ipsec transform-set badset1 ah-md5-hmac ah-sha-hmacThis is invalid because we can only have one parameter for AH. Here is another invalid one:Router(config)# crypto ipsec transform-set badset2 ah-md5-hmac esp-des esp-nllThis one is invalid because it has two encryption algorithms. The following is a valid transform set:
Router(config)# crypto ipsec transform-set goodset esp-sha-hmac esp-desThis is correct because it specifies an HMAC function of MD5 for ESP and DES as an encryption algorithm for ESP. If we omit a security protocol from the transform set, then that protocol will not be used for the data IPSec connection.
Table 4.1 Lists the valid phase2 transforms
To view the transform sets on our router, use the show crypto ipsec transform-set Command:Router# show crypto ipsec transform-set
4.3.4 Crypto Maps
A crypto map is a Cisco entity used to bind together all of the ISAKMP/IKE and security components to form data SAs. A crypto map is given a name and is bound to an interface to activate it. By default, our router uses the source IP address of the interface the traffic exits in the IPSec packets. If we have two physical interfaces that our router can use to reach the remote peer, we might want to create a loopback interface and have the router use this as its source IP address. Otherwise, for each interface (IP address) our router can use, we’ll need to define these on the remote peer—using a loopback address simplifies our configuration .Crypto maps contain one or more entries, where each entry represents a particular remote peer or site our router will be connecting to. Each entry contains the following information:
Which traffic between this router and the remote IPSec peer. Whether manual or dynamic ISAKMP/IKE should be used. The transform set(s) to use to protect the data connections. Optionally, the PFS DH key group to use to share the data keys. Optionally overriding the global lifetime values for the data Sas.
4.4. Crypto Map entry requirements
When creating an entry in a crypto map, the information that we configure has to correspond to information in the remote peer’s crypto map entry:. Each side must agree upon the use of ISAKMP: manual configuration or dynamic ISAKMP/IKE negation. The crypto ACLs used must be symmetrical on the two peers. At least one transform set must match between our router and the remote IPSec peer. If PFS is used, the DH key group must match. Depending on the vendor, the lifetimes of the data SAs might have to also match.If these requirements are not met, then data SAs will not form.
4.5 Crypto Maps and traffic
Once data SAs are formed and IPSec Phase 2 has completed, the router will use the rules in Table 4.2 concerning data traffic. Inbound refers to traffic entering our network and outbound to traffic leaving our network.
Table 4.2 Crypto ACLs and Traffic.
4.6 Crypto Map types
There are two types of crypto maps: Static: Static crypto maps are used when we know the peer that we are connecting to and its IPSec information and abilities, as well as the traffic to be protected and the transforms that should be used. This is typically the case for site-to-site connections.
Dynamic: Dynamic crypto maps are used when we do not know the remote peer’s information, such as remote access users. This is typically the case when dialup clients are trying to access us and they are dynamically acquiring Note that with dynamic crypto maps, the remote side must initiate the connection—our router cannot, since it does not know the IP address of the remote device.
4.7 Static Crypto Map ConfigurationTypically, we will only have to create one static crypto map, but it may have several entries. An entry in the map specifies the locations or peers the router will be connecting to. This map can be applied to multiple interfaces if we have two or more interfaces for redundancy. Here is the basic syntax to create an entry in a crypto map: Router(config)# crypto map map_name sequence_# {ipsec-isakmp | ipsec-manual}Router(config-crypto-map)#
The crypto map must be given a name to bind these entries to the crypto map. This name must be unique among all the names of the static crypto maps on our router. Next, we specify a sequence number for the entry. These sequence numbers are used by the router to process the crypto map entries when determining which entry to use for a peer to build a tunnel. They are processed from the lowest sequence number to the highest. The crypto map entry contains the necessary information in order to create the data connections; therefore, the router will process these entries until it finds a match with the remote side—if no match is found, then no tunnel is built. There are two types of entries that we can specify:ipsec-isakmp: Uses ISAKMP/IKE to negotiate the security parameters, including keying. ipsec-manual: Requires we to manually configure the data connections, including the keys to use—should only be used if the remote side doesn’t support dynamic ISAKMP/IKE . after entering e the crypto map statement to create an entry, we are taken into a sub configuration mode where we can specify our SA information.[12]
4.8 Crypto Map entriesTo create an entry where ISAKMP/IKE will build the tunnel, use the following configuration:Router(config)# crypto map map_name sequence_# ipsec-isakmp Router(config-crypto-map)# set peer {hostname | IP_address} Router(config-crypto-map)# match address ACL_ID Router(config-crypto-map)# set transform-set name_of_transform_set1 [name_of_transform_set2…set6] Router(config-crypto-map)# set pfs {group1 | group2 | group5} Router(config-crypto-map)# set security-association lifetime {seconds #_of_seconds | Kilobytes #_of_kilobytes}If there are other entry parameters we can configure, but these are the most common. Table 4.3 explains the Sub configuration mode commands for a crypto map entry. we can enter more than one peer, for redundancy, by configuring the set peer command multiple times, with different peer addresses or names. The first set peer command we configure will be the primary. The set transform-set command specifies the transform set or sets (up to six) that can be used to protect traffic between our router and the remote peer. We should only have to specify one transform set if there is only one peer; if we have multiple peers with multiple capabilities, then we’ll need to specify
more than one transform set: make sure, though, that we enter the transform sets from most to least secure, since this is the order that they are exchanged during the Phase 2 negotiation processes. If we do not configure PFS with the set pfs command, the data SA keys are shared across the Phase 1 management connection.
Table4.3 crypto map entry command
4.9 Activating a Crypto Map
Once we have created our crypto map (and its corresponding entries), we need to activate it on our router’s interface that will be handling inbound and outbound IPSec traffic. Use the crypto map command on our interface to do this: Router(config Once)# interface interface_IDRouter(config-if)# crypto map crypto_map_name
we only have to apply the crypto map once—if we add or modify any entries in the crypto map, we do not have to re-apply it. By default, the source IP address in the header of the PSec-tunneled traffic will be that of the interface where the crypto maps is applied. If we have two interfaces but want to represent them as a single, logical interface to make our and our remote peers’ configuration easier (but still provide redundancy), we can change the IP address used for IPSec with the local-address parameter: Router(config)# crypto map crypto_map_name local-address interface_IDTypically, we will want to use the name of a loopback interface; however, this interface must have a public (reachable) address, since the remote peer will be using this address to reach our router.
4.10 Crypto Map verification
Once we have configured our crypto map, use the show crypto map command to view the entries in our crypto map. Here is an example of the use of this command:Router# show crypto map Please note that the show crypto map command displays the entries—not the actual data SAs.
4.11 Troubleshooting Connections
IPSec session connections are not built automatically; instead, traffic that matches a crypto ACL triggers the process of ISAKMP/IKE building a tunnel. To test our configuration, have a device trigger traffic that matches the crypto ACL. Of course, one of the best methods of testing is to include ICMP traffic associated with our local router and destination IPSec peer in the crypto ACL; then from our router ,ping the destination router. This should start the process to bring the tunnel up. Of course, there is no guarantee that we have configured everything correctly, so we will need to use various commands to troubleshoot connectivity problems.
This section introduces us to some of the show, clear, and debugs commands we can use for troubleshooting .[13]
4.11.1 Managing Phase 1 Connections:
To view ISAKMP/IKE management connections, use the show crypto isakmp sa command:Router# show crypto isakmp sadst src state conn-id slot The “state” column describes the state of the ISAKMP/IKE connection.
To clear our active ISAKMP/IKE connections, use the clear cryptoiskamp command:Router# clear crypto isakmp [connection_ID]Omitting the connection_ ID parameter will cause all management connections to be torn down.
4.11.2 Managing Phase 2 Connections
To view the IPSec data SAs that have been established in Phase 2, use the show crypto ipsec sa command. Here is an example of the use of this command:Router# show crypto ipsec sa If the Phase 2 tunnels have successfully been built, we can discern this from the preceding output. Toward the top of the output if we see the #pkts values incrementing, then traffic is traversing the tunnel. The #pkts encaps value indicates that our router is encapsulating packets to be sent to the remote peer; #pkts dcaps indicates that we are receiving packets from the remote peer. Toward the bottom of the output we should see SPI values(spi) for the inbound and outbound SAs(ah and/or esp).To tear down the data SAs, use the clear crypto sa command: Router# clear crypto sa Router# clear crypto sa peer {IP_address | host_name}Router# clear crypto sa map crypto_map_name Router# clear crypto sa entry dest_IP_address protocol SPI_#
If we do not qualify which SAs to remove (the first command), all data SAs are torn down. The peer parameter removes data SAs associated with the specified peer. The map parameter removes all data SAs associated with the specified crypto map. The entry parameter removes only the specified data SA for a peer, based on the SPI value. To clear the counters in the output of the show crypto ipsec sa command, use the clear crypto sa counters command.
4.12 Debug Commands
If Phase 1 or Phase 2 connections are not successfully being established, you can use the following debug commands:debug crypto isakmp Troubleshoots problems with building the management connection during Phase 1 and the data connections during Phase 2debug crypto ipsec Troubleshoots problems with building the data connections.
Of the two commands, we have almost exclusively used the first one, since it displays the setup of l three connections: Phase 1management and Phase 2 data connections. Table 4.4 lists some common problems we should look for in the output of the debug crypto isakmp command. [14]
4.13 Troubleshooting steps
This section summarizes the approach we should take if we experience problems bringing up an IPSec tunnel for a site-site connection:1. Make sure we can ping the remote peer in clear text to ensure that a layer 3connectivity issue is not causing a problem.2. Use the show crypto isakmp sa and show crypto ipsec sa commands to see the state of the tunnels.3. Quickly review the configurations on both peers (show running-config).4. Use the debug crypto isakmp command to troubleshoot Phases 1 and 2.5. Generate interesting traffic (traffic that matches the crypto ACL) to bring up the tunnel and look for errors in the debug output.6. Verify that the crypto ACLs have increased hit counts based on generating interesting traffic (show access-list).7. Delete any SAs (clear crypto sa and clear crypto isakmp)and go back to step four.
4.14 Classic Method site-to-site exampleNow that we have a basic understanding of the commands used to build an IPSec tunnel, let us look at an example configuration. This section shows an example of setting up an IPSec tunnel to a remote peer using the classic method.
4.14.1 Network topology:Figure 21-2 shows the example network that will be used in this class L2Lconfiguration example. In this example, traffic between the 1.0.0.0/8 and 4.0.0.0/8 networks should be protected.
Fig 4.2 Site to site VPN network topology
router ConfigurationHere’s RouterA’s configuration:RouterA(config)# crypto isakmp policy 10 RouterA(config)# authentication pre-shareRouterA(config)#crypto isakmp key 123 address 3.0.0.2RouterA(config-if)#crypto ipsec transform-set vpnset esp-aes esp-sha-hmacRouterA(config-if)# set peer 3.0.0.2RouterA(config-if)# set transform-set vpnsetRouterA(config)# match address 100
RouterA(config-isakmp)# interface FastEthernet0/0RouterA(config-isakmp)# ip address 1.0.0.1 255.0.0.0RouterA(config-isakmp)# interface FastEthernet0/1RouterA(config-isakmp)# ip address 2.0.0.1 255.0.0.0RouterA(config-if)# ip route 0.0.0.0 0.0.0.0 FastEthernet0/1RouterA(config)#access-list 100 permit ip 1.0.0.0 0.255.255.255 4.0.0.0 0.255.255.255RouterA(config)#access-list 100 permit ip 1.0.0.0 0.255.255.255 4.0.0.0 0.255.255.255
Here’s RouterB’s configuration:RouterB(config)# crypto isakmp policy 10 RouterB(config)# authentication pre-shareRouterB(config)#crypto isakmp key 123 address 3.0.0.2RouterB(config-if)#crypto ipsec transform-set vpnset esp-aes esp-sha-hmacRouterB(config-if)# set peer 2.0.0.1RouterB(config-if)# set transform-set vpnsetRouterB(config)# match address 100 RouterB(config-isakmp)# interface FastEthernet0/0RouterB(config-isakmp)# ip address 4.0.0.1 255.0.0.0RouterB(config-isakmp)# interface FastEthernet0/1RouterB(config-isakmp)# ip address 3.0.0.2 255.0.0.0RouterB(config-if)# ip route 0.0.0.0 0.0.0.0 FastEthernet0/1RouterB(config)#access-list 100 permit ip 4.0.0.0 0.255.255.255 1.0.0.0 0.255.255.255
5.1 Simulation Environment Cisco Packet Tracer 5.3 is used to evaluate the performance of the site to site VPN design and implementation. In our network topology we are connected two branch office via two VPN gateways. A VPN backbone network is connected to two VPN gateways. When the packet simulated from source to destination it works on different layers as follow as:
5.2 Simulation ScenarioWhen the packet goes to inbound direction then packet matches a crypto ACL entry and is in clear text then the packet is dropped. When packet matches crypto ACL entry and is protected then the packet verified and decrypted and when the packet goes to inbound direction sometimes it doesn’t match a crypto ACL (clear text or already protected) then the packet is protected by IPsec.
When the packet goes to outbound direction there are some action also take place such as packet matches a crypto ACL entry and is clear text then the packet is protected by IPSec. When packet matches a crypto ACL entry and is already protected then the packet protected again by IPSec and the another action is when the packet doesn’t match a crypto ACL (clear text or already protected) then the packet is ignored by IPSec
Fig 5.1 Inbound packet format
Fig 5.2 Outbound packet format
5.3 Simulation ResultThe simulation results are shown as experienced while working with graphs having different type of complexities. As the whole simulation is done in Cisco Packet Tracer 5.3, several experiments have been performed to verify protocols efficiency and checked with several network infrastructures.
Number of packets
Fig 5.3 Number of packets varying with number of transmitted packet
Fig6.3 illustrates the performance of the site to site VPN with respect to the number of packets along with the number of transmitted packets. In this case some of packets are transmitted from source to destination and some packets are dropped in most cases 100 percent packets are transmitted.
Fig 5.4 Number of packets varying with number of encapsulated packetsFig6.4 illustrates the performance of the site to site VPN with respect to the number of packets along with the number of encapsulated packets. In this case some of packets are encapsulated and some packets are dropped. However, in most cases 100 percent packets are encapsulated.
Fig 5.5 Number of packets varying with number of encrypted packets
Fig6.5 illustrates the performance of the site to site VPN with respect to the number of packets along with the number of encrypted packets. In this case some of packets are encrypted and some packets are dropped. However, in most cases 100 percent packets are encrypted.
Fig 5.6 Number of packets varying with number of decrypted
Fig6.6 illustrates the performance of the site to site VPN with respect to the number of packets along with the number of decrypted packets. In this case some of packets are decrypted and some packets are dropped. However, in most cases 100 percent packets are decrypted.
6.1 SummaryA VPN is a session between two devices and/or networks that is protected. The three general types of VPNs are intranet, extranet, and remote access. The functions provided by a VPN can include confidentiality, packet or data integrity and authentication, identity validation, encapsulation method, control of traffic using the VPN. Some common VPN solutions include GRE, PPTP, L2TP, IPSec, and some of the technologies employed by VPNs. IPSec, the most commonly deployed VPN solution today. IPSec is composed of many standards to build and maintain a secure session between two peers. IPSec provides authentication, confidentiality, packet integrity and encapsulation. The main protocols involved with IPSec are ISAKMP, IKE, DH, AH, and ESP. ISAKMP/IKE builds and maintains the three connections (one management and two data). AH and ESP protect the data
connections. A Phase 1 management policy contains an authentication method, an encryption algorithm, an HMAC function, a DH key group, and a lifetime. When we configure these values for a policy and if we omit a parameter, the policy will use a default value for the missing policy parameter. The defaults, if omitted, are RSA signature (certificates), DH group 1 keys, DES, SHA-1, and 86,400 seconds for the lifetime. Preshared keys are configured with the crypto isakmp key command. Crypto ACLs define the traffic that is to be protected, where a permit statement specifies that the traffic be to be protected. Crypto ACLs on peers should be mirrored. Transform sets define how the data connections should be protected: the protocol (ESP or AH), the encryption algorithm (if ESP), the HMAC function, and the mode. To activate a crypto map, it must be applied to an interface. To view the Phase 1 connections, use the show crypto isakmp sa command. A connection with a QM_IDLE state indicates that the management connection has successfully been built. To view the Phase 2 connections, use the show crypto ipsec sa command. To troubleshoot connections, use the debug crypto isakmp and debug crypto ipsec commands.
6.2 Future WorkThe Virtual Private Network can be extended to a number of possible areas for future work. As an instance, following features will be appended
As the VPN market becomes larger, more applications will be created along with more VPN providers and new VPN types.
Networks are expected to converge to create an integrated VPN Improved protocols are expected, which will also improve VPNs.
