Routing and keying Questions

[Ivo Smits]

Hello,

> My Questions:
> * Is this (nodes can talk to eachother without having the crypto keys) the
> correct behavior?

Yes, that's one of the advantages of using tinc.

> * What can I do get my desired behavior (only nodes sharing the keys of
> eachother can talk) ?

IP based firewalling, or point-to-point tunnels (which indeed means that you 
need one tunnel to connect 2 machines, but this can be simple IPIP or GRE 
tunnels, which do not involve userspace applications)

> * sending a killall -USR2 tincd gets me a lot of nice debug stuff. Is 
> there a
> documentation what is meant by the option value and the weight value?
Sorry, I don't know.

> * Is there a posibility to resolve the routing path through a tinc mesh?
Same answer.

Ivo


----- Original Message ----- 
From: "Frithjof Hammer" <mail op frithjof-hammer.de>
To: <tinc op tinc-vpn.org>
Sent: Sunday, July 06, 2008 3:02 PM
Subject: Routing and keying Questions


> Hello!
>
> I use tincd to interconnect 3 LANs: A, B and C. So long, it works fine:
> everybody reaches everybody. But I want a different behavior: A and B 
> should
> be allowed to talk, as should B and C. I tried to simply delete the
> host-files on the nodes that should not be allowed to talk to eachother:
>
> A has a hostfile from B
> B has a hostfile from A and C
> C has a hostfile from B
>
> But this is no use: I can still ping from A to C. My first thought was, 
> that
> they use B as in intermediate hop. But as the ping-latency suggests, they
> still talk to eachother directly:
>
> Ping from A to C via tinc:
> 64 bytes from 192.168.1.100: icmp_seq=2 ttl=64 time=77.5 ms
> 64 bytes from 192.168.1.100: icmp_seq=3 ttl=64 time=84.6 ms
> 64 bytes from 192.168.1.100: icmp_seq=4 ttl=64 time=77.1 ms
>
> Ping from A to C via WAN:
> 64 bytes from x.t-ipconnect.de (217.80.x.x): icmp_seq=1 ttl=58 time=72.9 
> ms
> 64 bytes from x.t-ipconnect.de (217.80.x.x): icmp_seq=2 ttl=58 time=72.9 
> ms
> 64 bytes from x.t-ipconnect.de (217.80.x.x): icmp_seq=3 ttl=58 time=71.5 
> ms
>
> As the roundtrip-times via tinc are only ~ 5-10ms higher than the rtt via 
> wan,
> it B can't be in the middle.
>
> My Questions:
> * Is this (nodes can talk to eachother without having the crypto keys) the
> correct behavior?
> * What can I do get my desired behavior (only nodes sharing the keys of
> eachother can talk) ?
> * sending a killall -USR2 tincd gets me a lot of nice debug stuff. Is 
> there a
> documentation what is meant by the option value and the weight value?
> * Is there a posibility to resolve the routing path through a tinc mesh?
>
>
> I don't want to setup two vpns because my scenario is more complex: It
> involves seven nodes and I want to define for each and everyone of them to
> which other nodes they may talk to.
>
> Any hints?
>
> Thanks
> Frithjof
> _______________________________________________
> tinc mailing list
> tinc op tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc