Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 482
  • Last Modified:

Client Access Disconnects

We are experiencing clients being disconnected at random times but frequently.
I have worked with both Cisco and IBM and am on my own now. I would like to know how to proceed.
PC5250 Traces (IBM Client Access Traces) show the the Client (User's Computer) is receiving a Socket Error 10054 (Connection reset by peer)
the TRCCNN IBM server trace shows the ACK for the RST on the server.
Wireshark shows that Client is requesting a Retransmission .
However we have multiple clients that are experiencing this and it just started out of the blue about a month ago. I think the problem might be application related but i'm in the dark on how to troubleshoot something like that.
0
mpossible
Asked:
mpossible
  • 5
  • 3
1 Solution
 
mpossibleAuthor Commented:
Anyone have any ideas ? Please help!
0
 
BlueComputeCommented:
It looks like you're losing TCP packets on your network.  Packet loss indicates duff network hardware, drivers, switches, cables, NICs etc.  Connect the client to the server direct through a new switch or CAT 5 cable - can you replicate the problem?
0
 
mpossibleAuthor Commented:
Well i suppose we could ;however, this is at a remote location and it would be costly to drive out there. I have captured and analyzed wireshark captures from the same side of the network as the server and they seem normal and no one on that side appears to be disconnecting.  All the clients that are disconnecting are on the remote side of the VPN.
The captures on the ASA show no dropped packets so I might have too easily dismissed the ASA 5505s . What I discovered today was some ISAKMP keepalives that had been tampered with (Probably because of the VPN going up and coming down all the time) I disabled the keep alives in that tunnel-group and it's only been 2 hours but no one disconnected today.
I'll post back tomorrow.

I can not recreate the problem for sure, Client Access gives the Disconnect screen for several reasons and not knowing the exact reason (aside from Socket Error 10054) makes it very challenging. I did go there and replace the entire Layer 1.  Tried switching out the switches ( Layer 2 ) and the same thing happened.  Even threw in a Layer 3 device closest to the clients to segment the network and explore that option.
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
mpossibleAuthor Commented:
Well so far no one has disconnected today at all.
0
 
BlueComputeCommented:
Sorry mpossible, I didn't realise you were using VPN, I thought you meant 'client access' as in general client access to the server rather than IBM Access Client.

VPN drops are sometimes associated with incorrect MTU size causing fragmented packets.
0
 
mpossibleAuthor Commented:
Ah .perhaps I should have done a little more explaining . Thank u blue for all the help. However it seems now that when they connect to a public ip address that is 1to1 natted to the server ip. They get disconnected .however the vpn sessions do not. This is opposite of what was happening before.
0
 
mpossibleAuthor Commented:
Never mind about the disconnects to the public IP not through the VPN that was a couple of configuration errors. They weren't really getting disconnected, they were never connecting.
all is well after the editing of the ISAKMP keepalives in the tunnel-group .
0
 
BlueComputeCommented:
Wikid.  Glad you got it sorted and sorry I couldn't be more helpful.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

NEW Internet Security Report Now Available!

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out this quarters report on the threats that shook the industry in Q4 2017.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now