Virtual Private Networks

This article is Part 1 in a 3-part series on how Virtual Private Networks (VPNs) work. Part 1 delves into the nuances of VPNs at a high-level, scratching the surface on the inner workings of VPN services. Part 2 (VPN Protocols) dives deeper into VPN protocols (platforms) and their differences, and part 3 (VPN Encryption and Authentication) goes a bit deeper into encryption and cryptography, and how security concerns may influence your choice in VPN protocols and/or services.

A goal of this website is to make complex technologies easier to grasp without diluting the importance of nuances that distinguish products or methods from one another. VPN protocols are a good example of an important subject that is rarely explained well (if at all). Other that touting the myriad of protocols or services they support, most VPN provider and provider sevice reviews gloss over the subject as if merely mentioning keywords and names is sufficient to establish credibility. It's a subject that is rarely discussed in any meaningful detail, yet an end user or system administrator's choice can have a profound impact, whether they realize it or not.

If one places a high enough value on security, privacy, and data exchange integrity to consider a VPN in the first place, why not closely examine every aspect of the VPN that will ostensibly protect your values? Whether your goal is evading censorship, cirumventing geographic content restrictions, or simply protecting yourself from potential malicious third-party monitoring of your internet traffic, your choices in every aspect of selecting a VPN are critical to a successful outcome of your goals.

Terminology

First things, first. Let's clarify what some of the terms used in these articles mean.

• Protocol - A VPN Protocol is a technical methodology that defines the constructs of a VPN, such as secure key exchange and encryption methods. You may liken it to a service platform.
• Service - A VPN Service is an application that establishes and operates a VPN using one or more VPN protocols.
• Provider - A VPN Provider is an organization that provides one or more VPN services and makes them available to the public, potentially for a fee.

Overview

Topical articles on VPNs can quickly turn into very deep discussions. The intent of this article is to cover moderately technical topics on the practical use of VPNs by consumers, pro-sumer hobbyists, and SOHO users (Small Office/Home Office). As a starting point, I presume you already have an idea of what a VPN is. If not, you may want to first read the introductory article, What Is a VPN?

VPNs are just what their name sounds like: virtual networks. They create a connection between two remotely separate devices, forming a virtual network connection. VPNs should not be confused with Point-to-Point (P2P) connections, which are physical connections between two points. While a VPN does only involve two (2) end-points, it relies on any number of devices in between the two end-points to act as hubs and facilitate information transfers from one end-point to the other. VPNs use data encryption to disguise the information being transferred, making it impossible for third party devices to eavesdrop on the information in transit.

When trying to wrap your mind around how VPNs function, there are seven (7) important concepts:

1. Operating Modes
2. IP Address Types
3. Protocols
   • IKEv2
   • IPSEC
   • L2TP
   • OpenVPN (v2)
   • OpenVPN (v3)
   • PPTP
   • SSTP
   • WireGuard
4. Device Connections
5. NAT
6. Network Ports
7. Encryption

These subjects might be referred to in slightly different ways by different authors and/or the documentation in different VPN server software, but regardless of what you call them, the concepts are the same and most organizations use the same terms to refer to the same concepts. The most important factors of a VPN are the type of network traffic it is able to carry from point-to-point, how the VPN encrypts the contents of its transmissions, and how the VPN processes security credentials when it is established. Digging a little deeper, it's also helpful if you have some understanding of NAT and Network Ports. If you have at least a cursory grasp of them, you'll find it easier to understand how VPN connections work. I'll explain these concepts below, at a high level.

Operating Modes

VPNs have a few different operational modes:

• Tunneling
• Transport
• Bridge

Tunneling Mode (TUN)

The most common mode is called tunneling. If someone refers to a VPN without describing its mode, presume they are referring to a tunneling VPN. The term is derived from describing how the most common type of VPN emulates opening a tunnel between the device initiating the VPN connection - the client (sometimes referred to as the client server) - and the device accepting the VPN connection (the host, server, or host server). The so-called "tunnel" is a secure wrapper (often SSL). There's a bit more to it than that, but that's the gist of it.

Tunneling mode VPNs operate as a Network Layer device (OSI model layer 3).

Tunneling mode is usually abbreviated as type "TUN" and is the most common type of VPN. When you think of a typical VPN setup, it's using the TUN mode.

Transport Mode (TAP)

A less common VPN mode is the "transport" mode. Also known as "site-to-site," a transport mode VPN operates as a Data Link Layer device (OSI model layer 2). Transport VPNs transfer raw data between two (2) network segments or nodes. A transport mode VPN is about as close as a VPN can get to emulating a Point-to-Point (P2P) connection, which is a direct (physical) connection between two network points called nodes. P2P connections are normally only found in large telecommunications networks.

Why would you ever want to use a transport mode VPN? Since they operate on the Data Link Layer of networking, they are capable of transmitting any network protocol your device is capable of sending over Ethernet. This is particularly relevant when creating a Bridge, which is explained next.

Transport mode is normally abbreviated as "TAP."

Bridge Networks

A bridge network, or in this case a Bridge VPN is exactly what it sounds like: it creates a bridge between two (2) points. With most VPN services, a bridge uses the TAP (transport mode) described above. If you read or hear about a VPN bridge, just think of a transport mode VPN.

Bridge VPNs always run in the "TAP" mode.

Which VPN Mode Do I Need?

Viewing digital content, web surfing, logging into your office remotely, protecting your internet connections while traveling, etc., you'll be using a VPN tunnel (TUN). It's exceptionally rare for consumers to need a transport mode VPN (TAP). They are normally reserved for sophisticated site-to-site communications, such as joining two local networks that are separated geographically, or transferring raw ethernet traffic between two routers.

You cannot perform normal activities over a transport or bridge VPN (TAP), such as web surfing or watching movies. TAPs transfer raw data. They do not interpret it or wrap and unwrap it like TCP connections (the IP protocol used by 99% of consumer internet traffic).

Let's review what the different VPN modes are for:

• transport mode (also known as bridge mode)
  • Routes IP traffic, and encapsulates your network traffic at the networking transport layer
  • Operates on OSI model Layer 2 (Data Link Layer)
  • Can transport any Ethernet based traffic, including the use of custom frame sizes
• tunnel mode (also known as routing mode)
  • Acts as a virtual network adapter
  • Creates a so-called "tunnel" between the two devices at either end of the tunnel
  • Suitable for common networking protocols such as TCP and UDP

Classifying VPNs by IP Address Type

"Type" - when used in the context of VPN discussions - is the term most likely to cause confusion, so it's important to level-set the discussion before both parties get lost in the weeds. Type refers to whether a connection's IP address is static or dynamic.

Re-capping:

• A VPN server has two (2) IP addresses: an inbound connection and an outbound connection.
• The inbound connection is the IP address from which the VPN server accepts new connections (to establish a new VPN connection).
• The outbound connection is exposed to the Internet.
• Failure to clarify the context of a VPN discussion on whether a connection is incoming or outgoing can create a disconnect in discussions.
• When there is a vacuum of information about the direction of travel being discussed, presume the focus is on the outbound side of the connection (publicly visible IP address when connected to the VPN).

Protocols

Protocols are the backbone of VPNs. They act like a map that governs how a VPN will operate and most importantly, its data encryption and handshake methods and procedures. When you hear terms such as OpenVPN, L2TP, or IPSec, these are all VPN protocols. OpenVPN is the most popular and ubiquitous protocol for tunneling VPNs. You may also be familiar with SSL, TLS, and SSH, which are protocols commonly affiliated with other IP technologies, yet may also be used with a VPN (SSL and TLS are quite common).

Most articles on VPNs focus on the client side of the model, but a VPN actually follows a client-server model. Unless you are also running a VPN server, your primary focus will be the client side. The majority of users fall into this category, and hence the lack of articles discussing the server side of VPNs. If you subscribe to a VPN service (i.e. you're not running your own server), the most important thing you need to know about the provider's service is which protocols it supports. The client side has to use a protocol supported by the server. VPN service providers almost always support more than one protocol.

For an in-depth discussion of each protocol, see the related article, How VPNs Work - Part 2: VPN Protocols.

PPTP [Point-to-Point Tunneling Protocol]

An old protocol that is similar to L2TP. Originally designed to connect two (2) remote routers together, it is not a tunneling protocol. Developed by Microsoft in the 1990's. Now considered obsolete. Insecure (its encryption can be cracked) and should be avoided.

L2TP [Layer Two Tunneling Protocol]

An improved version of PPTP developed by Cisco Systems, Inc. TUNneling only. No encryption (yikes!) and no TAP function.

Generally frowned upon for most consumer/prosumer VPN client-side applications, due to its complex setup process and increased risk of security holes due to insecure configurations. To form a VPN, it must be paired with an encryption protocol (such as IPSec). The latest version is L2TPv3.

L2TP/IPsec

Discouraged, particularly for novice users, as mentioned in L2TP section (above). When used in conjunction with IPsec it is possible to create a VPN with L2TP, however they are notorious for security holes due to inadvertent mis-configuration by users. Proceed with caution or choose another protocol.

When used to create a VPN, L2TP/IPsec works in transport mode ONLY. It cannot be used in tunnel mode. IP packet authentication, integrity, and anti-replay services are NOT provided with this protocol.¹

SSTP [Secure Socket Tunneling Protocol]

Owned by Microsoft. Potentially viable option for basic usage and when security is not a concern, especially for Windows devices. Compatible with Windows, Linux, and Mac. Uses the deprecated Secure Socket Layer (SSL) 3.0 standard, and for this reason I generally recommend avoiding it. Better option than PPTP, but still bad. Look elsewhere. If you are truly dead set on a low-security tunnel or bridge where speed is a priority and you must have a VPN, consider L2TP (standalone) as a potential choice. However, I would generally discourage you from this approach.

IKE [Internet Key Exchange]

IKE (Internet Key Exchange) is a 2-phase tunneling protocol that establishes and handles the security association within an authentication suite, and requires pairing with an encryption standard, such as IPsec. It establishes a secure tunnel (Phase 1) and negotiates a security policy between the VPN's peers (Phase 2). IKE is not standalone solution. It must be paired with an authentication suite. The current version (IKEv2) uses IPsec as its authentication suite.

IKE is particularly useful in mobile applications as it supports a special protocol (MOBIKE) that is resistant to dropping the VPN connection due to network changes (e.g. switching between a cellular data connection and a WiFi connection). It is also highly resistant to dropping a VPN due to connection changes (e.g. roaming from cellular to WiFi or vice-versa). IKEv1 is deprecated and should be avoided.

IPsec [Internet Protocol Security]

IPsec is not a VPN protocol, but is mentioned here because it is commonly referenced during VPN protocol discussions. IPsec is a suite of security protocols often used in data encryption over a VPN. It is most frequently applied as part of a strategy employing IKE or L2TP.

OpenVPN v2

OpenVPN is the gold standard by which every other VPN protocol is measured. It is consistently recommended more than any other VPN protocol. Widely regarded as the most secure, robust, and fault tolerant VPN service, OpenVPN utilizes SSL (OpenSSL) and TLS certificates, and supports both TUN and TAP modes. It is also open source, regularly stress tested, and receives updates periodically (though infrequently). Its configuration process is of moderate complexity.

These traits makes it ideal for consumers and home/remote office users, and OpenVPN enjoys a wide range of compatibility with Linux, Windows, Mac, Android, iOS, OpenBSD, FreeBSD, NetBSD, and Solaris.

OpenVPN v3

Building on OpenVPN 2's foundation, OpenVPN v3 is experimental and is currently available in Linux, Windows, and Mac flavors only. Server-side functionality is not implemented yet (it currently works as client-side only), it is backwards compatible with OpenVPN v2. Built on C++, D-bus, and Python 3, OpenVPN v3 seeks to modernize the OpenVPN codebase.

Be wary of unofficial OpenVPN 3 code. There are multiple "OpenVPN v3" repositories. The official repository on GitHub is https://github.com/OpenVPN/openvpn3

WireGuard

WireGuard is a new VPN protocol receiving a lot of attention over the last few years. It should be considered experimental for the time being (translation: do not use), and is currently (late 2019) only offered by a handful of VPN service providers (and only on specific, limited servers).

WireGuard began as a side project built from the ground-up with the intention of addressing specific problem areas that have been a thorn-in-the-side for other protocols (especially OpenVPN and IPsec). However, in spite of its good intentions, WireGuard is no panacea. For example, it may only be used in an OSI Layer 3 mode (tunneling) and works with UDP only. It is also limited to Linux only, which while that's fine with me and this site, this obviously hampers adoption.

On the plus side, WireGuard utilizes a fresh perspective on encryption and authentication standards, eschewing the traditional approach of juggling numerous security protocols and cryptographic algorithms to maintain a wide range of support in exchange for a slim code base that focuses on a small number of the most modern cryptographic suites.

So far, WireGuard is a mixed bag of pluses and minuses, and to date it appears most of its negative attributes are the other side of the coin from its positive improvements. Is WireGuard robbing Peter to pay Paul? Time will tell.

WireGuard is explored in greater depth in the sister article, How VPNs Work - Part 2: VPN Protocols.

Device Connections: What's a "Connection?"

When a VPN service provider indicates a maximum number of simultaneous connections, what does that mean? What, exactly is a device connection?

A connection or device connection means a single TUN or TAP interface. Each virtual device interface requires one connection to a VPN server; a 1:1 relationship. Most VPN providers allow multiple simultaneous connections with a single account, making it important to understand the difference between a connection and an account.

Multiple Device Connections

It's important to make a distinction between devices and connections. It is a subtle difference, as most people are used to thinking of a device as a physical machine. In networking, that's not the case. Practically speaking, there is a 1:1 correlation between connections and virtual network interfaces (VNIs). This is a crucial concept to grasp because a connection is not the same thing as a device. For instance, on a Linux computer you can create multiple virtual VNIs, and each may be connected to the same VPN. Even though they all emanate from the same physical device (e.g. a server), each network interface is considered a separate connection.

Operating more than one (1) virtual network interface (VNI) on a single host device is an advanced topic requiring a solid understanding of network routing tables and knowledge of Split VPNs, or unexpected results will occur.

Nearly all VPN service licenses allow multiple simultaneous device connections. Normally, multiple connections are allowed to any of the provider's VPN servers, however some may limit your access geographically. It's wise to verify the policy of your VPN service provider.

Under Windows, OpenVPN only allows one (1) connection per device, while Linux has no such limit.

It's rare that you would ever have a need for multiple connections to the same VPN server, from the same device. A more common scenario is connecting multiple independent devices to the same VPN at the same time.

Examples

Let's say you want to connect the following devices to a VPN, using a single license:

1. Desktop computer at home
2. Laptop connected to a shared cellular-based WiFi hotspot
3. Mobile phone
4. Another laptop located in another country

So, how many VPN connections is that if they are all connected to the same VPN service provider, at the same time, using the same license? Four (4).

Now, take that same scenario, but presume everyone is behind the same router, the mobile phones are connected to the Internet via WiFi, and the WiFi router is behind your primary router. How many connections is that? If you're familiar with networking, you might be thinking one (1) is the answer, but you'd be wrong. It's still four (4) devices. Why? Each device is creating its own instance of a virtual network adapter.

So, what can you do if you are constrained because the maximum number of devices allowed by your VPN license is less than the number of devices you want to connect to it? The answer is: it depends. One option is to consolidate your connections as much as possible, by shifting the VNI from each device to a router, where a number of devices are on a network behind that router.

Slow VPN Connections? Don't Blame OpenVPN

OpenVPN is sometimes unfairly blamed for slow speed performance. When users point the finger at OpenVPN as the cause of slow throughput or lots of overhead, their comments are misguided. By definition, VPN services have some overhead that reduces throughput and thereby speed. It's reality. Part of the trade-off between security, privacy, and data integrity versus data throughput speed. You can't have your cake and eat it too. Furthermore, your connection speed is wholly dependent on all the devices your VPN relies upon to transfer data from Point A to Point B. This means every hop across the Internet - just like any other connection - impacts how quickly your data traverses the path from its source to destination.

OpenVPN can be very speedy and efficient. For example, I have experienced OpenVPN server connections with over 90% throughput compared with my non-VPN fixed wire speed. Certainly, other protocols are known to be quicker, but that often comes at the expense of reduced security or privacy. WireGuard is an up-and-coming competitor to OpenVPN that is garnering increasing positive public attention, however for the momemnt it remains experimental and unproven at scale.

There are multiple key factors in VPN speed (throughput). The first pertains to how expedient your device is at processing the encryption required based on the VPN protocol you're using. Beyond that, you are relying on the VPN server and the path your data travels back and forth between your device and your connection's ultimate destination. How well the VPN servers are tweaked, their proximity to your physical location, and how taxed the server happens to be when you are connecting to it all play a significant role in real speed. Other than location, these factors are under the auspice of the VPN service provider, and this is why you should pay close attention to reputable reviews and tests of VPN providers.

I strongly recommend reading the related article, Reviewing the VPN Reviewers, where I contrast and compare notable VPN review sites. I chose this approach instead of publishing my own VPN reviews because there are already plenty of VPN reviews on the Web. The problem is figuring out which ones are real reviews and which are marketing shills (hint: most are the latter). That article will guide you toward the best VPN review sites, which will in turn lay out the pros and cons of the most reliable VPN service providers, so you can make an informed decision. With over 350 VPN services around the world, this can appear to be a daunting task.

Take the time to apply yourself just a little bit, and you will find the majority of VPN service providers are junk. In fact, a good number of them are outright scams; an increasing threat discussed in another article, The Great Global VPN Swindle.

Consolidating Connections Behind a Router

Grouping VPN connections behind a router has the benefit of making multiple connections appear as one. The router uses Network Address Translation (NAT) to keep track of which network traffic belongs to which device behind the router. From the viewpoint of the VPN server, the router is the only device.

Getting this to work properly is often not a simple task. The router needs to know which devices should have their network traffic sent over the VPN connection, and which should not. Several different approaches may be taken:

• Most general: ALL internet traffic exiting the router is sent to the VPN.
• Certain traffic: Only specified internet traffic types (from all devices behind the router) are sent to the VPN server.
• Certain devices: All internet traffic is sent to the VPN, but for specified host devices only.
• Most limited: Only specified network traffic, from specified host devices is sent to the VPN.

The simplest solution is a blanket policy routing all traffic to the VPN server, from where it will be sent out over the Internet. This has the benefit of hiding all your internet traffic behind the IP address assigned by the VPN. However, it comes at a cost: reduced speed and higher latency. This approach requires an intermediate level of networking knowledge.

Next, routing only certain types of network traffic to the VPN. This may be accomplished in different ways, depending on the sophistication of the router. However, for the most part this means forwarding specified ports to the VPN, while all others are sent over the normal ISP connection. This process will require an intermediate level of understanding of network concepts, at a minimum. If the router supports advanced packet inspection techniques, it may be possible to create more sophisticated policies if the network administrator has the appropriate expertise.

Routing only specified devices is easier. Simply branch devices to the VPN that match a list of internal (local network) IP addresses or match by host MAC ID.

At the most complex end of the spectrum is routing only certain traffic from specific hosts. This requires advanced networking experience. It is a combination of the aforementioned less restrictive concepts, but involves creating a Split VPN on the router itself. Specified traffic is routed through the VPN, and other traffic is routed through the router's normal internet connection. This results in traffic emanating through the VPN server having one public IP address, and the traffic emanating through the normal (ISP assigned) internet connection receiving another (ISP assigned) public facing IP address. The traffic can be split any way you like, so long as care is taken to ensure the full routing table is setup correctly such that no traffic is orphaned or represented by duplicate routes. The advantage of this approach is traffic types where speed is paramount may be routed throught the faster ISP connection, while traffic that needs a higher level of security or privacy gets routed through the VPN.

NAT

Network Address Translation (NAT) is a method of mapping one IP address to another, when the source and destination address are in different subnetworks.

NAT is what allows network traffic to be translated back and forth to the correct source and destination IP addresses on either side of a router. The router acts as a bridge that translates traffic between two or more independent networks, such as Local Area Networks (LANs), Wide Area Networks (WANs), and/or the Internet. NAT allows a router to receive incoming network traffic and route it to the appropriate host device on the Local Area Network (LAN) side of the router. NAT is what makes all your devices behind a router appear to be emanating from the same IP address, while packets returning to those devices get sent to the correct device on the local network.

Not all VPNs support NAT across the VPN. When they do, it's a feature called NAT Traversal or NAT-T. Why does this matter? If you're just connecting a single device to the Internet via a VPN, such as using a third-party VPN service provider for privacy, anonymity, or similar reasons then it's not something you need to worry about. However, if you are creating a VPN to connect two networks together that are remote from one another, you should make sure you pay attention to NAT-T. Another way of looking at it is if you'd like your VPN to share connections between more than one device on either end of the VPN, your VPN will need to use a protocol that supports NAT-T.

Network Ports

Network ports (or ports) are sort of like NAT, but at the host (computer) level. They are connections between two network devices (local or remote). When a port is "opened" it means it is allowing a communication with another device, via the opened network port number. There are 65,536 possible ports, numbered 0-65535.

Ports can somewhat restrict a device's connection abilities. Most applications can use any port number, but some require a specific port number. If a port is already in use, it can't be used by another process. For example, OpenVPN uses port 1194. When an OpenVPN connection is opened with a remote VPN server, port 1194 on the host device (your local device) is held open. This is why Windows can only connect to one VPN provider and via one VPN program at a time. Linux, on the other hand, segments its network connections by a combination of factors, including port number and interface. Thus, on Linux you may have multiple port 1194 openings, as long as they are on different network devices (e.g. different virtual network adapters).

The reason I'm explaining all this? There is one more interesting scenario: When a single host device can establish multiple connections on its own, without a router. That is an option with some VPN solutions. Specifically, VPNs that support multiple simultaneous connections, such as the Linux version of OpenVPN.

Encryption: Smoke and Mirrors

A high-level discussion of encryption layers in VPNs.

A VPN protects data traveling between peers by wrapping it in an encryption layer often referred to colloquially as a "tunnel." But, there's more to it than that. Many VPNs are also capable of acting as a proxy server and concealing the true origin of a connection by masking its identity and location. To other devices on the Internet, the connection appears to originate from the VPN server and not where the original device is actually physically located. This is obviously a big plus from a privacy perspective, but what about security and data integrity?

Focusing on third-party VPN service providers in particular, doesn't that mean the provider's VPN server will be reading one's data? Theoretically, no. At least it shouldn't be. You have read, Choosing the Right VPN Provider before signing up for a VPN service, haven't you???

Let's walk through a high-level overview of the data protection process provided by VPNs.

Recall that a VPN wraps your data packets in its own encryption and gets "unwrapped" when it arrives on the other side of the VPN "tunnel." Regardless of whatever form your data was in before being handed to the VPN, it must be restored to its prior state when it reaches the other end of the connection. A VPN acts like any other network adapter. It transmits and receives data via Internet Protocol (IP) network packets. Contained within each network packet is a source and destination address, just like any other normal IP packet. Those are the true source address of your device and the destination device address.

The "wrapped" transmission sent via the VPN tunnel has a destination address equal to the VPN server. Meanwhile, inside the tunnel is the real data (sometimes referred to as the payload, data payload, or packet payload). When the payload is extracted (unwrapped) at the VPN server, the source IP address of your device and the real destination of the server you want that data sent to are also extracted at the same time. The source IP address of the data payload packet is changed to the IP address of the VPN server, and then the payload is transmitted to the real destination device. To the destination device, it appears your location is the VPN server. When a reply is received, the VPN server looks up its record of your true IP address and the process above is reversed. The return reply is sent to your real IP address, and when you receive it appears to emanate from the destination device's IP address. At the application level, your device is unaware of the existence of the VPN server (i.e. your connection looks the same as a non-VPN connection to any application serviced by the VPN).

Let me go over that again and reiterate. Each data packet your device sends to the VPN server contains the source address of your device and the destination address of the VPN server. That's how your data gets routed through the VPN server; by first being sent to the VPN server. During that process, the VPN wraps or encrypts your data (regardless of whether it was already encrypted or not). The VPN server then decrypts the encryption it applied, to peel back the layers of the underlying data packet. What does it find? Your device's source address (where it just received the data packet from), the true destination device IP address (where you're trying to send the data to in the first place), and the real data itself.

The VPN server then takes your original data packet - in whatever form you sent it (e.g. encrypted in its own right, or not) - and repackages that in the form of a normal data packet. This time, the data packet gets sent to the real destination. The source device address on this leg of the data packet's journey is that of the VPN server, and the original (true) destination device address becomes the data packet's destination. The data is sent on its way. To any device in between - up to and including the destination device - this looks like a normal data packet. At this point if your data packet was not originally encrypted then it won't be here either, and vice-versa.

Either way, to any device other than yours and the VPN server, the data exchange appears to be between the VPN server and the destination device. No one can tell the transmission actually originated from your source device address and the VPN server is a proxy. There is no way for anyone but the VPN server to know that. This is the beauty - and benefit - of using a VPN.

The encryption and decryption processes discussed above are exclusive of any application generating data. If underlying data is also encrypted by an application before hand-off off to the VPN, the data will still be encrypted when reaching a corresponding application on the destination device.

At the application layer, your source device is oblivious to the VPN and VPN server; to it, the VPN is simply a network interface. Applications on the source device have no idea the VPN exists.

Double Wrapping (Dual Encryption)

When your data is already encrypted to begin with (such as HTTPS traffic), the result is sometimes called "double wrapping" or "dual encryption," which simply means your data has been encrypted twice. Normally, there isn't any particular benefit to your data being encrypted twice, but it won't hurt anything either. While it may slow your connection a bit due to the constant packaging and repackaging processes, it will work and is more secure than sending non-encrypted data through a VPN tunnel. Furthermore, it does provides an additional layer of data security. In the event your VPN were to leak data outside of the tunnel (i.e. VPN tunnel encryption fails or is compromised), the fact your original data is encrypted to begin with makes it nearly impossible for a malicious actor to derive anything useful from it.

Footnotes