Intermittent TCP connect issues when using tinc 1.0.23 and IPv6

[Tom Parrott]

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 modes

I 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, tomp at tomp.co.uk 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, tomp at tomp.co.uk 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, tomp at tomp.co.uk 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
>>> tinc at tinc-vpn.org
>>> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>> _______________________________________________
>> tinc mailing list
>> tinc at tinc-vpn.org
>> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20131223/6a8a5ac1/attachment.bin>