similar to: several problems....

Hello, I have been reading through the documentation and trying to set up a very small VPN as a test for a larger rollout that I would like to complete in the future but cannot get this working. The configuration seems like it should be relatively simple, so I'm most likely missing something basic but I just cannot see what I'm doing wrong. At the moment I am trying to get this working

using 1.0pre5 A: tinc.conf ------------ Name = A PrivateKeyFile = /usr/local/etc/tinc/vpn/rsa_key.priv Device = /dev/tap0 ConnectTo = B A: tinc-up --------- #!/bin/sh modprobe ethertap ifconfig tap0 hw ether fe:fd:00:00:00:00 ifconfig tap0 192.168.0.3 netmask 255.255.0.0 ifconfig tap0 -arp B: tinc.conf ------------ Name = B PrivateKeyFile = /usr/local/etc/tinc/vpn/rsa_key.priv Device =

> - Indirectdata finally REALLY REALLY works now! > - More precise debug messages Hmmm ... I can't prove that using the CVS code I checked out this morning. Everything works like yesterday: I can ping the peer but I canot go beyond: *** SERVER *** Jun 27 09:04:56 lemon tinc.9[10186]: tincd 1.0pre3 (Jun 27 2000 08:53:56) startin g, debug level 4 Jun 27 09:04:56 lemon tinc.9[10186]:

Hello, I'm trying to test a tinc vpn between two Linux hosts on the same ethernet. If I start tinc on both sides as 'tinc -n test --bypass-security --debug=5' I can ping both machines from each other and tcpdump shows that the packets pass through the tun-device created by tinc. Connection from 192.168.192.17 port 32852 Sending ID to (null) (192.168.192.17 port 32852): 0 helix 17

Hi, I've been running tinc for a couple of months and it's great, but I have a periodic problem which maybe you guys can figure out. I operate a 3-node tinc VPN, lets say A, B and C. A / \ B --- C The problem is that after a while, node C can't exchange data with node B. It works fine (ping and other traffic) for about 10 minutes, then fails. Here is some debug

Here are a few facts that should make things clearer. Regarding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of

Hi. I have few questions out of curiosity.. Cant help for now with your problem... What version is crashing? 1.1 or 1.0 ? How your network is segmented..? I use tinc myself here a lot too (1.0) but my network is very segmented. I use switch mode and handle routing myself, so mesh links arent large.. I would NOT go beyond 30 nodes for full auto-mesh.. its already like 435 edges... Regards,

Hi there I have the following setup Home - Main Tinc server with public IP running on PfSense work - tinc client running behind a CISCO ASA firewall with public IP running on Windows 10 offsite - tinc client running on tomato router behind a double NAT Home & offsite connect & i can see all PCs & devices & connect to them easily, on either side work to Home or offsite connects

Thanks for answers. I think its now flaw.. but design.. Tinc auto-mesh is very very handy. You just need to avoid flat networks. There is also IndirectMode w/ forces nodes to be switched by intermediate node... but I would be cautionus how its used. I use it myself for certain nodes behind NATs where they cannot be connected to, so always connect node handles switching for them. You noticed it

Hello! I have encountered a bug using tincd with Microsoft Windows: Below you'll find my Setup and my Logs. In short, i do the following: 1. office running tincd 1.0.7 and waiting for connections (no ConnectTo, but this does not resolve the issue) 2. the supporter starts up tincd 1.0.7 on windows (native) 3. ping from windows ("support") to the office: Here the error occours:

Hello, I have a problem connecting to one of my computers using tinc 1.0.x on Windows. It used to work, now it suddenly stopped (and nothing changed :) ) We have a server with a known ip address and port forwarding set. All computer connect to this server. I can ping from my computer (laptophenk) to the server and some other computers but not to jeffrey2015. When I set tincd to -D -d4 I get ( I

Hello, I have a problem connecting to one of my computers using tinc 1.0.x on Windows. It used to work, now it suddenly stopped (and nothing changed :) ) We have a server with a known ip address and port forwarding set. All computer connect to this server. I can ping from my computer (laptophenk) to the server and some other computers but not to jeffrey2015. When I set tincd to -D -d4 I get ( I

I would like to discuss the following commit: https://github.com/gsliepen/tinc/commit/4a0b9981513059755b9fd15b38fc198f46a0d6f2 ("Determine peer's reflexive address and port when exchanging keys") This is a great feature as it basically allows peers to do UDP Hole Punching (via MTU probes) even when both are having their source ports rewritten by a NAT, which is extremely useful.

I did notice the that interface we have named br-lan did not have the proper broadcast and netmask information. I adjusted that and it looks like its now connecting but still running into issues. Here is a snipet from the new system we are trying to connect in (from the /var/log/tinc.log file) 2018-03-15 22:57:26 tinc.NETNAME[871]: Read packet of 74 bytes from Linux tun/tap device (tun mode)

Thank you for your response. Yes, I know something changed, hence the smiley. I have looked at the code (I was able to build it under the new windows bash). It turns out that the error was on a udp receive, not a tcp connection. Didn't know you would get this error. Anyhow near the location of the error there was a remark about IPv6. I hadn't looked at that yet. So I turned IPv6 off at

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,

Hi, thank for getting back. I'll answer the questions, but I've already gave up on tinc and switch to zerotier-one. On 2020-07-27 5:10 p.m., borg at uu3.net wrote: > Hi. I have few questions out of curiosity.. Cant help for now with > your problem... > > What version is crashing? 1.1 or 1.0 ? 1.1 is crashing > > How your network is segmented..? > I use tinc myself

Hello, I am having troubles with the following configuration in that it produces the following errors: *Masterserver:* On the server (yea, I know) side is a Linux machine called "*masterserver*". It should have a VPN IP of 192.168.2.1 and it sits behind a pretty generic ADSL Router (with port 655 forwarded) which can be found via a dynamic host address. A small snippet of errors this

Lets view your tinc.conf On February 26, 2016 6:41:30 PM GMT+03:00, Mike Purvis <mpurvis at clearpathrobotics.com> wrote: >Hi Maxim, > >I'm having the same result, though I got some more output with debug >level >5; it's definitely failing to create the specified tincdev0 network >device. >Is there something I need to change on OS X to enable that? See: >

Thanks for replying so quickly Guus. I will try increasing the re-keying time to 86400, and am now running the servers in debug 5 mode logging to a file, so will get all output. Its interesting what you say about UDP being given lower priority, the two end points of this VPN are actually within the same data center, but are being routed within the DC's core routers (because its going