Moreover, there are particular benefits of OpenVPN:
As for every coin, there are also two sides when using VPN. One such disadvantage is that it is necessary to deal with an additional technology. Another disadvantage of VPN is, that additional data traffic is generated. This may result unexpected and hard to calculate cost for M2M communication. GPRS, EDGE and UMTS are not charged according to connection time, but transferred data volume (traffic) – in contrast to other services.
The overhead of OpenVPN shall be considered and estimated in the following.
OpenVPN generates a virtual network as the client sets-up a data connection to the server and maintains this connection. The actual data packets are sent through this connection (also referred to as tunnel). So, the original data packets must be embedded in the packets, which represent the tunnel. This means that more information is transferred at all – an additional overhead is generated.
This overhead is to be quantified differently from case to case. Among other things, it depends of:
OpenVPN can tunnel data on level 2 (bridging) or level 3 (routing):
When bridging, the data to be tunnelled is packed into new Ethernet packets, when routing into new IP packets. Therefore, bridging leads to less overhead, because a bit less information has to be transferred for the new Ethernet packets than for the new IP packets when routing.
Thus, bridging seems to be very attractive first, especially because it results the simple enlargement of the network as additional benefit. However, bridging cannot be used in reality from the network planning view, because the administrative effort in the central network for considering the participants of the extended network increases. Therefore, routing is the preferred variant in most cases.
Again, tunnels created with the aid of UDP packets create less overhead then tunnels with TCP packets. A UDP connection is preferred by default. This is not only founded in less overhead, but also by less latency times for a UDP tunnel in contrast to a TCP tunnel. OpenVPN must take care that the packets are unpacked and assembled correctly at the remote terminal again for both tunnel types. An unnecessary redundancy occurs with this for TCP, which is already connection-protected.
OpenVPN allows to encrypt the data to be tunnelled before transmission, which provides additional protection. This results in additional overhead.
This is an example for the overhead resulted by an encrypted UDP tunnel with default setting:
| UDP tunnel | ||
| additional IP header | 20 byte | |
| additional UDP header | 8 byte | 28 byte |
| optional encryption | ||
| HMAC-SHA1 signature | 20 byte | |
| initialisation vector | 16 byte | |
| sequence number | 4 byte | |
| include packet tag | 1 byte | 41 byte |
| total | 69 byte | |
This overhead has more effect when tunnelling very small data packets than for large data packets. However, since transferring very low data packets is very inefficient without tunnel already, and, on the other hand, the 69 byte do not effect disproportionally more traffic for large data packets (theoretically up to 1500 byte) as well , the overhead should be justified in most cases.
OpenVPN can compress the data to be tunnelled before transmission. The LZO algorithm (Lempel-Ziv-Oberhumer) is used here. This does barely reach the compression rates of ZIP for example, but LZO has the benefit that the data is packed and unpacked nearly in real-time.
LZO is a loss-free compression, which results some limits. Moreover, the compression rate depends very much on the data to be transferred. Already compressed data, like zipped files or images, like .jpg, cannot be compressed much further. Text, like HTML, XML or also images in raw data formats, like bit maps for example, can be compressed very good. Compression rates of more than 60% for example are resulted when surfing.
The default adaptive compression is another feature of OpenVPN to save computation effort and increase performance. The compression rate is monitored for this. If the compression rate falls below a configured value due to the nature of the data, the compression will be disabled as long as compressible data material is to be sent again. This saves computation power in addition.
Apart from the tunnel packet overhead, additional traffic occurs for the artificial network of the VPN. Some reasons are:
A field device is connected to the Internet via a GPRS/EDGE/UMTS router. The router establishes an OpenVPN tunnel to a control center, in which an OpenVPN server is running, automatically after the connection is established. The authentication is performed via X.509 certificates. The field device generates data (2000 byte), which is to be retrieved once per minute from the control center via HTTP.
The following is assumed for the individual processes:
The 3125 byte for the payload are determined empirically and are composed of:
The daily data traffic is composed as follows:
| 3125 byte payload/minute x 1440 minutes/day | 4,500,000 byte |
| 2 x connection set-up/day | 26,000 byte |
| 24 x hourly connection check (via DNS request) |
22,152 byte |
| 24 x hourly key renegotiation | 240,000 byte |
| 2880 x OpenVPN ping (1 ping/minute outgoing and incoming) |
0 byte |
| Total data traffic/day | 4,788,152 bytes |
Approximately 10 % of the data traffic are required for the provision of the data connection inclusive tunnel in this example. The OpenVPN ping is not performed in this case, because the tunnel check is set aside, if data traffic exists otherwise.
A big disadvantage when connecting field devices via GPRS can be the high latency time. Especially for the first packet after a long transmission pause, 1000 ms to 2000 ms may elapse. This long latency times can be reduced to the times, which typically level during a longer data transmission, with an OpenVPN tunnel and its ability to create artificial data traffic with "OpenVPN pings". Indeed, this increases the data traffic, but it is possible to mitigate time-critical applications with this, which could only be used with difficulties via GPRS otherwise and would only work with other technologies, like EDGE or UMTS for example.
Without any payload data traffic and a
{(4 x 60 x 24 x 81 byte) + (30 x 24 x 81 byte)} result a daily data traffic of 524,880 byte.
Thus, this "continuous ping" costs approximately 12 MByte per month. This is more or less acceptable depending on the mobile radio contract and should be considered carefully.
The higher the data volume, the lower will be the portion, which is necessary for the OpenVPN overhead and its infrastructure. A VPN with OpenVPN may result the effect that less data traffic occurs due to compression.