Hi, Unfortunately the TCPOnly option did not work out as reliable aferall.
After several weeks of trying to resolve this issue I have had to switch to another VPN technology to try and rule out the timeouts as a network or machine issue.
Following links from the Tinc web site, I found PeerVPN: http://www.peervpn.net/This project seems to be very similar to Tinc's switch mode. It uses a tap interface, UDP transport and openssl, and allows multiple hosts to be connected together using a virtual mesh network.
Whilst the project seems younger than Tinc, it showed promise, so I switched our 3 site VPN from Tinc to PeerVPN to see if it solved the intermittent timeout issues.
Like our configuration of tinc, we are using PeerVPN to tunnel IPv6 subnets across the IPv4 internet.
After 3 days of using PeerVPN, we have not had a single timeout of TCP connections. Whereas with Tinc we were having multiple timeouts every hour.
This leads me to think there is some internal issue in Tinc that is causing these intermittent timeouts.
So that it may be of some help trying to resolve, here is a full run down of the settings I have tried with Tinc:
Versions 1.0.23 and 1.1 pre9 RSA encryption, Elliptic encryption, no encryption UDP and TCP transport Increasing UDP send/recv buffer Enabling IffOneQueue Setting KeyExpire to 86400 Disabling PMTUDiscovery Setting PMTU manually to 1300 and 1400 Setting process priority to high Switch and router modesI am surprised no-one else has experienced these issues, which leads me to think perhaps tunneling IPv6 inside IPv4 is unusual and I may have stumbled on a rare bug.
Suffice to say I am now confident that it is not the ISP dropping or de-prioritising UDP packets.
Hopefully this info will prove useful to improving Tinc, if you need more info I would be happy to supply it if I can.
Thanks Tom On 29/11/13 17:19, [email protected] wrote:
Hi,Just to follow up on this, after trying the re-keying option set to 86400, we were still seeing the intermittent tcp timeouts.However after switching TcpOnly option to on, we have now been having reliable communication for 8 hours or so, whereas before we were getting timeouts every couple of hours.Sop hopefully this has solved the problem, and it looks like UDP data was being dropped occasionally.Tom On 2013-11-28 17:57, [email protected] wrote:OK makes sense.How often would you expect to see the REQ_KEY and the PMTU probes occurring?They seem to happen quite a lot, is that normal? Tom On 2013-11-28 15:51, Guus Sliepen wrote:On Thu, Nov 28, 2013 at 02:52:45PM +0000, [email protected] wrote:Now that debugging is turned on properly, I am seeing some interesting lines:2013-11-28 14:48:48 tinc.dcvpn[31620]: Got type 2 MTU probe reply 1431 from rps (2001:1b40:5000:9::2 port 655) 2013-11-28 14:48:48 tinc.dcvpn[31620]: Got type 2 MTU probe reply 1431 from rps (2001:1b40:5000:9::2 port 655) 2013-11-28 14:48:48 tinc.dcvpn[31620]: Got type 2 MTU probe reply 1431 from rps (2001:1b40:5000:9::2 port 655) 2013-11-28 14:48:48 tinc.dcvpn[31620]: rps (2001:1b40:5000:9::2 port 655) RTT 0.49 ms, burst bandwidth 51.684 Mbit/s, rx packet loss 100.00 %Specifically the bit about 100% packet loss.Ignore the bit about packet loss, that is an estimate that doesn't work correctly yet.It was shortly after following by:2013-11-28 14:51:01 tinc.dcvpn[31620]: Got REQ_KEY from rps (2001:1b40:5000:9::2 port 55170): 15 rps rsukmhb 21 AA...I got a REQ_KEY request 12 times in 1s from rps.That is also normal for tinc 1.1. _______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ tinc mailing list [email protected] http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
