The computing world has become dependent on various types of tunneling. All remote access VPN connections use tunnels, and you’ll frequently hear the geeks talking about SSH tunnels. You can accomplish amazing things with tunnels, so sit back and relax while you enjoy a gentle introduction to tunneling and its uses. If you’re looking for IPSEC details, we’ll cover that in a future Networking 101.
A tunnel is a mechanism used to ship a foreign protocol across a network that normally wouldn’t support it. Tunneling protocols allow you to use, for example, IP to send another protocol in the “data” portion of the IP datagram. Most tunneling protocols operate at layer 4, which means they are implemented as a protocol that replaces something like TCP or UDP.
VPN tunnels allow remote clients to tunnel into our network. This supports the previous notion of tunnels being used for “unsupported protocols,” even though that may not be apparent. If we VPN into work to gain access to printers or file sharing, it’s probably because ports 139 and 445 (the Windows mating ports) are blocked from the outside. They are, in effect, unsupported TCP ports across our border routers. But if we allowed IPSEC or PPTP across the border, to known VPN servers, then everything “just works.”
Your packets destined for the Active Directory server’s port 445 will be hidden with the VPN packets. When they reach the VPN server, it will demux (de-multiplex, AKA disassemble) the packet and then forward it onto the internal network. When it hits the internal network, the packet’s source address is now the VPN server’s internal IP, so that responses can go back to the VPN server. Other than that, the packet is exactly as you intended it at this point. Upon receiving a response, the VPN server will encapsulate that packet by adding the VPN headers, and then ship it back to you out its external interface.
A few interesting things to note about the VPN tunnel are: once your data hits the internal network it’s already been unencrypted, and when your data is traversing the Internet there is extra “stuff” attached to the packet.
Unmentioned, but probably obvious, is that VPN protocols will also encrypt your data before transmission. It doesn’t matter for understanding tunneling, but it’s worth mentioning. Take notice that the encryption is not end-to-end, i.e. you and the server’s communication are not truly secure. Surely it’s secure from prying eyes between yourself and your work, but as soon as packets are shipped beyond the VPN server, they’re once again unencrypted.
To understand the second interesting point, let’s take a look at how basic IP encapsulation works. Conceptually, we’re going to nest packets. That is, the data portion of the outer IP packet is going to contain an entire IP packet itself. Neat, isn’t it? We’ve just described an IPIP tunnel: IP living in IP packets.
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 [email protected]’ 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 [email protected]’
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.