Hi Ben, The ping we initiated was to see if the VPN itself was dropping. You are correct, this remote user has moments they have no activity on the telnet session. At five minutes, the connection terminates.
I've gone through all TCP settings on both VPN devices. Everything is set beyond 5 minutes at 30 or 600 minutes. The telnet software itself doe NOT have a "keep alive" setting. Even if the user is in the middle of an order, typing, the connection gets dropped so it's not related to activity within the telnet session. We have clients on our side of the firewall that are NOT having this problem. This one remote user is the only connection that is experiencing this. I'm on the phone with Sonicwall techs now. They state everything is set correctly on my side. We're doing a packet trace now. Thanks, Tom -----Original Message----- From: Ben Scott [mailto:[EMAIL PROTECTED] Sent: Thursday, May 01, 2008 10:12 AM To: NT System Admin Issues Subject: Re: Time out issue On Thu, May 1, 2008 at 8:37 AM, Tom Strader <[EMAIL PROTECTED]> wrote: > We even started a ping to an IP on the same subnet. Ping never blinked but > at 4 minutes the Telnet session dies. [...] > There is a timeout value for NAT translations and packet streams.. ICMP is stateless; each Echo Request is independent from all the others. So if you're running "ping -t", the NAT doesn't see that as a "connection", it sees it as a bunch of individual Echo Request messages, over and over again. So that will be a different scenario vs Telnet. Telnet uses TCP, which is statefull -- there's a connection setup, which all following datagrams will be associated with. Are these Telnet sessions sitting idle (no keystrokes or screen updates)? I'm guessing there has been no activity, so no datagrams are being sent as part of that TCP connection. The NAT eventually decides the connection has died without being closed properly, and drops the state it uses to keep track of that TCP connection. If that's the problem, look for a feature in your Telnet software for something called "keep alive". That will cause the system to send an occasional datagram, even though there's been no real activity. That should keep the NAT happy. If the NAT is just putting a hard limit of 4 minutes on even active connections, then the only solution is to adjust that limit. Most good NAT implementations let you adjust the limits independently. It's generally fine to have a very long (days, weeks, even months) limit for active sessions. As long as there's data flowing, we don't care how long that connection is being used for. But be cautious about setting the "idle timeout" too long. The NAT may accumulate a lot of state about dead connections, leading to resource exhaustion in the NAT. How long "too long" is depends on the capabilities of your NAT, the total load, and how often connections die without a proper TCP close. -- Ben ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~ ~ Upgrade to Next Generation Antispam/Antivirus with Ninja! ~ ~ <http://www.sunbelt-software.com/SunbeltMessagingNinja.cfm> ~
