Strange behavior in .NET web service client when NOT running as Local Administrator

We have encountered a very strange situation when we deployed an application at a customer site. This application is implemented as a service using C# on .NET 3. The application communicates with a web service that is written using gSOAP. In our .NET application, the classes that wrap the web service were created by performing "Add Service" in Visual Studio and referencing the WSDL. Communication is performed using HTTPS, but using port 35000.

What we are seeing is that when our application runs as "Local Administrator account" everything works well. However when our application runs as any other account, including "Local System account" and even a user account with network admin privileges, web service method calls sometimes time out. Other times they succeed but after a very, very long time, e.g. 100 seconds instead of less than 1 second as expected.

This customer is using Cisco switches in their network.

We have not encountered this behavior at other sites. Any insights or suggestions would be greatly appreciated.

From stackoverflow

• Any event log messages for timeouts, exceptions, etc?

  Is the application a windows service? Are you using RunAs to run under a different user context? Does it require desktop interaction or have any references to System.Windows.Forms?

  @Comment 1: Windows service, Web Service, WCF Service?

  Enable security auditing for both the local and remote machines for resources the service is likely to use.

  Another thing is to add debug level logging like this... (Sorry for the pseudo VB)

  Sub OnStart(args())
   LogToFile("Starting Service, processing arguments")
   'process args'
   LogToFile("ArgsProcessed calling main worker method")
   'call main worker method'
  End OnStart
  
  Sub LogToFile(message as String)
   If (AppConfigKeys[debugLogging] = True) Then
     'writes "DateTime.Now.ToString() & "-" & message" to a text file log' 
   End If
  End Sub
  

  Embed this kind of logging into the application before and after any process that is likely to fail.

• Does the customer have BI rules on the firewall hardware? (I'm grasping at straws, but we got similar behavior from one of our clients consuming one of our services a few years back because they had enabled some funky BI rules on the firewall.)