Good one, I couldn't connect to it using windows VPN connection, so I guess they will presetup all the confif in the client app. You might have to do a bit of digging around to find the setup details and get it working with windows
The VPN options in most OSes are based on the IPSec protocol. IPSec is a fairly comprehensive VPN protocol, but requires quite some time and skills to set it up properly. And the "easier" solutions are often commercial ones, which are fairly expensive. In addition some OS vendors, like Microsoft, also includes their own VPN alternatives as options.
OpenVPN uses its own protocol, and is thus not compatible with other VPN protocols. This is by design, to avoid implementing lots of features not strictly needed for the task OpenVPN tries to solve.
On the other hand, OpenVPN is an open source product, with the first release in 2001 [1]. Since then, OpenVPN has been through two security audits [2][3] which it passed with quite few findings. And the critical ones where fixed quickly after [4].
On top of this, a Dutch security company, Fox-IT, has also worked with the Dutch government to deliver a certified OpenVPN solution to be used for data transfer up to the RESTRICTED security level [5] (Going higher than this usually means deploying dedicated VPN hardware). The OpenVPN-NL version is shipping with mbed TLS instead of OpenSSL, where both mbed TLS and OpenVPN has been another round of security audit.
So OpenVPN has proven over time to be a fairly solid and secure VPN solution, with not an enormous amount of security issues [6] over these years.
I hope you won't mind another question that's been in my head for a decade:
Can a PPTP/L2TP VPN or OpenVPN bypass the (speed limit or throttling or data cap) by ISP?
I mean it encrypts the whole internet package, right? does that include stuff like the size of the package?
I actually tried to setup VPNs for many clients, but their internet experience (speed and capping) didn't change... maybe I didn't do the right setup or maybe it's not possible.
No, you cannot use VPN to circumvent neither traffic throttling or data quotas. The encrypted VPN traffic is also network traffic passing over the Internet.
Some ISPs may have some quotas or throttling on specific services, but you will most like see them doing the reverse in reality - they throttle or have quotas on all the Internet traffic except for selected services they provide with lesser restrictions. And since they most likely won't provide lesser restrictions on VPN services, you can't use VPNs to avoid this.
VPNs may be used to to circumvent blocks to services imposed by ISPs, as they can't see what you use the VPN for. For example, using the Private Tunnel service in China for example, can give you access to a more open Internet.
Just realized, this can use a bit more explanation:
I mean it encrypts the whole internet package, right? does that include stuff like the size of the package?
Yes, VPNs encrypt the data being passed between the VPN client and server. But it doesn't make the size of the content "disappear".
So, say you want to download a file of 2MiB. All networks have a restriction of how large each network packet can be. This various slightly, but a very common value is 1500 bytes (this is a fairly comprehensive topic, but MTU and Ethernet frames are keyword). Each packet includes both MAC and IP headers (for TCP/IP traffic), and inside IP headers are your local IP address as well as the destination IP address found. And then comes the payload (the data you want to transfer). But due to this restriction, and the packet header information you have less than 1500 bytes per packet available when trying to transfer this 2MiB file. So what happens is that this large transfer is (automatically) chopped up into smaller pieces, fitting into the maximum capacity you can use. On the receiving side, all these fragments are then assembled and saved to a single file again.
When you add VPN into this mix, the VPN interface will receive a stream of packets, as described above. It will then encrypt each of these packets individually (hiding the contents) and then it will be sent further to the VPN host, which means another set of packet headers (which cannot be encrypted) together with the encrypted payload. The receiving side will then decrypt the payload and pass that to its local VPN interface again, containing the packet headers the sending side used.
What this means is that VPN will give an additional overhead and the effect of the available maximum size for the payload will be further reduced. Again, this is quite a complex topic, as there are approaches to try to avoid too much fragmentation on the VPN packets. But the effect is regardless that VPN in practice reduces the overall "transfer capacity" per network packet.
This means you will in almost all cases spend more data transferring packets passed over the VPN. To illustrate this, here's a (reordered) statistic of a VPN session on my computer. Here are both the packet and byte counters for traffic being sent to the VPN interface (TUN_BYTES_IN/TUN_PACKETS_IN). They are encrypted and sent out to the insecure Internet (BYTES_OUT/PACKETS_OUT)
What you see here is that more data is being sent to the VPN server than was received on the VPN interface. This is because encrypted network packets bigger and need additional splitting.
And for the traffice being sent from the VPN server to my client. BYTES_IN/PACKETS_IN is the encrypted data coming from the VPN server. TUN_BYTES_OUT/TUN_PACKETS_OUT is the decrypted data being sent to the VPN interface.
When receiving encrypted data from the VPN server, we see the reverse effect. We send less data/packets to the VPN interface, because decrypting the packets reduces the size.
And then you might wonder about compression. Compression is an alternative which may be used to reduce this overhead - when the traffic is compressible. But first of all, compression will reduce the security of the VPN tunnel. In addition a lot of the data being transported is already fairly compressed (like .mp3/.avi/.jpg files) or not suitable to compress (like https traffic) - both these cases will not result in much compression effect. So it is not recommended to use compression at all.
So to sum it up: VPNs will not hide the size of the data being transported. The effect will be that you use more data when using VPNs.
Good one, I couldn't connect to it using windows VPN connection, so I guess they will presetup all the confif in the client app. You might have to do a bit of digging around to find the setup details and get it working with windows
Actually, I did that for a client long ago (setup OpenVPN linux server).
But, he asked me whether to use Windows VPN connection or the client app or the router (all were working options)...
I picked the router for him since it seemed the safest (and cuz his connection will drop when the VPN is out).
But I still wonder what's the difference between OS settings connection and client app connection 🤔
The VPN options in most OSes are based on the IPSec protocol. IPSec is a fairly comprehensive VPN protocol, but requires quite some time and skills to set it up properly. And the "easier" solutions are often commercial ones, which are fairly expensive. In addition some OS vendors, like Microsoft, also includes their own VPN alternatives as options.
OpenVPN uses its own protocol, and is thus not compatible with other VPN protocols. This is by design, to avoid implementing lots of features not strictly needed for the task OpenVPN tries to solve.
On the other hand, OpenVPN is an open source product, with the first release in 2001 [1]. Since then, OpenVPN has been through two security audits [2] [3] which it passed with quite few findings. And the critical ones where fixed quickly after [4].
On top of this, a Dutch security company, Fox-IT, has also worked with the Dutch government to deliver a certified OpenVPN solution to be used for data transfer up to the RESTRICTED security level [5] (Going higher than this usually means deploying dedicated VPN hardware). The OpenVPN-NL version is shipping with mbed TLS instead of OpenSSL, where both mbed TLS and OpenVPN has been another round of security audit.
So OpenVPN has proven over time to be a fairly solid and secure VPN solution, with not an enormous amount of security issues [6] over these years.
Thanks David for the detailed information!
I hope you won't mind another question that's been in my head for a decade:
Can a PPTP/L2TP VPN or OpenVPN bypass the (speed limit or throttling or data cap) by ISP?
I mean it encrypts the whole internet package, right? does that include stuff like the size of the package?
I actually tried to setup VPNs for many clients, but their internet experience (speed and capping) didn't change... maybe I didn't do the right setup or maybe it's not possible.
No, you cannot use VPN to circumvent neither traffic throttling or data quotas. The encrypted VPN traffic is also network traffic passing over the Internet.
Some ISPs may have some quotas or throttling on specific services, but you will most like see them doing the reverse in reality - they throttle or have quotas on all the Internet traffic except for selected services they provide with lesser restrictions. And since they most likely won't provide lesser restrictions on VPN services, you can't use VPNs to avoid this.
VPNs may be used to to circumvent blocks to services imposed by ISPs, as they can't see what you use the VPN for. For example, using the Private Tunnel service in China for example, can give you access to a more open Internet.
Thanks David, great intro
Makes tons of sense, thanks David for the explanation 😊
Just realized, this can use a bit more explanation:
Yes, VPNs encrypt the data being passed between the VPN client and server. But it doesn't make the size of the content "disappear".
So, say you want to download a file of 2MiB. All networks have a restriction of how large each network packet can be. This various slightly, but a very common value is 1500 bytes (this is a fairly comprehensive topic, but MTU and Ethernet frames are keyword). Each packet includes both MAC and IP headers (for TCP/IP traffic), and inside IP headers are your local IP address as well as the destination IP address found. And then comes the payload (the data you want to transfer). But due to this restriction, and the packet header information you have less than 1500 bytes per packet available when trying to transfer this 2MiB file. So what happens is that this large transfer is (automatically) chopped up into smaller pieces, fitting into the maximum capacity you can use. On the receiving side, all these fragments are then assembled and saved to a single file again.
When you add VPN into this mix, the VPN interface will receive a stream of packets, as described above. It will then encrypt each of these packets individually (hiding the contents) and then it will be sent further to the VPN host, which means another set of packet headers (which cannot be encrypted) together with the encrypted payload. The receiving side will then decrypt the payload and pass that to its local VPN interface again, containing the packet headers the sending side used.
What this means is that VPN will give an additional overhead and the effect of the available maximum size for the payload will be further reduced. Again, this is quite a complex topic, as there are approaches to try to avoid too much fragmentation on the VPN packets. But the effect is regardless that VPN in practice reduces the overall "transfer capacity" per network packet.
This means you will in almost all cases spend more data transferring packets passed over the VPN. To illustrate this, here's a (reordered) statistic of a VPN session on my computer. Here are both the packet and byte counters for traffic being sent to the VPN interface (TUN_BYTES_IN/TUN_PACKETS_IN). They are encrypted and sent out to the insecure Internet (BYTES_OUT/PACKETS_OUT)
What you see here is that more data is being sent to the VPN server than was received on the VPN interface. This is because encrypted network packets bigger and need additional splitting.
And for the traffice being sent from the VPN server to my client. BYTES_IN/PACKETS_IN is the encrypted data coming from the VPN server. TUN_BYTES_OUT/TUN_PACKETS_OUT is the decrypted data being sent to the VPN interface.
When receiving encrypted data from the VPN server, we see the reverse effect. We send less data/packets to the VPN interface, because decrypting the packets reduces the size.
And then you might wonder about compression. Compression is an alternative which may be used to reduce this overhead - when the traffic is compressible. But first of all, compression will reduce the security of the VPN tunnel. In addition a lot of the data being transported is already fairly compressed (like .mp3/.avi/.jpg files) or not suitable to compress (like https traffic) - both these cases will not result in much compression effect. So it is not recommended to use compression at all.
So to sum it up: VPNs will not hide the size of the data being transported. The effect will be that you use more data when using VPNs.
Ah, I see now...
It's actually shocking to know that VPN has the opposite effect on data size, regardless of how many falsified articles claim 😁
BTW guys, David is the team lead core dev of OpenVPN Inc.
Thanks a lot David for the explanation!