The primary role of a virtual private network (VPN) is to provide secure connectivity over a shared infrastructure. There are several types of VPNs and each provides a varying degree of security and scalability.
MPLS VPN architectures
MPLS VPNs send site-to-site VPN communications using Border Gateway Protocol (BGP) signaling, Multiprotocol Label Switching (MPLS) traffic isolation and router support for virtual routing and forwarding (VRF). MPLS labeling algorithms are used to encapsulate IP packets, and BGP is used to distribute VPN-related information between a company’s customer edge (CE) router and a service provider’s edge label switch router. Unlike other Layer 3 VPNs that use encryption to secure data, MPLS VPNs address security by separating traffic that is similar to Frame Relay and ATM. In addition, the labels of packets are examined to ensure that those that do not belong to the MPLS VPN are dropped.
An MPLS VPN is configured in either a star or full mesh topology. To set up an MPLS VPN, the customer’s and service provider’s MPLS-enabled network devices must be provisioned accordingly. You can learn in these two tips how to prepare enterprise WANs for MPLS/VPN integration or find out when companies should consider building MPLS networks.
Benefits of MPLS VPNs
MPLS VPNs enable service-level agreements and provide scalability and end-to-end Quality of Service (QoS). Thus, they are a good option if you want to outsource your WAN or need to ensure QoS for delay-sensitive traffic on a converged network. For more information, view these resources:
- MPLS technology overview
- MPLS VPN basics
- Understanding Layer 3 MPLS VPNs
- Find the best MPLS/VPN service for your WAN.
IPsec VPN architectures
An IPsec (Internet Protocol Security) VPN supports a variety of security functions to protect data as it travels over a public or private IP network. Packets are encrypted for data confidentiality and authenticated for data integrity. The source of packets is authenticated for data origin authentication, and anti-replay prevents delivery of duplicate packets. IPsec VPNs allow network architects to dictate what traffic is protected, how it is protected and who can receive it. The Internet Key Exchange (IKE) is used to communicate and negotiate these parameters between network devices. An IPsec VPN is usually configured in a star network topology.
Remote access IPsec VPN architectures
Remote access IPsec VPNs use specialized client software to initiate a secure connection with a private network. The user runs the software and selects a destination. This could be a host name or an IP address, for example. Once the user is authenticated and the IPsec tunnel is established, the user accesses applications as if from the corporate LAN. IPsec VPNs are usually configured in a star topology.
Site-to-site IPsec VPN architectures
In the case of site-to-site IPsec VPNs, session negotiation and authentication occurs between IPsec-enabled VPN routers at different locations. Instead of launching client VPN software, users launch applications directly. The router then initiates an IPsec session with the central location. After successful negotiation and authentication, a secure VPN tunnel is established.
Benefits of IPsec VPNs
IPsec VPNs provide a number of security functions beyond those you’ll find in an MPLS VPN. This type of Layer 3 VPN also costs less and offers more flexibility than private networks based on WAN infrastructures -- like leased line and Frame Relay -- because it uses public network access or existing private IP networks. IPsec VPNs are also easy enough to set up that many IT departments choose to do so themselves.
Unlike Secure Sockets Layer (SSL) VPNs, IPsec VPNs allow access to nearly all networked applications.
SSL VPN architectures
An SSL VPN provides remote access to Web-based applications via a Web browser. When the Web browser connects to an SSL VPN device, the browser and device are authenticated through digital certificates. The traffic sent between them is encrypted using the Secure Sockets Layer or Transport Layer Security.
This type of Layer 3 VPN does not require the use of specialized client software. However, because an SSL VPN resides at the session layer, it does not support applications that are not coded for SSL, such as standard email clients and multicast applications.
In an SSL VPN, the SSL protocol must keep track of each connection or application session. This tracking is handled by application proxies and requires adequate memory. To prevent bottlenecks created by compute-intensive encryption processes, the server requires adequate processing resources. The SSL VPN device can be integrated within the existing network topology.
Benefits of SSL VPNs
An SSL VPN offers flexible remote access. Web-based applications can be securely accessed from any device with a Web browser and Internet connection -- no specialized client software is required. As a result, end users can work securely from anywhere. An SSL VPN is also beneficial to the IT department because it eliminates the need to install and manage additional software. This is particularly helpful when you need to give network access to devices that aren’t managed internally.
SSL itself offers several additional benefits. It is broadly supported by commercial Web browsers, so there is low training overhead. Also, because SSL sessions are not locked to an IP address, users can enjoy transparent wireless roaming across access points. SSL also enables granular access control. You can limit an individual user’s access to specific Web pages or other internal resources.
→ Read Crystal Bedell's VPN tutorial to learn more.
About the author: Crystal Bedell is an award-winning writer and editor specializing in technology. She has written articles, tips and guides to help IT professionals evaluate technology, secure and modernize their IT infrastructure, solve business problems and prepare for IT certifications. As Principal of Bedell Communications, Crystal also analyzes technology trends and offers editing and content development services. She can be reached at email@example.com.
This was first published in December 2010