View source for Tunneling protocol

{{short description|Computer communications protocol}}
{{IPstack}}
In [[computer network]]s, a '''tunneling protocol''' is a [[communication protocol]] which allows for the movement of data from one network to another. They can, for example, allow [[private network]] communications to be sent across a public network (such as the [[Internet]]), or for one network protocol to be carried over an incompatible network, through a process called [[Encapsulation (networking)|encapsulation]].

Because tunneling involves repackaging the traffic data into a different form, perhaps with [[encryption]] as standard, it can hide the nature of the traffic that is run through a tunnel.

Tunneling protocols work by using the data portion of a [[Network packet|packet]] (the [[Payload (computing)|payload]]) to carry the packets that actually provide the service. Tunneling uses a layered protocol model such as those of the [[Open Systems Interconnection|OSI]] or [[TCP/IP]] protocol suite, but usually violates the layering when using the payload to carry a service not normally provided by the network. Typically, the delivery protocol operates at an equal or higher level in the layered model than the payload protocol.

== Uses ==
A tunneling protocol may, for example, allow a foreign protocol to run over a network that does not support that particular protocol, such as running [[IPv6]] over [[IPv4]].

Another important use is to provide services that are impractical or unsafe to be offered using only the underlying network services, such as providing a corporate [[network address]] to a remote user whose physical network address is not part of the corporate network.

=== Circumventing firewall policy ===
Users can also use tunneling to "sneak through" a firewall, using a protocol that the firewall would normally block, but "wrapped" inside a protocol that the firewall does not block, such as [[HTTP]].  If the firewall policy does not specifically exclude this kind of "wrapping", this trick can function to get around the intended firewall policy (or any set of interlocked firewall policies).

Another HTTP-based tunneling method uses the [[HTTP tunnel#HTTP CONNECT method|HTTP CONNECT method/command]]. A client issues the HTTP CONNECT command to an HTTP proxy.  The proxy then makes a TCP connection to a particular server:port, and relays data between that server:port and the client connection.<ref>{{cite web|url=http://www.ietf.org/rfc/rfc2817.txt|title=Upgrading to TLS Within HTTP/1.1|date=2000|work=RFC 2817|access-date=March 20, 2013}}</ref> Because this creates a security hole, CONNECT-capable HTTP proxies commonly restrict access to the CONNECT method.  The proxy allows connections only to specific ports, such as 443 for HTTPS.<ref>{{cite web|url=http://www.kb.cert.org/vuls/id/150227|title=Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections|date=2002-05-17|publisher=[[CERT Coordination Center|US-CERT]]|access-date=2007-05-10}}</ref>

Other tunneling methods able to bypass network firewalls make use of different protocols such as [[DNS]],<ref name="tunneling_dns">Raman, D., Sutter, B. D., Coppens, B., Volckaert, S., Bosschere, K. D., Danhieux, P., & Buggenhout, E. V. (2012, November). DNS tunneling for network penetration. In International Conference on Information Security and Cryptology (pp. 65-77). Springer, Berlin, Heidelberg.</ref> [[MQTT]],<ref name="tunneling_mqtt">Vaccari, I., Narteni, S., Aiello, M., Mongelli, M., & Cambiaso, E. (2021). Exploiting Internet of Things Protocols for Malicious Data Exfiltration Activities. IEEE Access, 9, 104261-104280.</ref> [[SMS]].<ref name="tunneling_sms">Narteni, S., Vaccari, I., Mongelli, M., Aiello, M., & Cambiaso, E. (2021). Evaluating the possibility to perpetrate tunnelling attacks exploiting shortmessage-service. Journal of Internet Services and Information Security, 11, 30-46.</ref>

== Technical overview ==
As an example of network layer over network layer, [[Generic Routing Encapsulation]] (GRE), a protocol running over IP ([[List of IP protocol numbers|IP protocol number]] 47), often serves to carry IP packets, with RFC 1918 private addresses, over the Internet using delivery packets with public IP addresses. In this case, the delivery and payload protocols are the same, but the payload addresses are incompatible with those of the delivery network.

It is also possible to establish a connection using the data link layer. The [[Layer 2 Tunneling Protocol]] (L2TP) allows the transmission of [[Frame (networking)|frames]] between two nodes. A tunnel is not encrypted by default: the [[TCP/IP]] protocol chosen determines the level of security.

[[Secure Shell|SSH]] uses port 22 to enable data encryption of payloads being transmitted over a public network (such as the Internet) connection, thereby providing [[VPN]] functionality. [[IPsec]] has an end-to-end Transport Mode, but can also operate in a tunneling mode through a trusted security gateway.

To understand a particular protocol stack imposed by tunneling, network engineers must understand both the payload and delivery protocol sets.

== Common tunneling protocols ==
* [[IP in IP]] (IP protocol 4): IP in IPv4/IPv6
* [[6in4|SIT/IPv6]] (IP protocol 41): IPv6 in IPv4/IPv6
* [[Generic Routing Encapsulation|GRE]] (IP protocol 47): Generic Routing Encapsulation
* [[OpenVPN]] (UDP port 1194)
* [[Secure Socket Tunneling Protocol|SSTP]] (TCP port 443): Secure Socket Tunneling Protocol
* [[IPSec]] (IP protocols 50 and 51): Internet Protocol Security
* [[Layer 2 Tunneling Protocol|L2TP]] (UDP port 1701): Layer 2 Tunneling Protocol
* [[L2TPv3]] (IP protocol 115): Layer 2 Tunneling Protocol version 3
* [[Virtual Extensible LAN|VXLAN]] (UDP port 4789): Virtual Extensible Local Area Network
* [[Point-to-Point Tunneling Protocol|PPTP]] (TCP port 1723 for control, [[Generic Routing Encapsulation|GRE]] for data): Point-to-Point Tunneling Protocol
* [[Point-to-Point Protocol over Ethernet|PPPoE]] (EtherType 0x8863 for control, 0x8864 for data): Point-to-Point Protocol over Ethernet
* [[Generic Network Virtualization Encapsulation|GENEVE]]
* [[WireGuard]] (UDP dynamic port)

== {{Anchor|TCP meltdown}}TCP meltdown problem ==
{{expand-section|date=September 2024}}
Tunneling a TCP-''encapsulating'' payload (such as [[Point-to-Point Protocol|PPP]]) over a TCP-based connection (such as SSH's port forwarding) is known as "TCP-over-TCP", and doing so can induce a dramatic loss in transmission performance — known as the ''TCP meltdown problem''<ref>{{cite web
| url=http://sites.inka.de/bigred/devel/tcp-tcp.html
| title=Why TCP Over TCP Is A Bad Idea
| first=Olaf
| last=Titz
| date=2001-04-23
| archive-url=https://web.archive.org/web/20220103191127/http://sites.inka.de/bigred/devel/tcp-tcp.html
| access-date=2023-01-03| archive-date=2022-01-03
}}</ref><ref>{{cite conference
| bibcode=2005SPIE.6011..138H
| title=Understanding TCP over TCP: effects of TCP tunneling on end-to-end throughput and latency
|author1=Honda, Osamu |author2=Ohsaki, Hiroyuki |author3=Imase, Makoto |author4=Ishizuka, Mika |author5=Murayama, Junichi | s2cid=8945952
|book-title=Performance, Quality of Service, and Control of Next-Generation Communication and Sensor Networks III
| volume=6011
| date=October 2005
| doi=10.1117/12.630496
| citeseerx=10.1.1.78.5815
| editor1-last=Atiquzzaman
| editor1-first=Mohammed
| editor2-last=Balandin
| editor2-first=Sergey I
}}</ref> which is why [[virtual private network]] (VPN) software may instead use a protocol simpler than TCP for the tunnel connection. TCP meltdown occurs when a TCP connection is stacked on top of another. The underlying layer may detect a problem and attempt to compensate, and the layer above it then overcompensates because of that, and this overcompensation causes said delays and degraded transmission performance.

== {{Anchor|SSH}}Secure Shell tunneling ==
A ''[[Secure Shell]] (SSH) tunnel'' consists of an encrypted tunnel created through an [[Secure Shell|SSH protocol]] connection. Users may set up SSH tunnels to transfer [[unencrypted]] traffic over a network through an [[encrypted]] channel.  It is a software-based approach to network security and the result is transparent encryption.<ref>{{Cite book|last1=Barrett|first1=Daniel J.|url=https://books.google.com/books?id=JFa5aLIII6oC&q=secure+shell+tunneling+protocol&pg=PP11|title=SSH, the Secure Shell: The Definitive Guide|last2=Barrett|first2=Daniel J.|last3=Silverman|first3=Richard E.|last4=Silverman|first4=Richard|date=2001|publisher="O'Reilly Media, Inc."|isbn=978-0-596-00011-0|language=en}}</ref>

For example, Microsoft Windows machines can share files using the [[Server Message Block]] (SMB) protocol, a non-encrypted protocol. If one were to mount a Microsoft Windows file-system remotely through the Internet, someone snooping on the connection could see transferred files. To mount the Windows file-system securely, one can establish a SSH tunnel that routes all SMB traffic to the remote fileserver through an encrypted channel. Even though the SMB protocol itself contains no encryption, the encrypted SSH channel through which it travels offers security.

{{multiple image
 | total_width = 420
 | image1      = Ssh-L-Tunnel.png
 | image2      = SSH Tunnel (remote).png
 | footer      = Local and remote port forwarding with ssh executed on the blue computer.
}}
Once an SSH connection has been established, the tunnel starts with SSH listening to a port on the {{colorbox|lightgreen}}{{nbsp}}remote or local host. Any connections to it are forwarded to the specified {{colorbox|violet}}{{nbsp}}address and port originating from the {{colorbox|orange}}{{nbsp}}opposing (remote or local, as previously) host.

The [[#TCP meltdown problem|TCP meltdown problem]] is often not a problem when using OpenSSH's port forwarding, because many use cases do not entail TCP-over-TCP tunneling; the meltdown is avoided because the OpenSSH client processes the local, client-side TCP connection in order to get to the actual payload that is being sent, and then sends that payload directly through the tunnel's own TCP connection to the server side, where the OpenSSH server similarly "unwraps" the payload in order to "wrap" it up again for routing to its final destination.<ref>{{cite mailing list
| title=Re: Extensions for long fat networks?
| date=2003-06-13
| first=Dan
| last=Kaminsky
| author-link=Dan Kaminsky
| mailing-list=openssh-unix-dev@mindrot.org
| url=https://marc.info/?l=openssh-unix-dev&m=105554033415532
| quote=the TCP forwarding code is pretty speedy as well.  Just to pre-answer a question, ssh decapsulates and re-encapsulates TCP, so you don't have classic TCP-over-TCP issues.}}</ref> Naturally, this wrapping and unwrapping also occurs in the reverse direction of the bidirectional tunnel.

SSH tunnels provide a means to bypass [[firewall (computing)|firewall]]s that prohibit certain Internet services{{snd}} so long as a site allows outgoing connections. For example, an organization may prohibit a user from accessing Internet web pages (port 80) directly without passing through the organization's [[proxy filter]] (which provides the organization with a means of monitoring and controlling what the user sees through the web). But users may not wish to have their web traffic monitored or blocked by the organization's proxy filter. If users can connect to an external SSH [[Server (computing)|server]], they can create an SSH tunnel to forward a given port on their local machine to port 80 on a remote web server. To access the remote web server, users would point their [[web browser|browser]] to the local port at <nowiki>http://localhost/</nowiki>

Some SSH clients support dynamic [[port forwarding]] that allows the user to create a [[SOCKS]] 4/5 proxy. In this case users can configure their applications to use their local SOCKS proxy server. This gives more flexibility than creating an SSH tunnel to a single port as previously described. SOCKS can free the user from the limitations of connecting only to a predefined remote port and server. If an application does not support SOCKS, a proxifier can be used to redirect the application to the local SOCKS proxy server. Some proxifiers, such as Proxycap, support SSH directly, thus avoiding the need for an SSH client.

In recent versions of OpenSSH it is even allowed to create [[TUN/TAP|layer 2 or layer 3 tunnels]] if both ends have enabled such tunneling capabilities. This creates <code>tun</code> (layer 3, default) or <code>tap</code> (layer 2) virtual interfaces on both ends of the connection. This allows normal network management and routing to be used, and when used on routers, the traffic for an entire subnetwork can be tunneled. A pair of <code>tap</code> virtual interfaces function like an Ethernet cable connecting both ends of the connection and can join kernel bridges.

== Cyberattacks based on tunneling ==
Over the years, tunneling and [[encapsulation (networking)|data encapsulation]] in general have been frequently adopted for malicious reasons, in order to maliciously communicate outside of a protected network.

In this context, known tunnels involve protocols such as [[HTTP]],<ref>Pack, D. J., Streilein, W., Webster, S., & Cunningham, R. (2002). Detecting HTTP tunneling activities. MASSACHUSETTS INST OF TECH LEXINGTON LINCOLN LAB.</ref> [[SSH]],<ref>Dang, F., Li, Z., Liu, Y., Zhai, E., Chen, Q. A., Xu, T., ... & Yang, J. (2019, June). Understanding fileless attacks on linux-based iot devices with honeycloud. In Proceedings of the 17th Annual International Conference on Mobile Systems, Applications, and Services (pp. 482–493).</ref> [[DNS]],<ref>Raman, D., Sutter, B. D., Coppens, B., Volckaert, S., Bosschere, K. D., Danhieux, P., & Buggenhout, E. V. (2012, November). DNS tunneling for network penetration. In International Conference on Information Security and Cryptology (pp. 65-77). Springer, Berlin, Heidelberg.</ref><ref>Aiello, M., Mongelli, M., Cambiaso, E., & Papaleo, G. (2016). Profiling DNS tunneling attacks with PCA and mutual information. Logic Journal of the IGPL, 24(6), 957-970.</ref> [[MQTT]].<ref>Vaccari, I., Narteni, S., Aiello, M., Mongelli, M., & Cambiaso, E. (2021). Exploiting Internet of Things Protocols for Malicious Data Exfiltration Activities. IEEE Access, 9, 104261-104280.</ref>

== See also ==
* [[GPRS Tunnelling Protocol]] (GTP)
* [[HTTP tunnel]]
* [[ICMP tunnel]]
* [[NVGRE]]
* [[OSI model]] (Diagram)
* [[Pseudo-wire]]
* [[Stunnel]]
* [[Tunnel broker]]
* [[Virtual Extensible LAN]] (VXLAN)
* [[Virtual private network]] (VPN)

== References ==
{{Reflist}}

== External links ==
* [http://portfusion.sourceforge.net PortFusion] distributed reverse / forward, local forward proxy and tunneling solution for all TCP protocols
* [http://www.freebsd.org/cgi/man.cgi?query=ssh SSH VPN tunnel, see the SSH-BASED VIRTUAL PRIVATE NETWORKS section]
* [https://github.com/BarbaTunnelCoder/BarbaTunnel BarbaTunnel Project - Free open source implementation of HTTP-Tunnel and UDP-Tunnel on Windows]
* [https://github.com/vpnhood/VpnHood VpnHood Project - Free open source implementation of a VPN using socket redirection]

[[Category:Tunneling protocols| ]]
[[Category:Network protocols]]
[[Category:Cybersecurity engineering]]