similar to: SSH connection hangs on shell commands when used through tinc

Hello! I have set up tunnel between a FreeBSD machine and Windows Vista. Tunnel is established, but when I try to ping either end ping fails. I have temporarily switched off firewalls on both machines, no luck. Here is client tinc.conf on Vista: Name = lenovo_client ConnectTo = lenovo_server Interface = tinctap Subnet = 10.20.40.0/24 Sevrer tinc.conf on FreeBSD: Device=/dev/tap0

Hello! I was trying to set up a VPN between a FreeBSD and Windows box. I didn't have to invent anything, as this connection worked before, but I had to reinstall WinXP from scratch. Being too lazy to use previous setup from a backup I set up it once again by memory. It didn't work, so I started to refer to a working connection between FreeBSD and Ubuntu. Then I found out that on my box

Well this has had me stumped for days now. For months I've been using tinc in TCPOnly because I always received the unknown host error when using UDP. On Monday, i set the flag IndirectData = yes in my host files, and removed the TCPOnly line. Initially, everything worked great. My throughput increased from 600KB/sec to 2MB/sec between the sites. However, I also did some testing with

Hi, I´m using Tinc for several years, but I didn´t fix a performance problem. There a about 20 nodes in this network. Master: 10.0.0.12 (dedicated host in a datacenter, debian, 100mBit port) tinc.conf: Name = TincKnoten12 AddressFamily = ipv4 Interface = tun ProcessPriority=high mode = router #DirectOnly = no Compression=0 PMTUDiscovery = yes #IndirectData = yes #ReplayWindow = 64 #ConnectTo

Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes. When the server does not receive a PMTU request back from one of the clients even when the packet size is very small (say 164), then it reverts to TCP. Should i turn off PMTUDiscovery or should it be ok to leave on? It takes a very long time to do simple pings (1 second or so), so i wonder what else i can do?

On Tue, Apr 10, 2018 at 03:36:08PM +0200, Hans de Groot wrote: > hosta  <--> hostb  <-->  hostc > > Hosta and hostc are not directly connected via tinc. But both are conncted > via hostb (I called my network tincnet). This works fine I can ssh from > hosta to hostc and vice versa without any problems. > > hostc is in a whitelisted iprange at some service

> Currently, i have nodes with PMTUDiscovery =yes and ClampMSS = yes. Hello, these features were introduced in 1.0.13 correct ?? I also understand that the two settings are by default "yes" if not explictly set to "no" in the config file. what may happen if I have a network with mixed versions from 1.0.11 and 1.0.13, where the older daemons do not implement that feature

Hi there, I am using tinc since some monthes. I think the basic idea of extending vpn to a mesh of systems via tun/tap is great. And I think it is one of the useable developments compared to the much more complex vpn solutions I had used in the past. Great work. Setting up tinc I have fought with the configuration (and with the concepts) for a while as I have found no example that covers my

Hi, I upgraded some of my Tinc nodes from 1.0.8 recently and found something strange. All of a sudden, the vpn would not work as a full-mesh. Certain nodes were not contactable. I re-generated my rsa-keys, and checked my configuration. My vpn uses the following in tinc.conf, as I am routing both ipv4 and v6. === name = node1 mode = switch AddressFamily = any PMTU = 1280 PMTUDiscovery = yes

Dear all, we have a very strange problem, - we have 3 VPN endpoints - all are in one NETWORK - all daemons come up and connect without any problem and normally we have no problem working through the VPN but in some cases the connection does not work because the traffic leaves the TAP interface on one VPN endpoint but never arrives on the other end, the similarities between the packages seem to

The server has a 1G symmetrical fibre line. It has been speedtested to various local servers to be close to 800-900M. When there is only a single client, there isn't much problem and as soon as the connection is made, the ping time through to tunnel is a respectable 30ms. As soon as a few more clients are connected, ping time degrades to hundreds and sometimes seconds and with dropped packets.

Aloha! I am new to tinc and I like to figure out my own issues before asking but I am not sure of my next step here. I am not sure if the problem is the VPN configuration or in my network. I will try to be as through as possible. I have two computers that are CentOS with the latest tinc from their respective repositories. Server A is behind a Sophos XG and Server B is behind a Ubiquiti Edge

With pleasure we announce the release of tinc versions 1.0.33. Here is a summary of the changes in tinc 1.0.33: * Allow compilation from a build directory. * Source code cleanups. * Fix some options specified on the command line not surviving a HUP signal. * Handle tun/tap device returning EPERM or EBUSY. * Disable PMTUDiscovery when TCPOnly is used. * Support the --runstatedir option of

With pleasure we announce the release of tinc versions 1.0.33. Here is a summary of the changes in tinc 1.0.33: * Allow compilation from a build directory. * Source code cleanups. * Fix some options specified on the command line not surviving a HUP signal. * Handle tun/tap device returning EPERM or EBUSY. * Disable PMTUDiscovery when TCPOnly is used. * Support the --runstatedir option of

With pleasure we announce the release of tinc version 1.1pre16. Here is a summary of the changes in tinc 1.1pre16: * Fixed building with support for UML sockets. * Documentation updates and spelling fixes. * Support for MSS clamping of IP-in-IP packets. * Fixed parsing of the -b flag. * Added the ability to set a firemall mark on sockets on Linux. * Minor improvements to the build system.

With pleasure we announce the release of tinc version 1.1pre16. Here is a summary of the changes in tinc 1.1pre16: * Fixed building with support for UML sockets. * Documentation updates and spelling fixes. * Support for MSS clamping of IP-in-IP packets. * Fixed parsing of the -b flag. * Added the ability to set a firemall mark on sockets on Linux. * Minor improvements to the build system.

Hello, all! I have many questions about tap device architecture. What is a right way to calc mtu on TAP device to avoid fragmentation on real eth device? I suppose TAP MTU = 1500-8(UDP)-20(IP)-18(Ethernet) = 1454. So I'd set 1454 for tap device: "ip link set mtu 1454 dev eth0" I'm not shure about what is the exact size of ethernet frame header, which tap device use in switch

Hi there, we are using tinc in switched mode for over a year now, currently with 18 clients which are connected 24 hours a day and many which aren't connected the whole day, also. If i'm reading the changes from 1.0.9 to 1.0.10 and 1.0.11 correctly, tinc should work now, although "TCPOnly = yes" isn't set in the config files of clients which are behind a NAT firewall, e.g. a

We run tinc in a linux environment in which it sits there waiting for connections from the clients. All clients are configured to only have one ConnectTo which points to this server. We're seeing in the server log that as soon as a client's connection is activated, a whole bunch of "Flushing x bytes to that host would block" is logged and the whole vpn is bogged down and has

Hello, I am tying to create tinc vpn for the ~1000 nodes and was thinking why meta connections are needed at all if I only need static configuration where every node knows addresses of other hosts and due to the amount of traffic any indirect connections will not work, so DirectOnly=yes is a must and then passing around routing information is not needed, right? Currently I have 10 nodes