Forwarding modes explained
Consider a network of multiple nodes. Each node uses one or more addresses within the VPN network. Depending on the device type those addresses are either IP addresses (IPv4 or IPv6) for TUN devices or MAC addresses for TAP devices.
Whenever a node received a data from its virtual device, it has to decide to which other node that data should be forwarded. That is exactly what forwarding modes are about.
Native forwarding modes
This whole topic of forwarding strategies in not specific to VPNs, it has been discussed at lengths in networking in general. So there are several concepts that provide solutions:
Old-style Ethernet hubs just forward incoming data to all other ports (i.e. other nodes). This is the most simple but als most inefficient strategy. By forwarding the data to all other nodes (broadcasting), the node that should receive it, will receive the data but so do all the other nodes that shouldn't receive the data. With this strategy, nodes filter incoming data and only process the data that matches their address.
Ethernet switches use a more advanced strategy: They observe the incoming data and associate (learn) the source address (as contained in the data) with the port that the data came from. When forwarding data, the switch uses this knowledge and only sends the data to the port that is associated with the destination address. If no port is associated with the destination address, the switch will send the data to all other nodes like the hub. To avoid outdated associations to cause problems (either do to the address moving to another port or memory issues when storing lots of associations) associations for addresses that have not been seen for a defined timeout will be forgot. When using VLANs (virtual LAN), a 16 bit number (VLAN tag) is added to the Ethernet header and switches will keep separate switching tables for different VLANs.
The IP protocols (IPv4 and IPv6) use a completely different strategy: routing. The idea behind routing is that whole address ranges are forwarded (routed) to specified ports. The routing table is configured in advance and defines which address range should be forwarded to which port. Ranges can also overlap, in this case the most specific range decides. If no range matches a given destination address the data is not sent anywhere (dropped) since the address is not known. A lot of IP configurations include a default route that covers all addresses and defines where data that does not match any other (more specific) range should be forwarded to.
Forwarding modes in VpnCloud
VpnCloud supports all four forwarding modes:
normal. The mode can be configured via a configuration option. The
normal mode depends on the device type:
tundevices it is the same as
tapdevices it is the same as
The default forwarding mode in VpnCloud is
The hub mode has no further configuration options.
For the switch mode (or normal on TAP devices), the switch timeout can be configured via a config option, but the default should be fine for most people.
VpnCloud supports VLANs. Whenever an ethernet frame contains a VLAN tag, the tag is considered to be part of the source and destination addresses (i.e. a combined VLAN+MAC address having 8 bytes). This way, VpnCloud distinguishes the same MAC address on different VLANs and associates it with different nodes.
Since routing needs a routing table to work, VpnCloud allows nodes to claim addresses (or address ranges) in router mode (or normal on TUN devices). Those claims are then distributed to all nodes in the VPN network. Each node then uses those claims to construct a routing table.
By default (can be deactivated), nodes will claim the IP address that is configured on the virtual network interface (either configured directly or via a command) at the time the node starts. As a result, nodes will automatically create a routing table that contains all IPs on the virtual network interfaces of their peers. This is often all that is needed.
Additionally, users can configure additional claims in the configuration. Those claims will then be sent to all other nodes and be part of their routing tables. This way, a node can claim more than just one address. This allows for more complex setups.
Please note that all that has been discussed on routing so far concerns the routing within VpnCloud. This must not be confused with system routing. The host has a routing table of its own that defines which address range should be sent via which network interface. VpnCloud will only ever handle outgoing data, if the destination address is listed in the system routing table to be routed via the virtual network interface of VpnCloud.
When configuring the virtual network interface via the
ip option, VpnCloud automatically configures a /24 network with 256 addresses to be routed via the interface. When using a custom
ifup command, users have to take care of that.
VpnCloud will not change the system routing other than setting up the default /24 network for the interface. Any claims received from other peers will only work if those address ranges either fall into the default network or if the user configures additional routing table entries in the system routing table (e.g. using
"Non-native" forwarding modes
While the modes
switch are intended for Ethernet (i.e. TAP devices) and the
router mode is intended for IP (i.e. TUN devices), VpnCloud does not restrict the modes used by device type. However, using a mode on a device type it is not intended for (non-native mode) has some implications, users should be aware of.
Routing Ethernet frames
Users can configure the
router mode for
tap devices to forward Ethernet frames via a routing table.
In this mode, the user needs to claim MAC addresses in the configuration (instead of IP addresses). Users can claim ranges of MAC addresses (using the prefix length like in IP ranges), however this is not very useful as MAC addresses are not structured hierarchical.
Also, some protocols on top of Ethernet (e.g. ARP) use the fact that data sent to unknown addresses are sent to all ports in order to send data to everyone in the network. Those protocols will not work in
router mode as data will only be sent to at most one node. Data for an unknown address will be dropped and data for an address claimed by the multiple nodes will only be sent to one of those nodes in
In summary, this combination is not very useful.
Switching IP packets
Users can configure the
switch modes for
tun devices to forward IP packets via a learning switching.
In this mode, VpnCloud will associate IP addresses with nodes based on the source IP addresses it sees in incoming IP packets.
This mode should work pretty well in general and can in sometimes be used to avoid configuring claims statically. However, the switch mode will broadcast packets to unknown addresses which does not happen normally when routing. Some systems might be confused to receive a packet not destined to them. Depending on its configuration, the system might try to forward that packet to its destination causing the real destination to receive multiple copies of the packet. Internet protocols are normally resistant to receiving duplicates, but it is still anomaly.