similar to: LocalDiscovery

Hi Peter and other Libvirt-Users, Thank you, I greatly appreciate your response. The diagram I provided may be a little misleading, so I have attached a new diagram (also available here: https://i.imgur.com/X3nFMCz.png ). I think I also need to provide some more detail about my scenario here: These physical nodes are provided to me by "bare-metal cloud" providers like Scaleway / OVH /

Hello Libvirt Users, I would like to setup a two node bare-metal cluster. I need to guidance on the network configuration. I have attached a small diagram, the same diagram can be seen here: https://i.imgur.com/SOk6a6G.png I would like to configure the following details: - Each node has a DHCP enabled guest network where VMs will run. (eg, *192.168.1.0/24 <http://192.168.1.0/24>* for

I use tinc everyday to access a private network at work, and i have three different public IPs to "bootstrap" other vpn clients so that a device like my laptop can always be on vpn wherever i go. As there is will all networks, there are some maintenance costs associated with tinc, one of which is making sure that all certs in the "hosts" folder are the same on all

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]

We are testing tinc inside Google Compute within a single region and an external region. Two boxes 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 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*

First off, I would like to express my appreciation for the tinc software, it has been such a great vpn solution for what i need, its amazing. I am setting up another node on the vpn. "KVM" is my public facing node, "MacbookAir" is my workstation, "NewNode" is my node i have recently configured and the one with the issue presumably. NewNode and MacbookAir are on the

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

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

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!

Hello, I have 4 VM's running in Microsoft Azure. They all should have similar configurations except from their tinc ip addresses of course. They run tinc 1.0.24. I have a 5th machine, my development machine. I am able to ping all 4 VM's from my computer when I start tinc from the commandline (tincd -n innomeer -D -d 2). 3 of the computers also work ok when running tinc as a service

Hello Libvirt-Users! I have a quick question about the qemu guest agent. Is it possible to use the guest agent from inside the guest in order to query the name of its own domain? For example, I use a base-image.qcow2 with a baked-in hostname. I would like to include a little tool in my guest image to change the hostname to the name of the domain. Is this sort of thing possible? -Cobin

I absolutely love tinc and the features it brings to the table, and also the stability it provides. My one issue with tinc is that managing certs between different nodes seems rather inconvenient. By using "tincd -n vpn -D -d5" I can see when a cert fingerprint is denied. Does tinc have features like that of puppet where you can list the pending certs and accept or deny them? see

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,

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 >

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

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

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

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