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/ _______________________________________________ tinc mailing list [email protected] https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
