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 Types
VPNs fall under two implementation types:
? Site-to-Site
? Remote Access
The 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 VPN
1.3.2 Remote Access
Remote 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 VPN
The 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 project
Chapter 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 IPSec
It 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 Features
IPSec 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 gateway | No | N/A (client is VPN endpoint) | N/A (client is VPN endpoint) |
| 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 authentication
As 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 solution
Crypto vision provides the CA solution CV act PKI Integratedwith highly sophisticated certificate management abilities, which covers the whole lifecycle of a digital certificate (certificate lifecycle management). CV act PKIntegratedsupports 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 Integratedwas 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-to-site virtual private network (VPN) connections
- Site-to-site IPsec tunneling with non-Microsoft IPsec gateway
2.5 Packet Filter
The 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 security
IPSec 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 encryption
Authentication username/password (such as Active Directory or RADIUS); user name and token pin. [2]
2.7 Which of the two VPNs provide a greater
return 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 Management
IPSec 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)
l IKE provides:
· Automation and scalability
· Improved security
· Encryption keys be changed frequently
l Hybrid IKE
· Proposed standard designed by Check Point
· Allows use of existing authentication methods
2.12 VPN Protocols
The 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 VPN
Applications: 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 Overview
Even 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 Addresses
The 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 Addressing
This 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 Firewalls
It 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 Overview
This 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 Components
VPNs 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 Deployment
Head 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 Maps
Dynamic 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 Initiation
When 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 Gateways
An 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 to
derive 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 Parameters
It 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 Parameters
The 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 Parameters
The IKE Phase 2 parameters used in Scenario 1 are:
• TripleDES
• SHA-1
• ESP
4.1 Configuration overview
Some 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.