Broadcast-Storm

[Guus Sliepen]

On Tue, Mar 16, 2010 at 05:32:07PM +0100, Markus Dangl wrote:

> I've got a small tinc network (switched) set up and it usually works
> fine. But sometimes i get echos from my own broadcasts and sometimes
> this even leads to a broadcast storm (two nodes forwarding the
> broadcasts in circle, thus flooding the whole network with copies of the
> same packet).
> 
> I'm currently unsure on how to debug this using tinc. So my questions are:
>  - How does tinc handle broadcasts when in switching mode? Does tinc
> understand STP? (I usually enable STP on all my linux bridges).

Tinc does not understand STP, but it ensures that the tinc network itself is
loop free.  So, you can see your VPN as a dumb switch, with each node being one
port of that switch. I think that if you bridge the VPN interface to LAN
interfaces, and the bridge itself supports STP, then everything should be fine.

>  - Not all of the clients update their tinc clients regularly, so i
> might have several tinc versions from 1.0.9 to 1.0.12 in my net. Could
> it be that incompatibilities between these versions are responsible for
> this?

Not that I know.

> Sadly not all of the installations are maintained by people that
> actually know a lot about network stuff. Also, a lot of the nodes run on
> Windows :/ so i don't have a portable way to use packet filtering on all
> nodes.
> 
> A nice-to-have feature for tinc would be to have some filtering options,
> maybe even a real packet filter (like those *-tables tools on linux). I
> see that that's not really tincs job, but there currently is no portable
> way of packet filtering, but tinc could do it :)
> If there are more people that could make good use of such a feature i
> might just start experimenting a little with the tinc sources.

There is an option in the latest version in the git repository that might help:

Forwarding = kernel

This will disable tinc's internal forwarding, and will send all received
packets directly to the VPN interface.  Most likely the kernel will try to send
it back to the VPN interface, since the packets are not for the local node, but
it would have to get past the firewall first.

But, there is no guarantee other nodes will send all packets via your central
node. So this is more of a debugging tool than a security feature.

Also, it does not tell you which node the packets came from. A solution to that
could be to add a VLAN or MPLS tag (with a unique ID for each node) to packets
sent to the VPN interface. However, that is not implemented yet.

As for filtering in tinc: I really do not want to duplicate pf or netfilter in
tinc. It would also be primarily of use for forwarded packets, not for ingress
or egress packets. The best way to keep the clients safe is to educate them how
to set up their firewalls.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20100317/5a387c8c/attachment.pgp>