tinc devel - May 2015 - Letting linux be the router, allowing dynamic routes, suggestion

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>

On Tue, May 12, 2015 at 01:13:58AM -0300, Marcelo Pacheco wrote:

[...]
> 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.
You mean like using tinc in switch mode?

http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-Mode

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150512/d0c9be28/attachment.sig>

No, this would in fact operate as a routing mode instead of bridging.
TAP would be used as a means to push routing to where it belongs, the
linux/bsd/... kernel.
Consider the challenge of having completely dynamic routing between vpn
peers. In one minute I might have 10000 routes towards one specific peer,
and hour latter I might have NONE. And I need to diferentiate each peer at
the kernel routing layer.
And no, it can't be a pure bridge, it has to be L3 routing.
TAP is just to use the ethernet layer to multiplex/demultiplex each layer.
Consider how ethernet works.
How would linux/bsd routing works if we had 10 routers on the same subnet,
obviously each with a separate IP on that same subnet.
Now instead of having that physical ethernet wire, that wire is now 10 vpn
peers connected via the internet.
Consider that in that scenario each router have other ethernet interfaces,
but its ROUTING between the common ethernet interface and the remote ones.
Its not a BRIDGE between multiple ethernets.

On Tue, May 12, 2015 at 5:42 AM, Guus Sliepen <guus at tinc-vpn.org>
wrote:
> On Tue, May 12, 2015 at 01:13:58AM -0300, Marcelo Pacheco wrote:
>
> [...]
> > 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.
>
> You mean like using tinc in switch mode?
>
>
>
http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-Mode
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc-devel mailing list
> tinc-devel at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150512/bdefeb21/attachment.html>

On 12 May 2015 at 05:13, Marcelo Pacheco <marcelo at m2j.com.br>
wrote:
> 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.
I think you can already do this in tinc by using the Forwarding kernel option:
http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-Forwarding

That would be fine if I had a single remote peer.
Now if I have 10 remote peers, and a single tun/tap device, when linux
sends a packet towards the tinc tun/tap device, how it knows which remote
peer to talk to ?
The only transparent way to do it is if you do something like I described.
Please realize that I'm not talking as a plain VPN software user.
I am a C/C++ developer, I write communications protocols, I have written
some crappy (but funcional) VPN before, that were too crappy to think about
publishing the code.

On Tue, May 12, 2015 at 4:27 PM, Etienne Dechamps <etienne at
edechamps.fr>
wrote:
> On 12 May 2015 at 05:13, Marcelo Pacheco <marcelo at m2j.com.br>
wrote:
> > 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.
>
> I think you can already do this in tinc by using the Forwarding > kernel
option:
>
http://tinc-vpn.org/documentation/Main-configuration-variables.html#index-Forwarding
> _______________________________________________
> tinc-devel mailing list
> tinc-devel at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20150512/0618c049/attachment.html>