How do VPN's forward network traffic? (Layer 3)

Question

I am looking for some info on how VPN's (Virtual Private Network) forward network traffic through its VPS (Virtual Private Server).

Take an example where you are connected to a VPN. You make a request to a website, which then makes its way down the network stack to Layer 3.

We have an IP packet - it has got its headers, including its destination address, and a payload.

If you change the destination address of the IP packet to the ip address of the VPS, how does the server forward the request to the original destination address?

The only thing I can think of is that at Layer 3 (the IP Layer), the header's destination address is changed to the ip address of the VPS, and then the original destination address is appended to the payload of the packet?

Does this not mean the length of the packet and the checksum header of the packet would then need to be recalculated and the IP packet again modified?

And then the VPS does the inverse mapping of the packet to assemble and make the original request on the server.

This seems like there would be a high latency time associated with it?

Perhaps I am missing some technical aspect of how this works, can anyone else explain it?

Answer 1

Take for example the GRE-Header (GRE is a protocol used to realize VPNs - its not often used as its not secure in any way, but the concept with encapsulation is nearly the same in every VPN connection (so also with IPsec for instance)):

As you can see, the original packet gets encapsulated into another IP-Packet.

Lets assume there are two networks/routers (A and B, a router can be a VPS) connected to each other via a VPN (site-to-site).

If a host on the network A wants to access a FTP-Server on Network B, the host in network A will send a packet, where the destination address is the IP-address of the FTP-Server and the source address is its own.

Then the original packet comes to the VPN-Gateway (probably his router), which encapsulates this original packet into for instance an IPv4-packet where the destination address is the VPN-Gateway (network B) and source address is its own. That way, the packet can travel over the internet to the other VPN-Gateway (network B). Here, the original protocol/header or packet type doesn't matter, as it will be encapsulated with an IPv4 header to travel over the internet and other routers won't care about the original protocol/header as they just see the "new" IPv4 header.

A new checksum for the "new" packet has to be calculated which gets appended, otherwise it wouldn't be able to travel over the internet (as for instance PPP is sometimes used between to points in the internet, which calculates a checksum). So there must be two checksums in the whole packet.

With IPsec (which is used nearly always for VPN connections), the original packet gets encrypted (mostly via AES) and a plain-text header (the "new" header to travel over the internet) is added. It must be plaintext so it can be routed properly. For that, a new checksum has to be calculated too (as the original checksum is encrypted).

When it has reached the other VPN-Gateway (network B), the VPN-Header is taken apart and the original packet is send into the network (to the FTP-Server).

Answer 2

So the short answer to your question is encapsulation. Meaning there is another set of packet headers put around the packet you are sending to a website that is taken off by the VPN endpoint.

Think of it this way:

-----------------------------------------------
| src_ip=2.2.2.2, dest_ip=3.3.3.3             |
|---------------------------------------------|
|| src_ip=10.10.10.10, dest_ip=5.5.5.5       ||
|| Data goes here. This could be a HTTP GET  ||
|| or pretty much anything.                  ||
|---------------------------------------------|
-----------------------------------------------

Your VPN client running on your local machine will give you a new IP address (10.10.10.10) and change your route table such that the default route is headed down the created tunnel. It will then send the traffic to the VPN server or in your example a VPS (3.3.3.3). Often your packet will have a NAT applied to it when it is de-encapsulated so to your destination server (5.5.5.5) it will appear the traffic is coming from the destination IP of the encapsulated traffic (3.3.3.3) This is how the traffic gets back to you by going to the VPN server first.

On to your third question. Since you are putting an additional packet essentially on the outside the length and the checksum are calculated on the resulting packet. So yes there are two lengths and two checksums. As for maximum length that is either done by the VPS saying use this MTU or through MTU discovery like normal.

As for latency. You can't break physics. You will account for your overhead of getting to the VPS and running through its network stack. While it may seem that there would be a high latency this is sometimes not the case. If your VPS is topologically in line with where the packet is already headed there may be minimal overhead added. For instance if you are in Seattle and your VPS is in New York and the website you are trying to talk to is in London. But if you are going from Seattle to New York to come back to a website in Seattle then there is additional latency from the trip across the United States.

Answer 3

A packet is created by the transport layer and passed down to the network layer. The host looks in it's routing table and sends it to the virtual interface created by the VPN software.

The VPN software takes the packet from the virtual interface. It may encrypt it or add it's own headers, it then passes it back to the network stack as a payload. Depending on the particular VPN implementation it may pass this payload to the transport layer or it may bypass the transport layer and go direct to the network layer.

Another layer of network layer headers are then added to the packet targetting towards the VPN server. The packet is then looked up again in the routing table and sent out onto the internet (if the VPN is a "full coverage" one then the VPN software must take care to set up the routing table in a way that VPN traffic goes out the real internet-facing interface rather than back to the VPN software).

When the encapsulated packet arrives at the VPN server it is passed back to the VPN software. The "outer" headers are removed and the packet is passed back to the network stack over a virtual interface.

After that it is up to the network stack on the VPN server what to do with it. In the case of a VPN used for internet access the network stack on the VPN server will likely be configured to act as a NAT router, so it modifies the source of the packet and sends it back out on to the Internet.

When the reply comes back much the same process happens. The packet comes in, the NAT process is reversed, it is passed back to the VPN software over the virtual interface, it is encapsulated and sent back to the VPN software on the client which deencapsulates it and passes it back to the network stack so it can be delieverd to the client application.