Hi all I feel like I should know the answer to this question, like I read it someplace sometime, but it evades me right now. It's also an opportunity to say hello to the list and many thanks for writing and supporting tinc vpn! We make great use of it at rhizomatica. So, Let's take this example setup. I have two tinc nodes (A and B) behind a firewall NodeA and NodeB have 192.168.1.2 and 192.168.1.3 assigned on an internal LAN, and they both have different public IP addresses forwarded to them, port 655 udp/tcp The rest of the nodes C-Z are spread out around the internet. NodeA is our "master" server with all the keys for all nodes, so every node in Node C-Z group has a ConnectTo = NodeA line and has NodeA's key, with an Address = nodea_public_ip line of course. Now, here's the question. I would like any given node in the C-Z group to be able to find Node B on it's public IP and therefore not forward via NodeA, but I would like to be able to do this without having to distribute NodeBs host key file with an Address = line to every node in the C-Z group. Right now, if I ask any node in C-Z for info NodeB I get: Address: 192.168.1.3 port 655 Reachability: none, forwarded via NodeA NodeA and NodeB itself have NodeB's public IP address in the Address line in the host/key file for NodeB, and LocalDiscovery is in operation on the 192.168.1.x LAN behind the firewall, some other nodes are actually there too. Node B is reachable on the publicIP from the LAN (Nat reflection is in operation) Is there a way to force NodeA or NodeB to "advertise" it's public IP to the rest of the tinc network, or did I miss something really obvious? Thanks! Keith.
AFAIK, and my setups thus far, unless you have NodeB’s public key in Nodes C-Z (with NodeB’s public/reachable IP configured in Nodes C-Z) *and* you have the PublicKeys for NodesC-z configured in NodeB, there is no way that NodesC-Z will be able to establish a connection directly with NodeB, and it’ll have to forward via NodeA (or any other node that do have a direct connection established with NodeB using it’s keys etc) Understand it like this: for any two nodes to have a *direct* connection, they need to share the other’s Public Key to properly authenticate each other. It is a function of the security choices for TINC.> On 22 May 2017, at 11:03 AM, Keith Whyte <keith at rhizomatica.org> wrote: > > Hi all > > I feel like I should know the answer to this question, like I read it > someplace sometime, but it evades me right now. > > It's also an opportunity to say hello to the list and many thanks for > writing and supporting tinc vpn! We make great use of it at rhizomatica. > > So, > > Let's take this example setup. > > I have two tinc nodes (A and B) behind a firewall > > NodeA and NodeB have 192.168.1.2 and 192.168.1.3 assigned on an internal > LAN, and they both have different public IP addresses forwarded to them, > port 655 udp/tcp > > The rest of the nodes C-Z are spread out around the internet. > > NodeA is our "master" server with all the keys for all nodes, so every > node in Node C-Z group has a ConnectTo = NodeA line and has NodeA's key, > with an Address = nodea_public_ip line of course. > > Now, here's the question. > > I would like any given node in the C-Z group to be able to find Node B > on it's public IP and therefore not forward via NodeA, but I would like > to be able to do this without having to distribute NodeBs host key file > with an Address = line to every node in the C-Z group. > > Right now, if I ask any node in C-Z for > > info NodeB > > I get: > > Address: 192.168.1.3 port 655 > Reachability: none, forwarded via NodeA > > NodeA and NodeB itself have NodeB's public IP address in the Address > line in the host/key file for NodeB, and LocalDiscovery is in operation > on the 192.168.1.x LAN behind the firewall, some other nodes are > actually there too. > Node B is reachable on the publicIP from the LAN (Nat reflection is in > operation) > > Is there a way to force NodeA or NodeB to "advertise" it's public IP to > the rest of the tinc network, or did I miss something really obvious? > > > Thanks! > > > Keith. > > > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
On 22/05/17 11:22, hvjunk wrote:> AFAIK, and my setups thus far, unless you have NodeB’s public key in Nodes C-Z (with NodeB’s public/reachable IP configured in Nodes C-Z) *and* you have the PublicKeys for NodesC-z configured in NodeB, there is no way that NodesC-Z will be able to establish a connection directly with NodeB, and it’ll have to forward via NodeA (or any other node that do have a direct connection established with NodeB using it’s keys etc)Hi! thanks for the reply. That goes against what I am seeing. I currently have a Node, let's call it 'G' which is also publicly reachable on a static IP. No other node has it's key except NodeA, the master. All tinc nodes can reach it directly. This is 100% confirmed by watching the traffic with tcpdump.> > Understand it like this: for any two nodes to have a *direct* connection, they need to share the other’s Public Key to properly authenticate each other. It is a function of the security choices for TINC.I don't mean to contradict you, but I think you misunderstand something about key distribution and the meta connections. https://www.tinc-vpn.org/documentation-1.1/How-connections-work.html#How-connections-work: "Tinc daemons exchange information about all other daemon they know about via these meta-connections." I think the problem in my case is that my NodeA is finding NodeB by LocalDiscovery and therefore ignoring the Address in the hosts config. NodeA is then telling the other tinc dameons that NodeB is at 192.168.1.3, which is not very useful. Keith.
On Mon, May 22, 2017 at 4:03 AM, Keith Whyte <keith at rhizomatica.org> wrote:> Is there a way to force NodeA or NodeB to "advertise" it's public IP to > the rest of the tinc network, or did I miss something really obvious?the config files can use DNS names, right? Have the nodes that you want to advertise their public IP addresses sign up with Dyndns or similar, presto done. -- everything has to be just so or the magic won't work
On Mon, May 22, 2017 at 11:03:30AM +0200, Keith Whyte wrote:> I have two tinc nodes (A and B) behind a firewall > > NodeA and NodeB have 192.168.1.2 and 192.168.1.3 assigned on an internal > LAN, and they both have different public IP addresses forwarded to them, > port 655 udp/tcp > > I would like any given node in the C-Z group to be able to find Node B > on it's public IP and therefore not forward via NodeA, but I would like > to be able to do this without having to distribute NodeBs host key file > with an Address = line to every node in the C-Z group.[...]> Node B is reachable on the publicIP from the LAN (Nat reflection is in > operation)The problem is getting the information about NodeB's public IP address to the other nodes. Since you have NAT reflection working, the easiest way is for NodeA and NodeB to connect to each other using their public IP address. This will cause these address to propagate to the other nodes.> Right now, if I ask any node in C-Z for > > info NodeB > > I get: > > Address: 192.168.1.3 port 655 > Reachability: none, forwarded via NodeAThe info command gives the address that is currently selected by the local node for communication with NodeB. However, tinc might know more than one address. You can do: tinc -n <netname> dump edges | grep 'to NodeB' The "at" addresses are the externally visible addresses for NodeB. Recent versions of tinc 1.1 however also report there own local address. You can find the local addresses of NodeB using: tinc -n <netname> dump edges | grep '^NodeB' And looking at the address after "local". Since you enabled the LocalDiscovery in NodeB's tinc.conf, then it will likely pick NodeA's local address for direct UDP communication with it, which is more efficient than using NAT reflection. But you have to make a connection between NodeA and NodeB using their public IP addresses, otherwise they themselves will not know they have those, and will only tell the other nodes about their local addresses. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20170522/9d63dddb/attachment.sig>
On 22 May 2017 16:30:49 CEST, David Nicol <davidnicol at gmail.com> wrote:> >the config files can use DNS names, right? Have the nodes that you >want to advertise their public IP addresses >sign up with Dyndns or similar, presto done.Unfortunately it does not make any difference. I have static IPs and DNS here anyway, but regardless of what is in the nodeB config file, nodeA is telling the other tinc daemons to look for nodeB at 192.168.1.3, presumably because that is where nodeA is seeing it. In fact, it might be good in some scenarios to be able to change this behaviour as it also causes traffic from all nodes to unreachable addresses. Thanks.>-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 22/05/17 21:02, Guus Sliepen wrote:> The info command gives the address that is currently selected by the > local node for communication with NodeB. However, tinc might know more > than one address. You can do: > > tinc -n <netname> dump edges | grep 'to NodeB'OK, I have a mix of 1.0 and 1.1.. 'NodeB' is actually running 1.1pre14-63-g3d8a836 I checked that on all the 1.1 nodes, I only have one IP listed. so only the LAN IP is propagating, for the reasons you state below.> But you have to make a connection between NodeA and NodeB using their > public IP addresses, otherwise they themselves will not know they have > those, and will only tell the other nodes about their local addresses.OK, so I tried that. but arrg.. the master NodeA still found NodeB at the router address. so now 192.168.1.1 is propagating. Not sure what's going on there, it's a BSC/pf system.. so I guess that is the way it's doing NAT reflection, it's passing the broadcast probe. I'm good with netfilter, but tracking this kind of thing down in pf well.. I have to open some manuals :) I guess maybe I could prevent that with yet another firewall rule, but this is getting messy. The other thing might be to turn off Local Discovery.. I have eight tinc nodes on this LAN, I suppose I have to turn off local discovery for all off them, otherwise just one will find the local IP and "poison" the tinc node list? Would you consider giving the address listed in the host config file priority for propagation to other tinc daemons? or maybe this is very much of an outside case? Would appreciate your opinion. (I'm not offering a patch at this time, - I have hardly looked at tinc source, but might be quite simple, no?) couple of points: I am thinking that If I can, I would prefer not to relay everything through 192.168.1.2 when there's no need. But maybe the performance hit there is negligable, as there is no crypto happening, is that correct? 192.168.1.2 is just relaying the UDP packets? I may in the future end up with a LOT of traffic coming through "nodeB", however actual communication between "nodeA" and "nodeB" would be minimal, so I don't really mind that using the NAT reflection for that. Thanks Guus! k/