Letting linux be the router, allowing dynamic routes, suggestion

[Marcelo Pacheco]

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>