November 28, 2014
 
 
RSSRSS feed

Understanding Tunneling: Hiding Packets In Plain Sight - page 2

Tunneling, Burrowing, Enscapsulating

  • December 11, 2008
  • By Charlie Schluting

Figure 1.
(Click for a larger image)
As depicted in figure 1, the data portion of your IP packet contains an entirely new IP packet. This works the same way as VPN tunnels, excluding the encryption. When your packet has the "extra header" on top of it, you can't send as much data, because the first IP header uses up 20 bytes. This is important to realize, because of Path MTU issues that crop up when people use tunnels.

A wonderfully geeky thing to do is "fire up an ssh tunnel." This means that you're using the SSH protocol to pass data around, tunneled. X11, i.e. a program that runs a GUI and requires that you have a display available, can be tunneled over SSH very easily. X clients (the window that pops up) will try connecting to a display. If you're SSH'd into a server with the right options set, your X connection attempts will be tunneled back to your local machine, where they can connect with your local X server. This "just works" for Unix to Unix connections if you're already running a window manager. If you're in Windows-land, you'll need to run an X server via cygwin or some commercial product. Give it a try by SSH'ing to something with 'ssh ���Y user@hostname.com' and run 'firefox' once you're in. It should display on your local computer, and it did so over an encrypted SSH tunnel!

Because it's easy to talk about OpenSSH's capabilities, and it's instructive for tunneling concepts, let's take a look at two other tricks with SSH.

You can forward a port from your computer to a remote computer, which has the result of tunneling your data over SSH in the process, making it secure. This may not seem useful, after all, why would I want a port on my computer being forwarded to another computer? The answer lies within some clarification. The port forwarding function of SSH works by first listening on a local socket for a connection. When a connection is made, SSH will forward the entire connection onto the remote host and port. This is a one-port VPN!

For example: 'ssh -L80:workserver.com:80 user@workdesktop.com'
This command creates an SSH connection to your workdesktop.com computer, but at the same time opens port 80 on your local machine. If you point your web browser at http://localhost, the connection will actually be forwarded through your SSH connection to your desktop, and sent onto the workserver.com server, port 80. This is very useful for accessing intranet-only sites from home, without connecting to a VPN first.

The latest OpenSSH version also supports tunneling IP over SSH. Actually, it supports Ethernet too, for the purposes of bridging two Ethernet broadcast domains together; encrypted over SSH! OpenSSH's Tunnel option allows people to set up fully functioning SSH-VPN tunnels that will work anywhere SSH works. It creates the tunnel interfaces on both sides, and the only manual configuration necessary is to adjust the routing table. If you want all traffic destined for your work's network to be sent through the encrypted tunnel, you simply add a route for that network and point it through the tunnel interface that SSH created automatically. This is truly the most hassle-free VPN setup available.

Tunnels tunnel other protocols. Hopefully these examples have provided enough insight into tunneling to spark an interest in some, or at least demystify this technology for others. Happy encapsulating.

In a Nutshell
  • Tunnels are a mechanism used to send unsupported protocols across diverse networks.
  • Tunneled data, VPN or other, adds to the size of the packet, resulting in less data being sent per-packet.
  • Tunneling data over ssh is normally a per-application VPN, but the latest version of OpenSSH implements a full-blown hassle-free VPN.

When he's not writing for Enterprise Networking Planet or riding his motorcycle, Charlie Schluting is the Associate Director of Computing Infrastructure at Portland State University. Charlie also operates OmniTraining.net, and recently finished Network Ninja, a must-read for every network engineer.

Article courtesy of Enterprise Networking Planet

Sitemap | Contact Us