That's strange. You do have a rule to NAT the UDP traffic from outside to your Tinc host inside right?<br><br><div class="gmail_quote">On Tue, Oct 23, 2012 at 3:55 PM, Nathan Stratton Treadway <span dir="ltr"><<a href="mailto:nathanst@ontko.com" target="_blank">nathanst@ontko.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm running Tinc on a Linux machine inside my home network, connecting<br>
through a NATing router to a Tinc server out on the Internet.<br>
<br>
I've noticed that fairly frequently the SSH sessions I leave open (but<br>
unused) get aborted with a "Connection reset by peer" message. When I<br>
investigated closely, I found that after a period of inactivity my<br>
router times out the UDP "session" between the remote and local Tinc<br>
nodes, and thus any VPN traffic that then attempts to come in from the<br>
remote side toward my SSH client gets dropped by the router (because it<br>
no longer has a record of where forward the incoming Tinc packets).<br>
When this condition lasts long enough, the remote SSH server times out<br>
and closes the login session. (During this period, of course, other<br>
inbound traffic is also lost, e.g. syslog messages send toward my local<br>
machine, etc.)<br>
<br>
As soon as something on the local side needs to sent traffic to the<br>
office side, the local Tinc node sends new outbound UDP packets, the<br>
router re-establishes the virtual session between the two nodes, and all<br>
traffic resumes passing normally (at least until the next period of<br>
inactivity).<br>
<br>
<br>
I see that the PingInterval setting allows me to set a minimum inactivity<br>
period on the metadata connection, and that seems to be enough to<br>
prevent the TCP session from timing out in the router... but I haven't<br>
found any way cause Tinc to ensure the data/UDP "session" also stays<br>
active.<br>
<br>
(I'm currently using v1.0.x, but I checked the v1.1 documentation on the<br>
web site as well and didn't see any new features that appeared to apply<br>
to this situation.)<br>
<br>
<br>
So, I'm wondering if I've missed some aspect of the Tinc configuration<br>
that would address this issue, and (assuming I haven't) what other<br>
people have done when facing this situation?<br>
<br>
For now I can use a "ping" command or something running locally to make<br>
sure that I have some traffic sent out over the VPN toward to the office<br>
side once a minute or so -- but is seems cleaner to have Tinc itself<br>
monitor for "long" stretches of inactivity on the data link. Would it<br>
make sense to add functionality to Tinc to accomplish that (i.e. an<br>
option named something like "DataPingInterval" or<br>
"DataKeepaliveInterval")?<br>
<br>
Thanks.<br>
Nathan<br>
<br>
<br>
----------------------------------------------------------------------------<br>
Nathan Stratton Treadway - <a href="mailto:nathanst@ontko.com">nathanst@ontko.com</a> - Mid-Atlantic region<br>
Ray Ontko & Co. - Software consulting services - <a href="http://www.ontko.com/" target="_blank">http://www.ontko.com/</a><br>
GPG Key: <a href="http://www.ontko.com/~nathanst/gpg_key.txt" target="_blank">http://www.ontko.com/~nathanst/gpg_key.txt</a> ID: 1023D/ECFB6239<br>
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239<br>
_______________________________________________<br>
tinc mailing list<br>
<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a><br>
<a href="http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" target="_blank">http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc</a><br>
</blockquote></div><br>