I think you've hit on something that's usually a problem with captures....there's usually far too much data rather than too little. The first place to start is by filtering the traffic capture based on the conversation that you want to follow. In your case, you can filter on: the IP address of the server to the IP address of the client on the telnet port. AND the IP address of the client to the IP address of the server on the telnet port. AND the IP address of the client to the broadcast address (to note the suspected session keepalives).
Once you've gotten the conversation down to a manageable size, note the time that the client connects and look at the correlating traffic in your capture. Note the time of the disconnect and look at the correlating traffic in your capture. Now look at the traffic in the minutes before the disconnect. It won't take long before you recognize "conversations" (syn,ack,fin) between the talkers. It would be very helpful to see captures from both sides of the PIX. This way it will be apparent if the server is sending something to the client that never makes it (or vice-versa). Hope this helps. Craig P.S. - You may want to check you time-outs in your VPN configuration if you haven't already. In most sample configs and in many production configs, the time-outs are set to 1800 seconds (30 minutes). If your sessions are dying after 30 minutes, it may be that the tunnel is being disconnected. At 02:27 AM 5/23/2002 -0400, you wrote: >To anybody that has experience with Sniffers. or more perhaps more >specifically, Priscilla- > >I'm trying to hunt down the culprit of Telnet Session disconnects >without Administrative or User interaction to invoke such action. > >The situation is Telnet clients on remote ends of PIX VPNs have their >sessions dropped without warning, and without Administrative action to >cause such sudden session endings. > >All users that connect to the same Telnet Server on the local subnet >never experience this problem. For the remote users that do experience >this problem, it usually occurs after roughly 30 minutes of inactivity. >This used to not be the case when all such remote clients were >connecting via private Frame Relay networks back to the Server in a >hub-n-spoke fashion.. Only since the switch to VPNs for connectivity to >the Telnet Server's Private Network has this anomaly arisen. > >The Telnet Server is a custom application service for Unidata DB Server >by Informix. It uses the standard Telnet port, and runs on NT 4.0. For >everything I can see in the registry referencing the Telnet App Service, >it doesn't specify any settings for keep-alive or session monitoring. > >Also, from the Unidata Application Server's point of view, the Server >thinks the user is still connected, so it never clears the session. >When the user finds his/her application rendering a Pop-Up dialogue >stating that the session was disconnected, and asks if they want to >reconnect, they choose "Yes" naturally. From the Server side, a second >session for that user is started, and the first session becomes an >"orphan" process (in my own words). This of course then causes a >problem of exhausting the limited number of users licenses, and >eventually causes users to not be able to get back on the system until >the old orphaned processes are administratively cleared. > >So, I open a case with Cisco, and they say "Slap a Sniffer on the Server >side of the network, and see what is causing the disconnects". They >also say that they are suspect that the Telnet Server is sending its >session keep-alives via Broadcast, and that by design of Security, the >VPN tunnels don't pass Broadcast Traffic. The Sniffer capture is >supposed to prove or disprove this. > >I put a Sniffer (Ethereal on Windows 2K) out and collected a Time Window >of data, but am at a loss as to how to identify the disconnect process >of a telnet session..Which is where I could use a few pointers. > >Could someone tell me what to look for in a session trace that >identifies a sudden termination of a specific telnet session (most >probably initiated by the server)?? > >Unfortunately, I'm not a very well experienced person in following the >SYN, FIN, PSH, ACK, SYN ACK, etc. process. But I want to learn! > >If I had the time and money, I'd go take a Sniffer class, but that's >another story. so, in the mean time, if someone would be kind enough to >point me in a direction on how to interpret and follow a sniffer trace, >I'd be eternally greatful. > >Thanks, >Mark Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44819&t=44793 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
