Tunneling protocol

Computer networks use a tunneling protocol
when one network protocol (the delivery
protocol) encapsulates a different payload
protocol. By using tunneling one can (for
example) 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 (GRE), a
protocol running over IP (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 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
(L2TP), 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
(UDP) over IP. The IP in the delivery protocol
could run over any data-link protocol from
IEEE 802.2 over IEEE 802.3 (i.e., standards-
based Ethernet) to the Point-to-Point
Protocol (PPP) over a dialup modem link.
Tunneling protocols may use data encryption
to transport insecure payload protocols over
a public network (such as the Internet),
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[edit]
A Secure Shell (SSH) 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
(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.
Reverse ssh tunnel
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 (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,
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 a 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, one can use a "socksifier" to redirect
the application to the local SOCKS proxy
server. Some "socksifiers", such as Proxycap,
support SSH directly, thus avoiding the need
for a SSH client.