Computer networks use a tunneling protocol when one network protocol encapsulates a different
payload protocol.
By using tunneling one can carry a payload over an incompatible delivery-network, or
provide a secure path through an untrusted network.
Tunneling typically contrasts with a layered protocol model such as those of OSI or TCP/IP.
Typically, the delivery protocol operates at an equal or higher level in the model than
does the payload protocol.
To understand a particular protocol stack, network engineers must understand both the
payload and delivery protocol sets.
As an example of network layer over network layer, Generic Routing Encapsulation, a protocol
running over IP, 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 compatible, but the payload addresses
are incompatible with those of the delivery network.
In contrast, an IP payload might believe it sees a data link layer delivery when it is
carried inside the Layer 2 Tunneling Protocol, which appears to the payload mechanism as
a protocol of the data link layer.
L2TP, however, actually runs over the transport layer using User Datagram Protocol over IP.
The IP in the delivery protocol could run over any data-link protocol from IEEE 802.2
over IEEE 802.3 to the Point-to-Point Protocol over a dialup modem link.
Tunneling protocols may use data encryption to transport insecure payload protocols over
a public network, 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.
Secure Shell tunneling A Secure Shell tunnel consists of an encrypted
tunnel created through an SSH protocol connection.
Users may set up SSH tunnels to transfer unencrypted traffic over a network through an encrypted
channel.
For example, Microsoft Windows machines can share files using the Server Message Block
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.
To set up an SSH tunnel, one configures an SSH client to forward a specified local port
to a port on the remote machine.
Once the SSH tunnel has been established, the user can connect to the specified local
port to access the network service.
The local port need not have the same port number as the remote port.
SSH tunnels provide a means to bypass firewalls that prohibit certain Internet services –
so long as a site allows outgoing connections.
For example, an organization may prohibit a user from accessing Internet web pages directly
without passing through the organization's proxy filter.
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, they can create a 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 browser to the local port at http:localhost/
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 doesn't 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.
Tunneling to circumvent 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.
Another HTTP-based tunneling method uses the HTTP CONNECT method/command.
A client issues the HTTP CONNECT command to a 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.
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.
Examples Below is an example of how to set up an SSH
tunnel in OpenSSH.
See also
References
External links PortFusion distributed reverse / forward,
local forward proxy and tunneling solution for all TCP protocols
SSH VPN tunnel, see the SSH-BASED VIRTUAL PRIVATE NETWORKS section
BarbaTunnel Project - Free open source implementation of HTTP-Tunnel and UDP-Tunnel on Windows
This article is based on material taken from the Free On-line Dictionary of Computing prior
to 1 November 2008 and incorporated under the "relicensing" terms of the GFDL, version
1.3 or later.