Understanding Tunneling: Hiding Packets In Plain Sight

Tunneling, Burrowing, Enscapsulating

Tunneling over untrusted networks is a flexible, powerful security tool. We continue our classic Networking 101 series with Charlie Schluting's gentle introduction to how they work, and some easy-to-try examples with SSH.

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.

More Networking 101 IP Addresses Subnets and CIDR Subnets Layers the Data Link Layer Spanning Tree ICMP The Internet Protocol TCP, the Protocol TCP In More Depth Internet Governance Routing RIP Routing OSPF Routing OSPF Routing (Part 2) Internet Routing and Peering BGP Routing Multicast Routing

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.