similar to: I've stumbled across weird chain of multiple failures

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

Try removing all MTU related settings from both sides. Allow tinc to learn on its own. " PMTU = 1436 ClampMSS = yes PMTUDiscovery = yes" in the config, " Address Family = ipv4" is likely not necessary, i would recommend removing it. " Device = /dev/net/tun" should not be used, unless tinc is having issues locating the tun device. however " DeviceType =

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

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

I can’t seem to find info about layer 2 tinc tap interface bridge with local physical nic. I have successfully created two nodes configuration with tinc acting as switch. My problem is ethernet packets only flow between two nodes and not to hosts on bridged nic. Example: Server 1 - eth0 bridged with tinc tap device, then bridge gets IP via dhcp server on physical nic subnet. Server 2 - local

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

Hello everybody, Thank you Fufu Fang for your quick reply: With tinc version 1.0.35 and the bellow options at 100% CPu load i get about 10 MB/s... PMTU = 1400 PMTUDiscovery = yes #Cipher = none Cipher = chacha20-poly1305 Digest = blake2b512 Tried Cipher = none as well and also got 10MB/s with 100% CPU on one thread the other three available threads are idle. With inc_1.1~pre17-1.1_amd64.deb

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?

Hi, i bought some VPS with KVM virtualization. I installed tinc 1.1-pre9 as usual... Have multiple servers with this working but now i got the following error... tincd -D -d -n NETWORK tincd 1.1pre9 (Jan 30 2014 11:09:17) starting, debug level 1 /dev/net/tun is a Linux tun/tap device (tun mode) Listening on 31.XXX.XXX.46 port 655 SIOCSIFADDR: No such device tun0: ERROR

connection will remain a TCP connection unless it is broken and restarted. Usually if I stop the client and wait for about 30 seconds to reconnect, there is a much greater chance that the MTU probes work fine, and in about 30 seconds MTU is fixed to 1416. Every time when the MTU probing fails, I see latency between 700 - 1000 ms with 32 byte pings over a LAN. Every time when the MTU probing does

Hi all, I followed the guide "simple-bridging-with-dhcp", which has two parts: http://www.tinc-vpn.org/examples/simple-bridging-with-dhcp-server-side/ http://www.tinc-vpn.org/examples/simple-bridging-with-dhcp-client-side/ I have altered two things to fit my needs, 1) DHCP server(host:pek1) is on client side ethernet, so I have bridged eth0 and tun1 together; 2) Network/Server/Client

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.

Hello everybody, I am doing some test with TINC and Windows 7 and I am having some issues with routing. (see attachment for the client configuration) The set-up I configured uses DHCP over the TINC tunnel and the Windows guests ends up with two gateways (one from its own network and one from the TINC network). The problem is that traffic when browsing the internet should go over the TINC tunnel

I'm been experiencing a very very odd problem for the past several weeks and am throwing it out in case someone can shed some light on it for me. There is a single box on our tinc mesh which can be pinged from all hosts, but cannot ping any. It is not limited to ping, the box cannot communicate over tinc. tinc is running in router mode for this mesh. ~30 other nodes function normally,

> 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

Hello. Finally I discovered the mailinglists and subscribed. Before, I were in #tinc, pinging guus all the time with various stuff/problems/patches/etc. So... the problems, in no particular order. 1) Quite often, after re-starting a client (I run in tunnelserver mode), no packets are flowing. Tcpdump shows packets being sent from client but nothing gets received, and on the server both send

Hi, I am running tinc on alpine linux 2.7.8 in 2 seperate environments. The first environment is running for about a month without any problems. The second environment causes some trouble. It looks like a memory leak on the client side. tincd.conf: ConnectTo=ServerHost Device=/dev/net/tun Mode=switch Name=ClientHost PMTUDiscovery = yes DeviceType=tap PriorityInheritance = yes

Hi, I've observed this strange behaviour for a while in my test environment. It looks like that all problems gone away when I switch to "hub-mode" instead of switch mode. Does tinc still work properly in switch mode when I transport vlan tagged traffic within that tunnel? In my environment the side, which is receiving arp requests from the wired interface, is running out of

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

Hi all, I have two nodes, connected to a switch, using Tinc 1.1 from git. They connect each other with sptps, and to other nodes in the Internet with old protocol because they have Tinc 1.0. There is no problem with remote nodes, but between my 2 local nodes, they see 1518 PMTU. But local network is 1500 MTU !!! So nodes can ping each other but larger data does not go. test1=sllm1 test2=sllm2