search for: connecttos

Hi Team, I admit that I am not familiar with Tinc very well, but have Tinc running at approximately 20 sites and functioning as a mesh vpn/network. I am having issues adding an additional site as it will not communicate with the rest. I have taken the firmware of one and flashed it on another router to make it duplicate and then tested it working but when I change the hostname, and IP to what we

I have a use case where my tinc.conf ConnectTo can go upto 20 + hosts. I am planning to automate a periodic cleanup of ConnectTo in the tinc.conf file, the issue is I am not able to figure out which ConnectTo is been used and which are stale, say NOT used in last 2 to 3 days. I want to remove those ConnectTo which are no longer actively used. Is it possible to find which ConnectTo are not used.

Hi Guus Following your suggestion we reconfigured our tinc network as follows. Here is a new graph and below is our updated configuration: http://imgur.com/a/n6ksh - 2 Tinc nodes (yellow labels) have a public external IP and port 655 open. They both have ConnectTo's to each other and AutoConnect = yes - The remainder tinc nodes (blue labels) have their tinc.conf set up as follows:

Thanks Guss, some comments and questions: If you make the yellow nodes ConnectTo all other nodes, and not have > AutoConnect = yes, and the other nodes just have AutoConnect = yes but > no ConnectTo's, then you will get the desired graph. The reason this approach is not desirable is because it fails at automation. It requires us to add a new line of AutoConnect = <new node that

On Thu, Mar 15, 2018 at 03:41:00PM +0000, Chris . wrote: > I admit that I am not familiar with Tinc very well, but have Tinc running at approximately 20 sites and functioning as a mesh vpn/network. I am having issues adding an additional site as it will not communicate with the rest. I have taken the firmware of one and flashed it on another router to make it duplicate and then tested it

On Mon, Jan 12, 2015 at 12:37:24PM +0530, Anil Moris wrote: > I have a use case where my tinc.conf ConnectTo can go upto 20 + hosts. > > I am planning to automate a periodic cleanup of ConnectTo in the tinc.conf > file, the issue is I am not able to figure out which ConnectTo is been used > and which are stale, say NOT used in last 2 to 3 days. > > I want to remove those

Hi Guus Thanks for clarifying. Some follow up questions: - How do we patch 1.1pre14 with this fix? Or will there be a 1.1pre15 to upgrade to? - What is the workaround until we patch with this fix? Using a combination of AutoConnect and ConnectTo? - When we use ConnectTo, is it mandatory to have a cert file in the hosts/* dir with an IP to ConnectTo ? -nirmal On Tue, Aug 22, 2017 at 12:10

Hi, Tinc Expert in my tinc.conf, the ConnectTo to host X is commented, like below: #ConnectTo = X and there is a script: /etc/tinc/netname/hosts/X-up, I thought commented the ConnectTo X wouldn’t trigger the X-up, but it did. Why? What’s the logic behind to trigger host-up? How can I avoid this except remove the host-up file? Bright Zhao

thanks Guus for the quick response. I am using tinc 1.1 if I use AutoConnect = yes then will it automatically remove connections that are no longer in use? What are the security issues with 'AutoConnect = yes' I should be worried? for my use case I might go upto 20 to 30 + tinc hosts connected to single tinc box. as per the doc AutoConnect = yes is experimental, I am using it in our

Hi Today our Tinc network saw a network partition when we took one tinc node down. We knew there was a network partition since the graph showed a split. This graph is not very helpful but its what I have at the moment: http://i.imgur.com/XP2PSWc.png - (ignore node labeled ignore, since its a dead node anyways) - node R was shutdown for maintenance - We saw a network split - we brought node R

Hi, we use a tinc network of about 400 nodes, all of them linux servers, partly in different datacenters (but generally low latency). Usually this is working very well (for weeks without a problem). >From time to time the whole network goes down though. This happened when we restarted a larger number of servers or when there was a connectivity issue between datacenters or some (short)

On Thu, Aug 31, 2017 at 01:37:28PM -0700, Nirmal Thacker wrote: > If you make the yellow nodes ConnectTo all other nodes, and not have > > AutoConnect = yes, and the other nodes just have AutoConnect = yes but > > no ConnectTo's, then you will get the desired graph. > > The reason this approach is not desirable is because it fails at > automation. It requires us to

I admit that I am not familiar with Tinc very well but see that Tinc is running their current vpn connections. We have a scenario that has 20 different sites currently and successfully using tinc on openwrt but I am having issues adding an additional site as it will not communicate with the rest. I am not the one that originally setup the system but that person is no longer available. I have

H, Narcissus Quick one for the below case, if node A have a direct connection to node B, and node B have a connection to node X, then I found node A will be able to talk to node X, but the communication path is go through node B, instead of build direct connection between A and X, is that right? I tested this in my environment. A >> B >> X > On 1 May 2017, at 3:07 PM, Narcissus

Hi there!!! I'm returned to TINC :D I've got a question: I've setted up a server in a provider's NAT, and all users of this VPN are in the same provider's NAT... Well, I let the main server connect to all users, but... only the first ConnectTo works... in fact I've noticed that if the first user connects to another one, the last can connect to the server, while he

...e the tinc.conf can support multiple ConnecTo, also the tinc can support multiple netname, like /etc/tinc/net1, /etc/tinc/net2. > > My question is, for my above use case, I should go with multiple netname instead of multiple ConnectTo, right? I did some tests, and I found no matter how many ConnectTos I placed in the tinc.conf(on the client side), only one connection can made to the server, and only one tun0 bring up with is the p2p connection can only go with one server, even though from debug message, I saw to connections all established, but only one connection is pingable. > > If this...

...it indicate the tinc.conf can support multiple ConnecTo, also the tinc can support multiple netname, like /etc/tinc/net1, /etc/tinc/net2. My question is, for my above use case, I should go with multiple netname instead of multiple ConnectTo, right? I did some tests, and I found no matter how many ConnectTos I placed in the tinc.conf(on the client side), only one connection can made to the server, and only one tun0 bring up with is the p2p connection can only go with one server, even though from debug message, I saw to connections all established, but only one connection is pingable. If this is the ca...

I did notice the that interface we have named br-lan did not have the proper broadcast and netmask information. I adjusted that and it looks like its now connecting but still running into issues. Here is a snipet from the new system we are trying to connect in (from the /var/log/tinc.log file) 2018-03-15 22:57:26 tinc.NETNAME[871]: Read packet of 74 bytes from Linux tun/tap device (tun mode)

X-up is being called when any connection is being built between node A and node X, it doesn't have anything to do whether you have connectTo in the config file or not. Because tinc is a mesh network, if node A have a direct connection to node B, and node B have a connection to node X, you can have a connection between A and X, and X-up is being called at the moment when it built a connection

Indeed it depends, tinc will have a port listening for incoming connections(both tcp and udp), if A have exposed its listening ports, a direct connection will be tried to build between the nodes, otherwise it will go from the intermediate node. -- Narcissus Emi 日時: 2017年5月1日 15:12:16, Bright Zhao (startryst at gmail.com) が書きました:: > H, Narcissus > > Quick one for the below case, if