tinc - Sep 2017 - Packet capture to analysis the tinc connection close

And, I ran a constant ping from the tinc client’s IP to the tinc server’s IP, it
shows, the pings are all successfully back and forth, no any packet loss during
the connection drop happens, so will this help to exclude any NAT/firewall cause
the connection drop?

And as you saw from the earlier screen shot, when it happens, it drop all tinc
connections, and those connections are for different direction of tinc servesr,
and the packet capture is just show one of the connections.

I do realize the connection drop in the picture happens 10 mins, but the tinc
client is direct connect to SP with public routable IP, without any
firewall/NAT. Just trying to know if there’s any other reason might cause this?

And BTW, this type of connection drop is not regularly with pattern, sometimes
it happens, sometimes it doesn’t.

> On 8 Sep 2017, at 1:18 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 
> On Tue, Sep 05, 2017 at 12:27:59PM +0800, Bright Zhao wrote:
> 
>> Recently, one of my tinc client always suffer connection drop, I was
suspect the connection was not stable to cause this issue, and BTW, I’ve set the
PingTimeout to 10 seconds already, but this situation still happens a lot
sometimes, but when the connection drop happens, the connection recovery pretty
fast, normally in a minutes.
> [...]
>> As you saw from https://ibb.co/mRyG3a <https://ibb.co/mRyG3a>,
the connection get drop and re-establish very frequently,
> 
> It looks like it happens almost exactly 10 minutes after a connection
> was established. I suspect that there is a firewall or NAT device in
> front of the client that drops any TCP connection after 10 minutes,
> regardless of whether there was any recent traffic over that connection
> or not. There is not much tinc can do about that, besides reconnecting
> when it happens.
> 
> -- 
> Met vriendelijke groet / with kind regards,
>     Guus Sliepen <guus at tinc-vpn.org>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc

On Fri, Sep 08, 2017 at 06:35:41AM +0800, Bright Zhao wrote:
> And, I ran a constant ping from the tinc client’s IP to the tinc server’s
IP, it shows, the pings are all successfully back and forth, no any packet loss
during the connection drop happens, so will this help to exclude any
NAT/firewall cause the connection drop?
> 
> And as you saw from the earlier screen shot, when it happens, it drop all
tinc connections, and those connections are for different direction of tinc
servesr, and the packet capture is just show one of the connections.
> 
> I do realize the connection drop in the picture happens 10 mins, but the
tinc client is direct connect to SP with public routable IP, without any
firewall/NAT. Just trying to know if there’s any other reason might cause this?
> 
> And BTW, this type of connection drop is not regularly with pattern,
sometimes it happens, sometimes it doesn’t.
Tinc itself wouldn't cause these kind of reconnections. It clearly sees
a timeout, which means it didn't receive a response to its PING packets in
time. Unfortunately, there are two classes of devices that are not
uncommon that could cause this to happen: consumer ADSL/cable modems
tend to have very short timeouts on connections or NAT mappings, and
some providers just randomly drop long-lived connections for various
reasons (mainly because they think you should only browse webpages,
which only requires short-lived TCP connections, which is also easy to
analyze, and they want to discourage VPNs, VoIP et cetera).

But just to be sure, just set up a TCP connection between the two nodes
using netcat or socket for example, send something over that connection
every minute, and see how long it lasts.

You can also try to reduce PingInterval to, say, 30, and see if that
improves anything.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170913/be6a3eaa/attachment.sig>

It seems like that kind of problem could be solved by making sure that tinc
continues PINGing over TCP metaconnections even when an UDP tunnel is
established, to keep the metaconnection alive. In fact I was under the
impression that the 1.1 branch already did that or that I had submitted
some code to do that at some point in the past, but it looks like I maybe
be misremembering things.

On 13 September 2017 at 16:13, Guus Sliepen <guus at tinc-vpn.org> wrote:
> On Fri, Sep 08, 2017 at 06:35:41AM +0800, Bright Zhao wrote:
>
> > And, I ran a constant ping from the tinc client’s IP to the tinc
> server’s IP, it shows, the pings are all successfully back and forth, no
> any packet loss during the connection drop happens, so will this help to
> exclude any NAT/firewall cause the connection drop?
> >
> > And as you saw from the earlier screen shot, when it happens, it drop
> all tinc connections, and those connections are for different direction of
> tinc servesr, and the packet capture is just show one of the connections.
> >
> > I do realize the connection drop in the picture happens 10 mins, but
the
> tinc client is direct connect to SP with public routable IP, without any
> firewall/NAT. Just trying to know if there’s any other reason might cause
> this?
> >
> > And BTW, this type of connection drop is not regularly with pattern,
> sometimes it happens, sometimes it doesn’t.
>
> Tinc itself wouldn't cause these kind of reconnections. It clearly sees
> a timeout, which means it didn't receive a response to its PING packets
in
> time. Unfortunately, there are two classes of devices that are not
> uncommon that could cause this to happen: consumer ADSL/cable modems
> tend to have very short timeouts on connections or NAT mappings, and
> some providers just randomly drop long-lived connections for various
> reasons (mainly because they think you should only browse webpages,
> which only requires short-lived TCP connections, which is also easy to
> analyze, and they want to discourage VPNs, VoIP et cetera).
>
> But just to be sure, just set up a TCP connection between the two nodes
> using netcat or socket for example, send something over that connection
> every minute, and see how long it lasts.
>
> You can also try to reduce PingInterval to, say, 30, and see if that
> improves anything.
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20170913/fdc38c29/attachment-0001.html>