Tunnels in the IT networking world refers to a communications channel connecting two (2) networks or devices when those devices reside on different local networks or sub-nets. A tunnel may be secure (protected from eavesdropping, tampering, or both) or insecure. Certain types of tunnels are readily identified through their use of specific, universal network protocols. This article explores some of those protocols; notably, secure tunneling network protocols.
Contents
This article explains the following concepts:
Quality of Service (QoS)
Quality of Service (QoS) refers to a system of network traffic prioritization based on type of traffic. IP traffic is identified via a universal list of protocols, defined by the Internet Assigned Numbers Authority (IANA).
Protocol IDs enable uniform handling and rule-based traffic management,and promote verification processes for secure network connections.
What does QoS have to do with an article on tunneling IP protocols?
QoS is a service found on most routers. It may be used to prioritize incoming (and in some cases outgoing) network traffic. This can come in handy particularly on networks with limited bandwidth or high priority communications. Due to how they operate, tunneled connections require more bandwidth and processing power to maintain. Therefore, if multiple tunnels are implemented across a router, it's often wise to setup QoS rules such that your network traffic is prioritized and balanced accordingly.
IP Protocols
Nearly as old as the Internet itself, universal Network Protocol IDs are contained in the header of every IP packet, and identify the type of data contained in the data portion of the packet. IPv4 uses a field called, "Protocol" to store the protocol ID. IPv6 calls its version of the same field, "Next Header."1 Identifying protocols by a universal ID is most pertinent to routers. For example, it makes network Quality of Service (QoS) possible.
Tunneling Protocols
Tunneling protocols only encapsulate packets. Simply a conduit or "tunnel" as the term implies, they provide no authentication or encryption. Operating at Layer 2 or 3 of the OSI networking model, Tunneling Protocols transport network (IP) packets (Layer 3) or data link (Ethernet) frames (Layer 2).
Here are some examples of protocols related to secure tunneling:
- ESP (Protocol 50): Encapsulated Security Payload
- GRE (Protocol 47): Generic Routing Encapsulation
- AH (Protocol 50) + ESP (Protocol 51) combined: IPsec (Internet Protocol Security)
- IP in IP (Protocol 4): IP in IPv4/IPv6
- L2TP (Protocol 115): Layer 2 Tunneling Protocol; relies on encryption protocols it passes thru
- SIT/IPv6 (Protocol 41): IPv6 in IPv4/IPv6
Common Tunneling Protocols
Certain tunneling protocols are more frequently used than others.
GRE (Generic Routing Encapsulation)
Generic Routing Encapsulation (GRE) is a Layer-2 (datalink) protocol that performs encapsulation only. It offers no encryption and is stateless. You may think of it as a private, but insecure connection. See RFC 2784 [2000], RFC 1701 [1994], and 1702 [1994].
PPTP (Point-to-Point Tunneling Protocol)
Point-to-Point Tunneling Protocol or PPTP is an obsolete Layer-2 Virtual Private Network (VPN) protocol. PPTP is a bit convoluted. First, it establishes a TCP connection to a remote network peer over port 1723. Next, it sets up a GRE encapsulation tunnel (also Layer-2), and wraps a PPP (Point-to-Point Protocol) - another Layer-2 protocol - inside the GRE encapsulated tunnel. Finally, the real data may be sent securely through the PPP tunnel. However, security is a relative term. PPP harkens back to the days of dial-up connections to Internet Service Providers (ISPs). By today's standards, PPP in particular is very weak. Both PPTP and PPP should be avoided.
IPsec
IPsec is the most widely adopted Virtual Private Network (VPN) protocol. One can think of OpenVPN as the gold standard of high security when it comes to VPN protocols, while IPsec is the standard when it comes to IT security and VPNs. In fact, it is so popular it has been adapted for use with other protocols, including GRE and L2TP. IPsec is often described as a protocol - and it can be considered as such - however, it is generally better thought of as a framework.
Why is IPsec so popular? IPsec was the "first mover" in the IT industry to provide all of the following in a single product:
- Secure key exchange
- Authentication
- Encrypted data payload
- Works in both client-to-host (server) and host-to-host modes
IPsec introduced the concept of a Security Association to VPNs. Security associations are security policies describing how a communication between two (2) network peers will operate. IPsec requires network peers to negotiate security associations before a secure tunnel is created in the first place.
Created in 1995, IPsec has withstood the test of time at the expense of an increasingly complex framework. Considering an IPsec implementation? Be certain you understand its pros and cons before committing to it. A detailed breakdown may be found here. The most significant factor in IPsec deployments - and what makes this security framework confusing - is grasping IPsec's conglomeration of different protocols. IPsec is in fact a nested group of other protocols, resulting in a complicated hierarchy of standards.
IPsec over GRE
This one is a bit of an oddball. It is a site-to-site Transport protocol only. An IPsec connection is established over an existing GRE tunnel. The purpose is to allow IPsec usage over a Layer 2 network connection. IPsec itself operates only on OSI Layer 3, so this trick gets around that since GRE may be implemented as either a Layer 2 or Layer 3 connection. The concept is defined in RFC 2457: Definitions of Managed Objects for Extended Border Node [1998].
L2TP
Layer-2 Tunneling Protocol or L2TP is normally used to establish site-to-site VPN connections, such as two (2) routers connecting portions of a distributed Wide Area Network (WAN). L2TP provides no encryption capabilities. Much like GRE, it simply establishes a connection between two (2) remote network peers, and relies upon other protocols piggy-backing on L2TP to handle encryption and confidentiality needs as desired. IPsec is the most common solution when encryption and/or authentication are desired. L2TP can be used alone if just establishing a conduit is all that is required, but this approach is not recommended when traffic must traverse the public Internet.
L2TP/IPsec Combo
This is the typical implementation profile of L2TP. As described above, L2TP by itself is not secure. Establishing an IPsec connection inside an L2TP tunnel permits a host of options for a network administrator to provide varying levels of security. In this case, L2TP provides some authentication for Phase 1 of the IPsec key exchange process via IKEv2 by virtue of the fact the L2TP connection has already established a connection with the remote host. Note this method does not impact the threat of Man-in-the-Middle (MitM) attacks, since L2TP by itself is not encrypting the traffic inside its tunnel. L2TP by itself is just a transport method.
L2TPv3
L2TPv3 is NOT a more advanced version of L2TP. It is a special version of L2TP's Layer-2 VPN protocol used by telecommunications carriers. It is mentioned here only for completeness.
Best thought of as a routing technique across long distances, L2TPv3 is used to transmit vast amounts of data over a virtual Layer-2 encapsulation connection. Its purpose is to reduces the time it takes to move data from one endpoint to another, while simultaneously reducing overhead on the network. The L2TPv3 connection is established ahead of time, and this virtual direct line of communication is held open until needed. The process benefits carriers by reducing network latency (a measurement of the time it takes to transfer data between two endpoints). Higher latency means longer wait times, and is normally caused by network traffic congestion somewhere along the communication path. L2TPv3 reduces latency by establishing an endpoint-to-endpoint VPN connection ahead of time and holding the connection open until needed. This in turn makes sending information between the endpoints much faster. L2TPv3 is often used by carriers to maintain an open connection between two (2) points when the data transmissions are likely to be in bursts or periodic, consist of very large amounts of data, and/or when the connection path between two (2) endpoints is complex.
OpenVPN
OpenVPN is the VPN poster child of strong security. If you want a VPN with robust security and privacy protection, your best choices are OpenVPN or IPsec. While the latter is more widely implemented, OpenVPN is superior when it comes to security and privacy protection options. Note the greater the emphasis on security and/or privacy, the greater the (negative) impact to throughput volume and speed of the connection due to increased processing demands on both the client and server.
OpenVPN and IPsec differ substantially in architecture philosophy. IPsec relies on a number of external programs to handle various tasks such as encryption key negotiations, while OpenVPN is completely self-contained. There are pros and cons to either approach.
OpenVPN uses UDP port 1194 by default, though this can be changed.
SSTP
SSTP (Secure Socket Tunneling Protocol) is basically another flavor of PPP, and shares some similarities with PPTP. However, SSTP has some design improvements that make it still marginally useful today. SSTP uses TCP port 443, transporting data along a PPP tunnel via an SSL/TLS channel. This combination provides transport level security in the form of key negotiation, encryption, and traffic integrity checking. It's use of TCP on port 443 - the de-facto common SSL/TLS/HTTPS port - allows it to masquerade as normal HTTPS traffic, making it difficult even for deep packet inspection techniques to detect there is an underlying PPP tunnel.
To reiterate: The data payload is encapsulated in a PPP tunnel, which is in turn encapsulated inside an independent SSL/TLS channel. Thus, you can get through just about any type of traffic except authenticated HTTPS proxy connections. The main drawbacks of SSTP are it's slow due to its complexity and connection overhead, and the security methods it offers are less robust than other solutions. For instance, SSTP provides user authentication, but not device authentication.
WireGuard
WireGuard is a newcomer to the world of VPNs. An open source project born in 2015, its purpose is to improve on the throughput performance of top dogs IPsec and OpenVPN, while simultaneously delivering the highest level of modern security encryption and authentication techniques. WireGuard attempts to deliver on this promise primarily by utilizing a very narrow choice of cryptographic ciphers and keeping the size of the code base as small as possible. Overall, WireGuard is built around this concept of smaller is better. As of this writing, only a handful of VPN service providers support WireGuard. It is not currently considered production-ready by any measure, and should be viewed as experimental. This status is not likely to change for the foreseeable future.
Honorable Mentions
These products are more common that you might think. However, they are certainly not consumer-oriented and are rarely (if ever) supported by commercial VPN providers. They may be of interest if you are planning to setup up a standalone VPN client and server combination.
OpenConnect
OpenConnect is an open source VPN solution. Originally created as a hack to connect Linux servers with a proprietary commercial SSL based VPN protocol produced by Cisco Systems, Inc., OpenConnect has since evolved into a stand-alone VPN platform. OpenConnect is fairly common in the wild due to its simple implementation. It uses SSL/TLS and DTLS (Datagram Transport Layer Service), defined under RFC 4347.
OpenConnect has a number of enhancements that make it most useful to professionals accustomed to working with Cisco and Juniper Networks routers. OpenConnect supports IPv4, IPv6, and SOCKS5 proxies.
Teredo Tunneling
An invention of Microsoft, Teredo Tunneling is a virtual network interface that provides simulated IPv6 support by transporting IPv6 over an IPv4 connection. It was launched as a stop-gap measure for users of Microsoft's Windows series of operating systems with applications requiring IPv6 connectivity when the user's ISP (Internet Service Provider) did not support an IPv6 gateway to the Internet.
Teredo Tunneling requires connecting to a Teredo Relay, which is a proxy server that receives the IPv6-in-IPv4 Teredo packets, converts them to native IPv6 traffic, transmits them to the destination host, and reverses the process back to the originating host (the Windows PC that initiated the Teredo Tunnel). Teredo uses UDP on port 3544.
Teredo should be considered a legacy technology, though it is still used today. Teredo was standardized in RFC 4380.
Are you using a Windows PC and having trouble with an application that is trying to use the Teredo Network Adapter? If your ISP supports IPv6 (it should), make sure your router/firewall is allowing IPv6 throughput. Turning that on should obviate the need for using Teredo. You may also need to ensure your PC has IPv6 enabled in its physical network adapter interface.
It was common practice up until the mid-2010's for ISPs to not support IPv6 for home and small business users, as the ISPs' last-mile equipment could not handle it. However, that problem is now virtually unheard of, and hence blocking IPv6 traffic locally should be a non-issue for nearly anyone. Thus, there is likely no real need to use Teredo Tunneling today unless your local network is artificially blocking it.
VXLAN
Virtual Extensible LAN (VXLAN) does not fit the same mold as any other protocol mentioned in this article. In fact, it uses the opposite strategy.
VXLAN is a network virtualization protocol that transports Layer-2 data frames between two (2) endpoints inside UDP packets (OSI Layer-4). You can recognize VXLAN by its use of UDP over port 4789. VXLAN is documented in RFC 7348.
Footnotes
1 Assigned Internet Protocol Numbers. 13 October 2017. Internet Assigned Numbers Authority. https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml