Understanding Tunneling: Hiding Packets In Plain Sight
Tunneling, Burrowing, EnscapsulatingTunneling 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.
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.