Geode Cities

Rooms

Settings

Table of Contents

< Chapter 18

Chapter 19 - Secure Tunneling and VPNs

Tunneling on its own is fine. But what really gets people excited about tunneling isn't sending Ethernet frames over TCP packets, it's sending Ethernet frames or IP packets over encrypted transports like TLS. That is, "secure tunnels"

Regular tunneling can help you put things like access controls onto a system that does not normally support them. Secure tunneling takes it a step forward, allowing you to put encryption on a system that does not normally support it.

Imagine the same tunneling setup that let you password-protect your printer, because your printer does not support setting a password on it. Your particular printer also does not support IPPS (Internet Printing Protocol Secure) because in all honesty, basically no consumer printers actually support IPPS. If I want to send my sensitive document over the regular tunnel to your printer using IPP, both the password for the tunnel and the sensitive document page get sent in a way that can be intercepted.

Using a Secure Tunnel instead of a regular tunnel allows the password to be encrypted, and the sensitive document page to be encrypted. A bad actor at the coffee shop won't be able to see either, even though I'm still technically printing with the insecure IPP protocol.

This idea of a Secure Tunnel forms the "Privacy" part of a VPN (Virtual Private Network)

The other half of a VPN, the "Virtual Network" isn't all that complicated. When I connected by tunnel to Alisa's PC in order to bridge onto your Ethernet network, that Ethernet network was physical network with a physical Ethernet switch and other physically present Ethernet devices to talk to. On a virtual network, there is no real Ethernet network to bridge onto. Computers typically still send Ethernet frames on these virtual networks, but those frames are managed entirely by software and never make it to a real physical Ethernet network.

Traditionally, the VPN server is a program running on a company's Router. Clients will connect to the VPN by secure tunnel, and get attached to a virtual Ethernet switch. Then they can directly access other devices that are also connected to the VPN's virtual Ethernet network, or they can send IP packets that the router can route over to the Internet interface or the regular physical network interface.

So imagine you're on the Internet somewhere and you want to print something at the company you work at. You would make a secure tunnel to the VPN server running on your corporation's router, and you'd provide some ethernet MAC to talk on that network with. You'd be virtually attached to that Virtual Ethernet switch, meaning that when the VPN server decodes your encrypted packet and finds an ethernet frame, it forwards that ethernet frame to the virtual ethernet switch code.

The VPN Interface has an IP address (10.0.0.1) so it can be used as an Internet Protocol gateway, so you send your virtual Ethernet frame with your virtual MAC, your virtual IP address (let's say, 10.0.0.2), then the destination virtual MAC (CC:CC:CC:CC:CC:CC, discovered by ARPing the VPN Interface's IP address 10.0.0.1) and the destination IP address (15.23.44.2).

This corporate router would take the tunnel connection and have it get processed by the the VPN server software. Then the VPN server software would decrypt it, and forward the virtual Ethernet frame to the virtual Ethernet switch. Then the virtual Ethernet switch would forward the frame to the virtual VPN interface. The Ethernet frame goes away, and the VPN Interface routes the IP packet by determining that the LAN Interface is the one that handles 15.23.44.* IP addresses, so the VPN Interface code hands the IP packet to the LAN Interface code. Then the LAN Interface code encodes a new Ethernet frame for the physical Ethernet network where the destination MAC is 12:34:56:AB:CD:EF and the source is AA:AA:AA:AA:AA:AA

That set of three "IP Packet Link" arrows are commonly implemented by the Linux networking stack. When you create iptables rules, it's actually writing the rules of how IP Packets sent through those buffers should be managed.

The "Virtual VPN Interface", on Linux, is generally given interface identifier tunN (like tun0 for the first one configured on a system), so-called "tun" because it's implemented as a tunnel. In the diagram, the "VPN Server Software" and "Virtual Interface" are separate boxes, but really both of those and the virtual ethernet switch are typically implemented by a single software package.

Here you can see I have lo which is a virtual interface to handle traffic on the 127.* network, wlp1s0 which is my physical wifi interface, tailscale0 which is a virtual interface for my Tailscale VPN, lxcbr0 which is apparently for talking to lxc virtual networks, and tun0 which is my OpenVPN virtual interface

That brings us to the VPN services that get advertised on YouTube. These VPN services run servers like the corporate router pictured in the diagram, but generally they don't have any LAN interface. When you use something like NordVPN to secure "up to 6 devices" or whatever, it means you can open 6 tunnels at once to their VPN Server software to attach those devices to the virtual Ethernet switch. The devices connected to NordVPN can talk to each other (if the Virtual Ethernet Switch code allows it) as if they were connected to a physical ethernet network.

That's not the selling point of these services though. The selling point is that because this virtual Ethernet network has a routing interface with routes to the actual Internet, by connecting the tunnel into this virtual Ethernet network you can connect your computer to the Internet but from somewhere else. This achieves a similar effect to a Web Proxy despite that the mechanism is so different. When you use the Internet over that virtual Ethernet connection, over the secure tunnel, once your traffic emerges on the Internet it appears to have come from wherever NordVPN's data center is. Your computer gets an IP address assignment on its tun0 interface of an IP address which belongs to NordVPN. Your traffic no longer appears to be coming from your genuine physical location or your genuine location in IP address space. Assuming you successfully made the initial tunnel connection, you don't have to worry about any weird firewalls blocking access to things (like China's "great firewall"), and because the tunnel is secured you don't have to worry about the people in the internet cafe spying on you, or your ISP spying on you.

That said, you do still have to worry about:

The "governmental interference" part is where we start to circle back to why people use VPNs for tasks like media piracy. Under the standard connection model where you can pirate a movie, those piracy requests are tagged with your IP Address which your ISP knows is being used by you, but the media companies can only see that it belongs to the ISP. Government interference (a "court order") means the ISP can be forced to tell the media company that it was you who was using that address at the time the address made those piracy requests.

These VPN providers operate their servers in countries where they don't have to listen to the government of your own country. So, if the Warner Brothers media group gets the United States courts to issue an order to the Lithuanian NordVPN company that NordVPN must cooperate in catching the evil movie pirates using NordVPN IP addresses, NordVPN and the Lithuanian government pretty much tell the American courts to pound sand.

These companies usually do everything they can to not even keep any sort of connection or access logs, so that if they ever were compelled to provide information, they would not have any to provide. But then also some VPN providers claim they do this but in reality they do not, so it's important to contract with a reputable VPN company if you genuinely want to avoid spying.

Glossary >