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>
Etienne Dechamps
2017-Sep-13 19:02 UTC
Packet capture to analysis the tinc connection close
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>