tinc devel - Aug 2005 - Automatic route add/del instead of supernetting

Hi,

I have a question about the routing to the tun device.

As I understand the tincd vpn solution, each side could add and delete 
subnets to the vpn, and these "routing" updates are send to every 
participating vpn node, so every node knows all subnets and the node 
where to send the traffic for it.

But, beside this, the operating system needs a way to distinguish 
between traffic destined for the vpn, which have to be send to the tun 
device, against traffic which should be forwarded via the "external" 
interface (for example all traffic send to a node itself).
To achieve this, each node have to add manually a route to the routing 
table for each vpn-subnet, pointing to the tun device.
Currently this is easily done with a so called supernetting 
configuration. But this is only working, if all subnets coming out of 
the same address range.

If a node adds a subnet coming from a complete different address range, 
than every node has to change there routing table manually (Initially 
done via the tinc-up script).

So the question is, is it possible to add some code to add a specific 
route to the kernel whenever a new subnet would be announced? The same 
should be done if the subnet is withdrawn.
Are there any disadvantages of such as solution (Ok, tincd have to be 
run as root to modify the kernel routing table)?

If we also add a hostroute pointing to the "externel" device for each 
vpn node, than it should be possible to announce a default route inside 
the vpn, right?

Any comments?
It would be nice if anyone could give me some hints where such a 
functionality should be added in the source (Currently I didn't read 
much of the code. Before doing so, I want to ask some experts here in 
the list if this is a reasonable plan)

Thank you for any suggestions
Holger

Oops,

seems to be that this was an RTFM question.
I installed tincd-1.0.4, but read a hardcopy of the man page of an older
version :-(.

So I will give the subnet-up/down script a try. But for the second part
of my question (host route for every node pointing to the external
device) there is currently no solution, right?

Thanks
Holger
> Miika Keskinen wrote:
> 
>> Hi,
>>
>> If I understood correctly the functionality you are looking for is
>> already present. There is subnet-up and subnet-down - scripts called
>> whenever subnet becomes available / unavailable. I have something like
>> ospf's algorithm which is controlled via fifo and when subnet
becomes
>> available I echo simple command (route add ... via ... dev ...) to that
>> fifo and have the listening 'routing daemon' handle changes.
>>
>> Miika
>>
>>
>> On 14:09 Mon 29 Aug     , Holger Zuleger wrote:
>>
>>> Hi,
>>>
>>> I have a question about the routing to the tun device.
>>>
>>> As I understand the tincd vpn solution, each side could add and 
>>> delete subnets to the vpn, and these "routing" updates
are send to
>>> every participating vpn node, so every node knows all subnets and
the
>>> node where to send the traffic for it.
>>>
>>> But, beside this, the operating system needs a way to distinguish 
>>> between traffic destined for the vpn, which have to be send to the 
>>> tun device, against traffic which should be forwarded via the 
>>> "external" interface (for example all traffic send to a
node itself).
>>> To achieve this, each node have to add manually a route to the 
>>> routing table for each vpn-subnet, pointing to the tun device.
>>> Currently this is easily done with a so called supernetting 
>>> configuration. But this is only working, if all subnets coming out
of
>>> the same address range.
>>>
>>> If a node adds a subnet coming from a complete different address 
>>> range, than every node has to change there routing table manually 
>>> (Initially done via the tinc-up script).
>>>
>>> So the question is, is it possible to add some code to add a
specific
>>> route to the kernel whenever a new subnet would be announced? The 
>>> same should be done if the subnet is withdrawn.
>>> Are there any disadvantages of such as solution (Ok, tincd have to
be
>>> run as root to modify the kernel routing table)?
>>>
>>> If we also add a hostroute pointing to the "externel"
device for each
>>> vpn node, than it should be possible to announce a default route 
>>> inside the vpn, right?
>>>
>>> Any comments?
>>> It would be nice if anyone could give me some hints where such a 
>>> functionality should be added in the source (Currently I didn't
read
>>> much of the code. Before doing so, I want to ask some experts here
in
>>> the list if this is a reasonable plan)
>>>
>>> Thank you for any suggestions
>>> Holger
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> tinc-devel mailing list
>>> tinc-devel@tinc-vpn.org
>>> http://brouwer.uvt.nl/cgi-bin/mailman/listinfo/tinc-devel
> 
> 
>