EMZETT.Tunnel
In short: A connection in which data packets of one protocol are packed (“encapsulated”) into another protocol and transported over it — e.g. to send data traffic through a network that wouldn’t otherwise let it through that way.
In more detail: Tunnelling encapsulates the actual data traffic in additional protocol headers, so that it looks like normal traffic of the carrier protocol. VPNs use this principle to route private network traffic encrypted over the public internet; SSH uses tunnelling to redirect any TCP connection (e.g. a database connection) securely over an existing SSH connection (“port forwarding”).
In Depth
Tunnelling works through encapsulation: the actual packet (including its own header) is packed completely as the payload into a new, outer packet of a carrier protocol. To all devices along the transmission path, only the outer header is visible — they simply transport the packet according to the carrier protocol, without knowing (or needing to know) what’s packed inside. Only at the other end of the tunnel is the outer header removed again and the original packet exposed.
A VPN uses exactly this principle to route, for example, a user’s entire internet traffic through an encrypted tunnel to a VPN server — to the user’s internet service provider, all that’s visible is that encrypted traffic is flowing to the VPN server, not what’s being transported in it or where the journey actually goes after that. SSH tunnelling (port forwarding) similarly allows a locally opened port to be redirected so that an application believes it’s talking to a local server, while the traffic actually goes encrypted to a remote computer — handy, for example, for securing a database that’s actually only meant to be reachable locally.