Letting linux be the router, allowing dynamic routes, suggestion

Marcelo Pacheco marcelo at m2j.com.br
Tue May 12 06:13:58 CEST 2015


What challenge this would solve ?

VPN software in general tries to be another router when running in server
mode with multiple clients.
This restricts VPN customers from having complex topology.

For instance, I'd like to have two tunnels between each client network and
each server (with two broadband connections on each end), with some OSPF
running and automatically switching from one to another. In other
scenarios, I have a dedicated hard line or carrier MPLS, and would like to
have a hot VPN up as a backup.

The solution to all of those challenges is to have the VPN software not be
the router, but rather just dump incoming packets to the kernel and route
outgoing packets with the kernel in charge.

This requires a means to diferentiate each remote connection from each
other at the kernel interface.

Instead of creating a heap of tun devices, there's a more logical solution.
Create a TAP device, and emulate ARP on the VPN software.
The many peers would form a virtual ethernet device, where each tunnel has
a separate virtual MAC address.

Something like this:

tap0:
inet 10.255.255.1/24 MAC fd:fd:fd:fd:fd:01

the arp table would have an entry for each remote connection, in this case
10.255.255.2 ... 254, just put the last byte of the IP as the last byte of
the MAC address.

The at the kernel level we can have a routing table like this:
10.255.255.0/24 dev tap src 10.255.255.1
192.168.0.0/16 via 10.255.255.2
10.2.3.0/24 via 10.255.255.3
...

This requires some fairly simple processing:
  L2 packets coming from the kernel (filled with the SRC MAC address from
the interface and DST MAC address resolved with ARP), using the DST MAC
address to know which tunel to send to.
  L3 packets coming from the tunel would be expanded into a L2 packet (with
the SRC MAC = the tunel virtual MAC Address, DST MAC = local interface MAC
address, and ether type = ipv4 or ipv6)

Doing something like this would transform tinc from a canned limited use
software into an extremely flexible the sky is the limit tool.

The easiest solution might be to create/delete static ARP entries as
tunnels are created/torn down.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150512/c42b4cef/attachment.html>


More information about the tinc-devel mailing list