<div dir="ltr"><div><div><div>What challenge this would solve ?<br><br></div><div>VPN software in general tries to be another router when running in server mode with multiple clients.<br></div><div>This restricts VPN customers from having complex topology.<br><br></div><div>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.<br></div><div><br>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.<br><br>This requires a means to diferentiate each remote connection from each other at the kernel interface.<br><br>Instead of creating a heap of tun devices, there's a more logical solution.<br>Create a TAP device, and emulate ARP on the VPN software.<br>The many peers would form a virtual ethernet device, where each tunnel has a separate virtual MAC address.<br><br></div><div>Something like this:<br><br></div><div>tap0:<br></div><div>inet <a href="http://10.255.255.1/24">10.255.255.1/24</a> MAC fd:fd:fd:fd:fd:01<br><br></div><div>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.<br><br></div><div>The at the kernel level we can have a routing table like this:<br></div><div><a href="http://10.255.255.0/24">10.255.255.0/24</a> dev tap src 10.255.255.1<br></div><div><a href="http://192.168.0.0/16">192.168.0.0/16</a> via 10.255.255.2<br></div><div><a href="http://10.2.3.0/24">10.2.3.0/24</a> via 10.255.255.3<br>...<br><br></div><div>This requires some fairly simple processing:<br>  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.<br></div><div>  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)<br><br></div><div>Doing something like this would transform tinc from a canned limited use software into an extremely flexible the sky is the limit tool.<br><br></div><div>The easiest solution might be to create/delete static ARP entries as tunnels are created/torn down.<br></div></div></div></div>