Mettle SE supports three VPN technologies at this moment, they are IPsec, SSL VPN, PPTP and L2TP. Based on your needs and requirements you may wish to implement any of these three VPN technologies.
The primary strengths of IPsec-based VPN for enterprise are as follows:
- Low-cost Internet access can be used for Network transport.
- Inherently strong security features enable user authentication, data confidentiality, and integrity. Users are authenticated with digital certificates or preshared keys. Packets that do not conform to the security policy are dropped.
- Head-end IPsec VPN devices scale to serve many thousands of geographically dispersed users.
- No service provider intervention is required to set up VPN, although many enterprises choose to take advantage of the service provider's managed-service experience for regional or national multi-site deployments to reduce costs, accelerate service introduction, and mitigate risk.
- When configured for split Tunneling, remote VPN client can forward Internet-destined traffic directly, instead of through an IPsec Tunnel, and establish a Tunnel only for related traffic being forwarded to the hub. This reduces congestion at the hub site.
- IPsec-based VPNs are application agnostic. This means that any application may be accessible from anywhere, given that adequate IPsec VPN access is provided. For example, advanced applications such as telephony or QoS will be able to function over IPsec tunnels.
- IPsec will allow access to almost all Network applications without modifications to the central site or client.
- IPsec will allow almost all applications to be supported without custom changes.
- As IPsec is designed for IP unicast traffic only, with adequate support for IP multicast over the virtual adapter concept, IPsec can provide an experience equivalent to that at an office.
Drawbacks of IPsec VPN:
- Remote hosts participating in IPsec VPN need client software installed.
- For the remote hardware client, traffic from each end host to the remote hardware client still traverses LAN in clear text.
- As interesting traffic is encapsulated into an IPsec tunnel, efficiency of payload in the IP data packet is decreased because of IPsec protocol overheads.
- Designing, deploying, and troubleshooting an IPsec VPN is a complex task. You need highly skilled professionals with good operational experience.
- Because multi-vendor solutions are seldom deployed, interoperability among different vendors has not been proven in the marketplace, adding to the original complexity of the IPsec VPN solution.
- The most recommended and secure method for key exchange is IPsec client-based certificates. However, certificate distribution authorities themselves are a complex undertaking.
- Retaining QoS takes some design efforts in the IPsec VPN solutions because most crypto engines in the hardware devices found in the market today cannot prioritize high-priority traffic when encrypting or decrypting the traffic.
- With the ESP flavour of IPsec VPN, Network Address Translation (NAT) and Port Address Translation (PAT) present a huge problem as the authentication checksums fail because of change in the IP header address.
- SSL/TLS operates in ring 3 of the secure OS ring architecture so there is no intertwining with the OS kernel like IPSec. You can use IPsec and SSL /TLS simultaneously on a Windows machine. An IPsec client operates in ring 0 so when the IPsec client software becomes unstable the whole OS can become instable.
- Very easy configuration of the VPN client. The major advantage of SSL/TLS over IPsec is the simple configuration of the client. Additional configuration can be pushed to the client. Solutions are available for windows 2000/XP, mac OS-X and Linux. SSL/TLS clients are available against no additional cost. There is no licensing structure for SSL/TLS VPN Tunnels.
- No packet loss during re-keying. SSL/TLS uses a secondary channel for re-keying. Data transfer will not be interrupted while re-keying with IPsec tends to loose some packets when old keys are dropped and the new keys become available.
- SSL/TLS works perfectly with NAT. SSL/TLS does not run authentication on the packet source address so it can successfully traverse a NAT device.
- Load balancing/fail over: you can make redundant Tunnels by using an additional ADSL- or Cable connection.
- The most widely deployed/tested security protocol. SSL/TLS uses by default the blowfish protocol for encryption and the SHA1 protocol for authentication. These security protocols are widely deployed and thoroughly tested and do not have known security flaws.
- The SSL server can push IP addresses as well as routes to the client. Information about available DNS or WINS servers can be pushed as well.
PPTP first encapsulates the data using PPP (Point-To-Point Protocol) and then encrypts the data stream using MPPE (Microsoft Point-To-Point Encryption). Session keys can be 40, 56 or 128 bit and are rotated frequently to increase security.
Some facts about PPTP:
- PPTP easy to deploy
- PPTP use TCP, this reliable solution allow to retransmit lost packets
- PPTP support
- PPTP less secure with MPPE(up to 128 bit) data encryption begins after the PPP connection process (and, therefore, PPP authentication) is completed
- PPTP connections require only user-level authentication through a PPP-based authentication protocol
L2TP (Layer Two Tunneling Protocol) supports non-TCP/IP clients and protocols (such as Frame Relay, ATM and SONET).
L2TP does not provide any encryption orconfidentiality by itself. It relies on an encryption protocol that it passes within the tunnel to provide privacy. Nowadays L2TP connections do not negotiate the use of PPP encryption through Microsoft Point-to-Point Encryption (MPPE). Instead, encryption is provided through the use of the Internet Protocol security (IPSec) Encapsulating Security Payload (ESP) header and trailer. It is also important to note that IPsec is more resource intensive than PPTP, hence the overhead with a L2TP solution is higher than PPTP.
The entire L2TP packet, including payload and L2TP header, is sent within a User Datagram Protocol UDP datagram. It is common to carry Point-to-Point Protocol (PPP) sessions within an L2TP tunnel. IPsec is often used to secure L2TP packets by providing confidentiality, authentication and integrity. The combination of these two protocols is generally known as L2TP/IPsec.
The two endpoints of an L2TP tunnel are called the LAC (L2TP Access Concentrator) and the LNS (L2TP Network Server). The LAC is the initiator of the tunnel while the LNS is the server, which waits for new tunnels. Once a tunnel is established, the network traffic between the peers is bidirectional. To be useful for networking, higher-level protocols are then run through the L2TP tunnel. To facilitate this, an L2TP session (or 'call') is established within the tunnel for each higher-level protocol such as PPP. Either the LAC or LNS may initiate sessions. The traffic for each session is isolated by L2TP, so it is possible to set up multiple virtual networks across a single tunnel. MTU should be considered when implementing L2TP.
The packets exchanged within an L2TP tunnel are categorized as either control packets or data packets. L2TP provides reliability features for the control packets, but no reliability for data packets. Reliability, if desired, must be provided by the nested protocols running within each session of the L2TP tunnel.
The process of setting up an L2TP/IPsec VPN is as follows:
- Negotiation of IPsec security association (SA), typically through Internet key exchange (IKE). This is carried out over UDP port 500, and commonly uses either a shared password (so-called "pre-shared keys"), public keys, or X.509 certificates on both ends, although other keying methods exist.
- Establishment of Encapsulating Security Payload (ESP) communication in transport mode. The IP protocol number for ESP is 50 (compare TCP's 6 and UDP's 17). At this point, a secure channel has been established, but no tunneling is taking place.
- Negotiation and establishment of L2TP tunnel between the SA endpoints. The actual negotiation of parameters takes place over the SA's secure channel, within the IPsec encryption. L2TP uses UDP port 1701.
When the process is complete, L2TP packets between the endpoints are encapsulated by IPsec. Since the L2TP packet itself is wrapped and hidden within the IPsec packet, no information about the internal private network can be garnered from the encrypted packet. Also, it is not necessary to open UDP port 1701 on firewalls between the endpoints, since the inner packets are not acted upon until after IPsec data has been decrypted and stripped, which only takes place at the endpoints.
A potential point of confusion in L2TP/IPsec is the use of the terms tunnel and secure channel. The term tunnel refers to a channel which allows untouched packets of one network to be transported over another network. In the case of L2TP/PPP, it allows L2TP/PPP packets to be transported over IP. A secure channel refers to a connection within which the confidentiality of all data is guaranteed. In L2TP/IPsec, first IPsec provides a secure channel, then L2TP provides a tunnel.
Some facts about L2TP(over IPsec):
- L2TP/IPSec data encryption begins before the PPP connection process
- L2TP/IPSec connections use the AES(up to 256bit) or DESUup to three 56-bit keys)
- L2TP/IPSec connections provide stronger authentication by requiring both computer-level authentication through certificates and user-level authentication through a PPP authentication protocol
- L2TP use UDP. It is a faster, but less reliable, because it does not retransmit lost packets, is commonly used in real-time Internet communications
- L2TP more “firewall friendly” than PPTP — a crucial advantage for an extranet protocol due to most firewalls do not support GRE