This website uses Google Analytics. Please click here to prevent Analytics from tracking your surfing behavior. Click here to stop the tracking.

Virtual Private Network (VPN)

Consideration of Overhead and Data Volume


There are many benefits when using a VPN, like

  • the availability of devices connected via GPRS ("provider firewall")
  • the communication costs can be reduced, because Internet connections are usually more reasonable than direct connections ("around the world for local rate")
  • the confidentiality of the data is ensured: protection against manipulation, recording, eavesdrop, etc.
  • the additional authentication of VPN participants generates new administrative and logistic options
  • reduction of latency times when starting a data connection

Moreover, there are particular benefits of OpenVPN:

  • The flexibility, simplicity, and robustness of OpenVPN is perfectly suitable for arranging the various different connection scenarios of machines and their remote maintenance.
  • In contrast to other VPN implementations, OpenVPN is not based on proprietary protocols and can therefore create connections in constellations, which would overburden other implementations.


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.

Functionality of OpenVPN

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.

Considering the overhead

This overhead is to be quantified differently from case to case. Among other things, it depends of:

  • how the VPN is configured, and
  • which data is transferred.


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.


  • TCP tunnels should only be used, if UDP tunnels cannot be realised due to other reasons, like firewall settings.

Data encryption before transmission

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:

 Overhead for encrypted UDP tunnel
 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


 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.

Further aspects

Apart from the tunnel packet overhead, additional traffic occurs for the artificial network of the VPN. Some reasons are:

  • Depending on the authentication type, data packets are transferred for authentication even before a tunnel has been established.
  • Connection check: an existing tunnel should be checked for existence regularly.
  • Data should be sent through the tunnel regularly that the ports used for the tunnel are not closed by routers, which connect both tunnel ends (stateful firewall).
  • Agreed parameters for encrypting the data packets should be renewed regularly.

 Example application

 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:

  • Dial-up to the Internet and subsequent tunnel set-up: 13,000 byte
  • Renewed negotiation of the encryption: 10,000 byte
  • One-time connection check (Internet connection): 1000 byte
  • One-time connection check (VPN tunnel): 81 byte
  • Retrieving the payload via HTTP: 3125 byte

The 3125 byte for the payload are determined empirically and are composed of:

  • 2000 byte text file
  • 1021 byte TCP header, HTTP header and HTML code
  • 104 byte pure OpenVPN overhead


The daily data traffic is composed as follows:

 Daily data traffic
 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 byte


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.

Reduction of latency times

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.

Ping costs

Without any payload data traffic and a

  • ping interval of 15 seconds from field device to control center and a
  • ping interval of 2 minutes from control center to field device

{(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.

OpenVPN ressources in the Internet:

OpenVPN Technologies, Inc.
Community about OpenVPN
  • Lowering communication costs
  • Authenticating communication partners
  • Making GPRS devices available in the field
  • Reducing latency times
 Our new website

Convince yourself of our passion for professional IoT and M2M data communication.

We look forward to you!