Telnet session drops 1

[Steve Bowman]

I have a situation where telnet sessions drop after 4-6 minutes (I have seen it in as few as 4 and few longer then 6) I have looked at idelout and have nothing setup and I have even from a client side turned on keepalives and sessions still drop. I have been screwing around with this for several days and have not even been able to scratch the problem. Any suggestions or ideas appreaciated.

Steve Bowman
Independent Technology, Inc.
CA, USA

 

[KenCunningham]

Hello Steve, there was a discussion of a similar issue in thread58-760504 if that helps.

 

[Steve Bowman]

I actually tried the suggested thread before I posted this, I should have mentioned that.

Steve Bowman
Independent Technology, Inc.
CA, USA

 

[Pilot1]

I had the same problem running SCO Telenet sessions over VPN's to all remote branch offices. As we hacked out the problem we found out in the logs (PIX 501 at headend) that the SCO server host(5.0.6) was closing the connections because of the idle periods at the remote end e.g. user going to lunch and being logged off. We solved the problem by editing some TCP timeout scripts, creating two timeout profiles, and two Telnet ports 23 - default and 823 for remote clients. There is a SCO knowledgebase article that explains how to do this, and if anyone wants it, I have it archived at work and can post it. It totally solved the problem.

 

[Steve Bowman]

I should have posted the final outcome and did in the PIX forum and forgot I had cross posted here. The problem was Telnet sessions dropping in 4-5 minutes on the (inside) we did not expect the PIX at first because the fact that since this was "local" traffic the PIX should not have been involved. The real issue was.
The PIX had an improper static setup the (outside, inside) was correct but they aslo had an (inside,outside) configured not really needed in this application but what was happening was the PIX was ARP proxying its Local Interface MAC address as being the Unix Boxes IP Address so when this ARP would broadcast anyone currently connected to the unix would get an invalid ARP and drop the connection.
Resolution was to correct the PIX configuration.
The company responsable for the PIX dragged out this trouble shooting process for days longer then needed because they where hung up on saying the PIX was not involved in the conversation because this was "local traffic" So lesson is when the obvious is eliminated it must be the least expected!

Steve Bowman
Independent Technology, Inc.
CA, USA