External links

Frequently Asked Questions

Why does my VpnCloud setup perform so poorly?

Most likely this is because of a slightly too high (or missing) MTU setting on the interface. Please try the recommended value of 1400. With proper MTU settings, VpnCloud should perform almost as good as the native network.

What happens when I increase the MTU above 1400?

Setting the MTU higher than the physical medium causes IP to fragment each inner packet into several outer packets and reassemble them at the receiving side. This has the advantage that VpnCloud has to process less packets and therefore uses less CPU (most of it will be memcpy) and has less context switches. It will also save some bytes on the wire as less bytes are used for VpnCloud headers and UDP headers and only a small additional IP fragmentation header is added.

The downside is that if one of the outer packets gets lost on the wire the whole inner packet is lost. If your MTU is is 40 times higher than normal, 40 outer packets will be sent for one inner packet. So your packet loss rate will be about 40 times higher than normal (e.g. 4.1% instead of 0.1%). It will also influence your delay distribution negatively.

If the delay distribution and the loss ratio matters to you, this is a bad idea. If your line is pretty good and you just care about throughput, I think it makes sense to increase the MTU.

(Full thread in issue #2)

Does VpnCloud support IP multicast?

VpnCloud has no special support for multicast and I did not test any multicast scenarios. So this is all theoretical:

  • If you use a TAP device, IP multicast should be mapped to ethernet broadcast and just work (although being a little bit inefficient)
  • If you use a TUN device with the default router mode IP multicast packets should be dropped as no node claims the IP multicast region.
  • If you use a TUN device with the learning switch mode, the multicast packets should be broadcast and multicast should just work (although being a little bit inefficient)

Other VPN software either does not implement multicast (like VpnCloud currently) or cheats by broadcasting it. Proper multicast support is somewhat complicated as several control protocols for IPv4 and IPv6 have to implemented.

(Full thread in issue #12)

What does "non-native forwarding mode" mean?

There are two device types TUN and TAP and the only difference between them is that TUN transports IP packets and TAP transports Ethernet frames.

All the rest is about how VpnCloud decides where packets/frames should be sent to. In routed mode each node claims one or more address regions by prefix and all the nodes match against those prefixes. In switch mode, nodes learn addresses by looking at the source addresses and broadcast for unknown addresses. Routed mode is native to TUN devices and switched mode is native to TAP devices but there is no reason not to use switched mode for TUN devices.

(Full thread in issue #12)

How much overhead do VpnCloud headers add?

VpnCloud has a fixed 8-byte header. If encryption is used, another 12-byte header and a 16 byte checksum are added. As VpnCloud packets are transported over UDP, you have to add the UDP header (8 bytes), an IP header (20 bytes for IPv4 and 40 bytes for IPv6) and an Ethernet header (14 bytes) for TAP devices.

So the total overhead is:

  • 50 bytes if unencrypted and IPv4
  • minus 14 bytes for TUN devices
  • plus 28 bytes for encryption
  • plus 20 bytes for IPv6