Many times, a VPN is described as an enchanted encrypted tunnel that “protects” your identity. However, these explanations are frequently inaccurate and highly abstract.
Although I’m not an expert in networking, I know enough to be able to describe what actually occurs behind the scenes when a VPN is enabled. I’m going to presume that since software developers are my target audience, I’m speaking to them.
This is a straightforward example using a web server to show you how VPN operates.
Assuming that your source IP address is 6.6.6.6, let’s imagine you wish to connect to Google (for example, IP 1.2.3.4) on port 80. I’m going to ignore NAT for simplicity because this is actually your public router IP rather than your private laptop IP.
In a typical scenario, in the absence of a VPN, your client transmits a SYN segment to port 80, which is then converted into an IP packet with a destination IP of 1.2.3.4 and a source IP of 6.6.6.6. Google then directly responds to you with a SYN/ACK destination IP of 6.6.6.6 and a source IP of 1.2.3.4 etc. The IP packet you are sending back and forth to 1.2.3.4 is visible to your ISP. They (the ISP and almost everyone in between) have the option to deeply examine it and view the information.
Let’s imagine you set up an UDP-based VPN and connect to a VPN server with IP 3.3.3.3. The VPN client intercepts the SYN IP packet that the client still generates, encrypts it, and repackages it into a new UDP datagram with VPN information. This new UDP packet has a destination IP address of 3.3.3.3 and a source IP address of 6.6.6.6.
Your ISP detects that you are traveling to 3.3.3.3 rather than 1.2.4.3.4 because the IP packet you are leaving your NIC is encrypted and encased in that outer packet. The VPN server receives the IP packet, unpacks it, decrypts it (requiring complicated logic to obtain the key, etc.), and then notices that, aha, this man wants to go to 1.2.3.4 and replaces the source IP with its own, creating a fresh IP packet (or reusing for zero copy). 3.3.3.3 to allow Google to receive the SYN.
In conclusion, the VPN merely passes the SYN through, allowing you to establish an end-to-end TCP connection with Google through this encrypted tunnel, rather than terminating the TCP.
Keep in mind that when you utilize TLS, the TLS client greeting is sent via the VPN to Google in the same manner as any other packet. Because of this, you also receive end-to-end encryption, and the VPN is unable to read HTTPS communication. That implies that when utilizing a VPN, you do accept the risk of double encryption and decryption.
Why use UDP for VPN instead of TCP? You can, but while the two congestion algorithms (outer and inner) compete, you risk a TCP meltdown.
