search for: localdiscovery

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-assas...

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...

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/...

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 > > AddressFamily = ipv4 > > Interface = tun0 > > ConnectTo = host > > PingInterval = 30 &g...

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 witho...

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 (104.154....

Hi, I'm using LocalDiscovery = yes to let tinc clients connect directly behind a NAT. Problem is that clients only start to talk directly after pinging each client from each client. Is there way to force direct connection after starting the tunnel. Ciao!

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, LocalDiscoveryAddress, but it was unclear what I should set that to. Should it be the LAN address that I want them to com...

...a reason it's flip flopping? Is that expected? Am I doing > something wrong? No, you are not doing anything wrong. Although I've not seen this kind of flip-flopping behavior myself, it is possible this behaviour occurs, although it should only happen in the first 10 seconds or so. When LocalDiscovery is enabled, tinc tries to send probe packets to both the address it learned from its TCP connections and to the local network. When receiving a valid packet, it notes the source address of that packet. If it is different from the source address of the previous valid UDP packet, a log message is pri...

...are created as follows: /etc/tinc/test/tinc_test_1 Subnet = 10.240.0.0/16 Subnet = 10.240.0.4/32 Address = 104.154.59.151 /etc/tinc/test/tinc_test_2 Subnet = 10.240.0.0/16 Subnet = 10.240.0.5/32 Address = 104.197.132.141 /etc/tinc/test/tinc.conf Name = $HOST AddressFamily = ipv4 Interface = tun0 LocalDiscovery = yes 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_tes...

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 a...

Hi, I would like to suggest a couple of enhancements for the LocalDiscovery part: - LocalDiscoveryInterval=x how often to do the local discovery, 0=once - LocalDiscoveryAddress=y to what broadcast address to send the discoveries. like how NTP does this. this is usefull when there's a router between two segments which doesn't route the broadcastst e.g. 19...

...cally/directly anymore, which means > > higher latency and outgoing traffic. I don't see any blocked packages on > > the client's firewall. Is there a way to let them talk directly again? > > This is probably because the Cisco doesn't support hairpin routing. Add > LocalDiscovery = yes to tinc.conf on the clients, that way they can > detect each other's LAN address and do direct traffic again. Hmmm ... I've tried "LocalDiscovery = yes" in /etc/tinc/mytunnel/tinc.conf already, but that didn't help. Config on client A is: --------------- Name = clie...

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

...ping? Is that expected? Am I doing >> something wrong? > > No, you are not doing anything wrong. Although I've not seen this kind > of flip-flopping behavior myself, it is possible this behaviour occurs, > although it should only happen in the first 10 seconds or so. When > LocalDiscovery is enabled, tinc tries to send probe packets to both the > address it learned from its TCP connections and to the local network. > When receiving a valid packet, it notes the source address of that > packet. If it is different from the source address of the previous valid > UDP packet,...

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 >

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

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

...running tinc-up until a working connection is made, and which on Windows will also change the network interface link status accordingly. * Tinc now tells the resolver to reload /etc/resolv.conf when it receives SIGALRM. * Improved error messages and event loop handling on Windows. * LocalDiscovery now uses local address learned from other nodes, and is enabled by default. * Added a "BroadcastSubnet" option to change the behavior of broadcast packets in router mode. * Added support for dotted quad notation in IPv6 (e.g. ::1.2.3.4). * Improved format of printed Subnets, M...

...running tinc-up until a working connection is made, and which on Windows will also change the network interface link status accordingly. * Tinc now tells the resolver to reload /etc/resolv.conf when it receives SIGALRM. * Improved error messages and event loop handling on Windows. * LocalDiscovery now uses local address learned from other nodes, and is enabled by default. * Added a "BroadcastSubnet" option to change the behavior of broadcast packets in router mode. * Added support for dotted quad notation in IPv6 (e.g. ::1.2.3.4). * Improved format of printed Subnets, M...