similar to: Problems about implementing a customized overlay network via Tinc

Hi Johnson, You might want to take a look at the IndirectData option, which will prevent tinc from trying to directly reach nodes it doesn't have a direct metaconnection to, using other nodes as intermediaries instead. On 15 October 2017 at 16:34, Johnson Li <johnsonli1993 at gmail.com> wrote: > Hi guys: > > I am using Tinc to build an overlay network, but I want to control

Hi, Etienne I took a look for the below host configuration parameter (IndirectData), the default is no. For the below example: A ConnectTo B, B ConnectTo C: If IndirectData = no (default), then A wouldn’t establish direct connection with C, but will be forwarded by B. If IndirectData = yes, then A will try to establish direct connection with C, even though A don’t have the statement of

Dear all, I like tinc and am using it widely in the company I work for. Currently I'm experimenting with 'switch' mode & have a problem with packets being forwarded. I've tried possible combinations with next parameters: a) Broadcast = direct b) Forwarding = kernel c) DirectOnly = yes From the documentation, it looks like (a) should be enough to stop packet forwarding

I don't know why, but for my case, I reduced the tinc topology from a complex one(which provide layered redundancy) to a very simpled one(one connection), and that connection drop disappeared. Later, let me draw the topology and share the config to you to see if there's any findings of the cause. Guus Sliepen <guus at tinc-vpn.org>于2017年9月14日 周四上午3:20写道： > On Wed, Sep 13, 2017

Hi, I have servers where shorewall6 won''t reject nor log: # cat /etc/shorewall6/zones fw firewall net ipv6 # cat /etc/shorewall6/interfaces net eth1 tcpflags (I also tried without "tcpflags", but no changes) # cat /etc/shorewall6/policy $FW all ACCEPT all all REJECT info # cat /etc/shorewall6/rules SECTION NEW (for testing, I removed all the rules) I am testing from

William Kennington <william at wkennington.com> writes: > Agreed. > On Feb 1, 2015 4:21 AM, "Etienne Dechamps" <etienne at edechamps.fr> wrote: > >> Considering how cheap that operation seems to be, would it make sense >> to call res_init() every time tinc retries a metaconnection? It's not >> doing that very often anyway... and it would solve

Hello, I'm running a tinc network including dozens of nodes in switch mode. Some are running stable branch 1.0, while a small set of nodes are running 1.1 with ed25519 support. I discovered some routing issue between two nodes: (names are hidden) A (1.1): ConnectTo = B ConnectTo = C IndirectData = yes Mode = Switch B (1.0): Mode = Switch C (1.1 but only with RSA key): Mode = Switch

It seems like that kind of problem could be solved by making sure that tinc continues PINGing over TCP metaconnections even when an UDP tunnel is established, to keep the metaconnection alive. In fact I was under the impression that the 1.1 branch already did that or that I had submitted some code to do that at some point in the past, but it looks like I maybe be misremembering things. On 13

I sent you a pull request that addresses the general issue, at least for the short term: https://github.com/gsliepen/tinc/pull/83 On 16 May 2015 at 19:36, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sat, May 16, 2015 at 04:53:33PM +0100, Etienne Dechamps wrote: > >> I believe there is a design flaw in the way SPTPS key regeneration >> works, because upon reception of

Is there a way to display the time of the 7960 running firmware 7.4? Im unable to find any information. Thanks, Ben Blakely -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20060308/a7e575cc/attachment.htm

On Sun, Feb 1, 2015 at 11:19 AM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Sun, Feb 01, 2015 at 04:08:47PM +0900, crocket wrote: > >> If tincd is started before name resolution comes up, it keeps failing >> for ever to resolve domain names in Address= host configuration >> variable after name resolution becomes possible. >> >> I think tincd should

On 13 April 2018 at 19:34, Alex Corcoles <alex at corcoles.net> wrote: > > Note that it would be easier to set up tinc nodes on your Windows > > desktop and Linux laptops, to avoid the additional complication of > > having to relay broadcast packets between your local networks and the > > tinc network. This is what I do in my setup. > > But both systems will

Hi all, So I have been reading through the docs available online and the different threads on this list, but I cannot seem to get this phone to work. I have configured the OS79XX.TXT and SIP/SEP*.cnf files (see attached), when I configure the phone to point to my tftp server and reboot it I get this message: Connection received from 10.6.0.224 on port 50608 [09/02 12:16:11.750] Read request

On Mon, Feb 09, 2015 at 10:57:05AM +0100, Florian Klink wrote: > I have some hosts which converted to systemd-networkd (which doesn't > support hooks by now), and most of the time, tinc simply won't come up > after bootup (or won't be able to reconnect when the network is > changed), which is really ugly. > > Having a local dns in front is somewhat hacky, I'd

I think RR DNS is the only viable solution under these circumstances. If you can cope with the fact that failovers won't be seamless, I don't think there's anything wrong with that though. On 07/21/2015 11:54 AM, Laz C. Peterson wrote: > The consensus seems to say no to RR DNS ? I am going to take that into serious consideration. > > With this proxy setup you describe, what

Hello, How does tincd determine the subnet(s) of other remote nodes? Does tincd read its copies of the hosts file and parse and follow the subnet information contained in the local files? Or does tincd solely trust the subnet information dynamically advertised by each remote node? In my experimentation, it seems that: a) tincd reads its own subnet(s) from its copy of its own host file, but

On Tue, Feb 14, 2017 at 1:46 PM, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Tue, Feb 14, 2017 at 11:21:34AM -0500, James Hartig wrote: > >> Those 2 boxes are in the same subnet and have addresses of 10.240.0.4 and >> 10.240.0.5, respectively, on their eth0 interface. Port 655 on tcp and udp >> is open to the world. The tinc_test_2 box has a ConnectTo of

On 09/03/2016 10:56 AM, Etienne Dechamps wrote: > C will still need keys in order to establish metaconnections with A and B (as > well as a few other things). However there is no need for C to own any > "Subnets" at all. If somebody breaks into C, he could get access to the vpn network, right? Because the keys are there, it will be possible to use them to get access. Even if

I'm using Tinc 1.1pre14 and I'm trying to connect a node that is behind a firewall that blocks all non-standard ports. I set up a rule in the server to redirect port 25 (that is not used in the server right now) to port 655, both in tcp and udp protocols, and set up the port 25 in the server host configuration file. The client can reach the server, but after the initial sync and key

Hang on a second. I've just re-read your original message and I believe you are confused about what the "Subnet" option does. Again, it deals with addresses *inside* the VPN. In the configuration you posted you seem to be using 10.240.0.4 and 10.240.0.5 as internal addresses, but then your other statements (and especially your dump edges output) seem to indicate that 10.240.0.4 and