search for: dechamp

...ion could be added to ADD_EDGE messages and stored in edge_t. Thoughts? [1] http://serverfault.com/questions/72112/how-to-alter-the-global-broadcast-address-255-255-255-255-behavior-on-windows (the long discussion in the comments of the second answer are particularly interesting) -- Etienne Dechamps

On 12 November 2015 at 01:15, fauno <fauno at kiwwwi.com.ar> wrote: > Etienne Dechamps <etienne at edechamps.fr> writes: >> (I realize that this means UPnP support could possibly be achieved >> simply by suggesting that the user spawn some standalone UPnP client >> process in the background from the tinc-up hook. That's not very >> user-friendly, th...

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

...g from the local address anymore and makes it revert to "classic mode" for a brief time. Then after a moment local discovery kicks in again and fixes the situation, until PMTU discovery happens again, and so on. I will continue investigating and try to come up with a fix. -- Etienne Dechamps

...gt; > Petr > > On Thu, Jul 14, 2016 at 12:18 AM, Rob Townley <rob.townley at gmail.com> > wrote: > >> Have anything to do with firewall locations, meaning home vs work vs >> public vs lockdown. Probably not it at all. >> On Jul 13, 2016 3:22 PM, "Etienne Dechamps" <etienne at edechamps.fr> wrote: >> >>> That's strange. Can you post a detailed log from the affected node (run >>> tincd -d5 -D), especially the initialization phase? >>> >>> On 13 July 2016 at 16:17, Petr Man <petr at madnetwork.org&gt...

...nterfaces, resulting in conflicts, and it all goes downhill from there. That would completely explain the weird phenomena you're reporting. If you make sure to use different IP subnets for VPN addresses and physical addresses, your problems should go away. On 14 February 2017 at 20:36, Etienne Dechamps <etienne at edechamps.fr> wrote: > 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...

On 11 November 2015 at 21:57, David Nicol <davidnicol at gmail.com> wrote: > it is entirely possible to write code that uses threads on Win32 and forks > on POSIX by abstracting the communication bits generically. Signalling could > work over pipes on both. > > https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152(v=vs.85).aspx Hum... yes of course, but I

On 09/02/2016 08:51 PM, Etienne Dechamps wrote: > What version of tinc are you using? tinc 1.1 already does what you want out of > the box: packets sent from node A to node B through node C will use a key that > A and B will negotiate between themselves. C doesn't have the key, and will > act as a blind relay. C will not...

...sides). - On zyklos (Linux), tinc was compiled from source from the "release-1.1pre10" git tag. On pegasus (Windows) tinc was installed from the downloadable package. - From where I'm standing this looks like a Windows-only regression between 1.1pre8 and 1.1pre10. -- Etienne Dechamps

Etienne Dechamps <etienne at ...> writes: > > You should mention your tinc version and the version of the > "TAP-Windows Adapter V9" driver for the virtual network device you're > using (i.e. the contents of "Driver version" as seen in the Device > Manager). > >...

...to A <---> C <---> D, which seems unlikely in such a topology, and can be fixed by directly connecting D to B. Thoughts? I get the feeling that Guus already thought about doing it this way and that there is some fundamental problem that would break my nice proposal :/ -- Etienne Dechamps

...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 levenlabs.com> wrote: > 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 > >...

On 12 November 2015 at 21:29, Guus Sliepen <guus at tinc-vpn.org> wrote: > On Wed, Nov 11, 2015 at 09:04:20PM +0000, Etienne Dechamps wrote: >> According to an online NAT check service, around 50% of NATs in the >> wild have this problem, making this a very real issue: >> http://nattest.net.in.tum.de/results.php > > Are you referring to port restricted NAT in the first graph? Because > that should stil...

...over metaconnections which are supposed to be trusted. Another performance issue with SPTPS over TCP is that it requires an handshake (which adds to initial communication latency), while the legacy PACKET mechanism doesn't. Thanks for taking the time to answer these questions. -- Etienne Dechamps

...IK won't arrive anytime soon. I have some ideas about implementing some crude form of Subnet access controls for centralized graphs in tinc 1.1 - it would basically look like StrictSubnets, but more flexible - I have not started on that yet. > ;) > > > Le 04/05/2015 21:50, Etienne Dechamps a ?crit : >> >> Whatever you do, keep in mind that tinc will always trust all nodes as >> long as they are part of the graph. It is not currently designed to >> deal with insider threats. Most importantly, that means anyone can >> impersonate any Subnet on a tinc netw...

...st fixes that I wrote (which are included in 1.1pre15). I think my fixes covered some of the causes of tinc misbehaving on standby, but not all of them. Are you able to reproduce the issue reliably? If so, can you please file an issue at https://github.com/gsliepen/tinc/issues (be sure to mention @dechamps) along with a verbose tinc log (-d5)? It would also help if you included the thread stacks that Process Explorer is showing you for tincd.exe while it's stuck. Oh, by the way, make sure you're using the TAP-Win32 driver that's bundled with tinc (9.0.0.9), not one of the newer versions...

...st fixes that I wrote (which are included in 1.1pre15). I think my fixes covered some of the causes of tinc misbehaving on standby, but not all of them. Are you able to reproduce the issue reliably? If so, can you please file an issue at https://github.com/gsliepen/tinc/issues (be sure to mention @dechamps) along with a verbose tinc log (-d5)? It would also help if you included the thread stacks that Process Explorer is showing you for tincd.exe while it's stuck. Oh, by the way, make sure you're using the TAP-Win32 driver that's bundled with tinc (9.0.0.9), not one of the newer versions...

On Fri, Dec 30, 2016 at 11:38:51AM +0100, Etienne Dechamps wrote: > I believe the reason why you're experiencing this problem is because tinc > does not use the connection TCP port to determine which port to send UDP > packets to. Instead, it uses the port that is *advertised* by the other > node. That's correct, at least for the ini...

...addresses of peers. * Add support for --runstatedir to the configure script. * Fixed linking with libncurses on some distributions. * Automatically disable PMTUDiscovery when TCPOnly is enabled. * Fixed removing the tinc service on Windows in some situations. Thanks to Todd C. Miller, Etienne Dechamps, Daniel Lublin, Gjergji Ramku, Mike Sullivan and Oliver Freyermuth for their contributions to this version of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: si...

...addresses of peers. * Add support for --runstatedir to the configure script. * Fixed linking with libncurses on some distributions. * Automatically disable PMTUDiscovery when TCPOnly is enabled. * Fixed removing the tinc service on Windows in some situations. Thanks to Todd C. Miller, Etienne Dechamps, Daniel Lublin, Gjergji Ramku, Mike Sullivan and Oliver Freyermuth for their contributions to this version of tinc. -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus at tinc-vpn.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: si...