similar to: LocalDiscovery flip flopping and network design tips

Can you specify which version of tinc you're using? There are vast differences in the way LocalDiscovery works between 1.0 and 1.1. The former uses broadcast, the latter unicast to explicitly advertised local addresses. You say that tinc_test_1's eth0 interface is configured with 10.240.0.4, and tinc_test_2's eth0 interface is configured with 10.240.0.5. How are the public addresses

On Tue, Feb 14, 2017 at 1:22 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > > Can you specify which version of tinc you're using? There are vast differences in the way LocalDiscovery works between 1.0 and 1.1. The former uses broadcast, the latter unicast to explicitly advertised local addresses. I'm using tinc 1.1pre14. I noticed there's an option,

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 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 tinc_test_1. > When tinc_test_2 is started, it prints out: > UDP address of tinc_test_1 set to

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

@Etienne, I understood your explanation about the Subnet being the network *inside* the VPN, but the following the example https://www.tinc-vpn.org/examples/proxy-arp/, it seems to have: Subnet = 192.168.1.0/24 for the office, yet the IP address for the office is 192.168.1.2. Is that example no longer valid or am I misunderstanding? On Tue, Feb 14, 2017 at 4:01 PM, James Hartig <james at

On Tue, Feb 14, 2017 at 3:43 PM, Etienne Dechamps <etienne at edechamps.fr> wrote: > 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 >

These two networks can be the same, i.e. the VPN can be an extension of your local network, sharing the same subnet. That's one the many ways things can be set up. The same result can be achieved through other ways (e.g. Ethernet-level bridging). This does not contradict my earlier statement: a subnet can be *both* inside *and* outside the VPN, depending on the scenario. The Subnet

On 14 February 2017 at 18:59, James Hartig <james at levenlabs.com> wrote: > When you say "and to the local network" what IP does it try to send to > on the local network? The subnet address? No. The Subnet option deals with routing *inside* the VPN, not the underlying "real" network. In tinc 1.1, the address that local discovery probes are sent to is the local

LocalDiscovery works by sending some of the MTU probe packets to the broadcast address (255.255.255.255). If the destination node receives one of these packets, it will update its UDP cache and reply, thus the two nodes will start using their local addresses to communicate. Now, I see two problems with this approach: - In case the two nodes are behind the same NAT and can reach other *but*

Hi, I believe I have found a bug with regard to the LocalDiscovery feature. This is on tinc-1.1pre7 between two Windows nodes. Steps to reproduce: - Get two nodes talking using LocalDiscovery (e.g. put them on the same LAN behind a NAT with no metaconnection to each other) - Make one ping the other. Expected result: - The two nodes should ping each other without any packet loss, hopefully at

Hi, I am playing with LocalDiscovery again and have noticed that I do not see any LocalDiscovery broadcasts anymore. I am using tinc 1.1-pre9 in switch mode and have set LocalDiscovery = yes in tinc.conf. I do not see any broadcasts on any network and I also do not see anything in the debug output. What to do? -nik -- # apt-assassinate --help Usage: apt-assassinate [upstream|maintainer]

Am Freitag, den 25.09.2015, 22:45 +0200 schrieb Marcus Schopen: > Hi Guus, > > Am Freitag, den 25.09.2015, 17:46 +0200 schrieb Marcus Schopen: > > Hmmm ... I've tried "LocalDiscovery = yes" > > in /etc/tinc/mytunnel/tinc.conf already, but that didn't help. Config on > > client A is: > > > > --------------- > > Name = clienta >

Hi, I have tried the LocalDiscovery feature of tinc. The problem is that it also sends broadcast probes out the CPN interface *and* detects nodes on the VPN. A connection is then established through the tunnel, which effectively breaks connectivity between the two nodes. I do not think that discovering hosts on the VPN makes sense in any way. How can it be disabled? I could easily netfilter

Hi Guus, Am Freitag, den 25.09.2015, 17:04 +0200 schrieb Guus Sliepen: > Ok, that means by default the UDP NAT timeout on the Cisco is extremely > short. > > > I check the manual of the the Cisco NAT for any TCP/UDP > > timeout settings, but there is no way to modify anything like "keeps > > TCP/UDP connections alive". > > It wouldn't be called

Dear all, I have 3 nodes: A, B and C. C has external IP and A and B are behind NAT. It turns out A and B route their traffic via the C, which they ConnectTo with; this instead of getting connection details from one another and contacting eachother directly (mesh style). The reason is, as I conclude from tincd debug output, is that they see the peer as having a minimum MTU of 0. I suspect this is

Hello tinc users! Has anyone been able to get LocalDiscovery to work properly? I'm not quite sure what I need to do other than enable it in tinc.conf, and it doesnt seem to be working. Has anyone else tried it? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160901/5698fc86/attachment.html>

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

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now

With pleasure we announce the release of tinc version 1.1pre11. Here is a summary of the changes: * Added a "network" command to list or switch networks. * Switched to Ed25519 keys and the ChaCha-Poly1305 cipher for the new protocol. * AutoConnect is now a boolean option, when enabled tinc always tries to keep at least three meta-connections open. * The new protocol now