none
TS Gateway - slow performance issue over SSL

    Question

  • Have setup a new Windows 2008 TS Gateway and a Windows 2008 Terminal Server as per the MS guidelines.
    I've got an issue with SLOW performance (lag) when connecting via the TS Gateway (one user logged in, no other apps installed on the terminal server).
    It logs in and secures the session OK (a little slow), but the lag once logged in is appreciably slower than normal (2-3 seconds from pressing a key, to the letter appearing in Notepad).
    Performance is fine if I connect to the TSGateway server or the Terminal Server directly via RDP.

    TS Gateway Specs:
    Quad-Core Xeon, 8GB RAM, SAS RAID-10 array, Windows 2008 Enterprise x86 SP2.
    No Antivirus software installed yet.

    Terminal Server Specs:
    Quad-Core Xeon, 8GB RAM, SAS RAID-10 array, Windows 2008 Enterprise x86 SP2.
    No Antivirus software installed yet.

    On both servers, CPU usage is at 2% or less, plenty of memory available, network utilization is low.
    - The IIS settings seem OK on the TS Gateway (anything I should check?)
    - On the TS Gateway, netstat -a reports port 443 connection to the client, and port 3389 connection to the Terminal Server, so that looks correct.

    Any ideas or other things I should check?


    Thanks,
    Peter.




    Thursday, June 18, 2009 12:44 PM

Answers

  • Do any of you happen to run NOD32 or any other AV with http/https checking?

    I have discovered that despite having SSL checking disabled in NOD32 it still appears to be interferring. Having disabled HTTP checking the RDP session has become usable again:

    RPC Ping http checking enabled :

    RPCPing set Activity ID:  {d0a1ce8e-4f02-4b22-8495-5aecbc5d74c3}

     Completed 1 calls in 5850 ms

    0 T/S or 5850.000 ms/T

     

    RPC Ping http checking disabled :

    RPCPing set Activity ID:  {83d848bd-a082-4c6e-a1cf-82be7ce5bbc9}

     Completed 1 calls in 1747 ms

    0 T/S or 1747.000 ms/T

     

    I also tried adding our ts gateway address to the Addresses excluded from checking, and it seemed to cause even more delay to the RPC Ping.

     

    RPCPing set Activity ID:  {b5310b70-dcd8-4ec0-95e9-ab8ac272d76a}

     Completed 1 calls in 6942 ms

    0 T/S or 6942.000 ms/T

     

    RPCPing set Activity ID:  {52727588-f1ae-4444-a4f4-80f4b8af58b3}

     Completed 1 calls in 6676 ms

    0 T/S or 6676.000 ms/T

     

    Also worth noting is that once the connection is established with HTTP checking disabled, minimizing the session and enabling the http checking again does not appear to impact the session (or at least hadn't after 10 minutes of been connected)

    Thursday, October 01, 2009 10:01 PM

All replies

  • Just an update to the above issue ....

    Tried connecting on a different client PC (Windows XP SP2 with RDP Client 6.1), and it's running at normal speed.
    From my original client (Windows 7 RC build 7100), it's SLOW through the TS Gateway, fine through RDP.
    Will try it on a Vista client.


    Regards,
    Peter.

    Thursday, June 18, 2009 1:18 PM
  • Hi,


    Can you please try the following commands and tell me how much time it took for you to do rpcping. if rpcping is successful then it shows how much time it has taken to ping the server. Also how fast is the direct mstsc connection to the gateway server.


    If you are usin password authentication for gateway:

    Rpcping -v 3 -e 3388 -t ncacn_http -s localhost -o RpcProxy= -c -H Cert -u SChannel -a connect -F ssl -B msstd:redmon dts.microsoft.com

    If you are using smartcard authentication for gateway:

     Rpcping -v 3 -e 3388 -t ncacn_http -s localhost -o RpcProxy=tsnext.microsoft.com -c -H Cert -u SChannel -a connect -F ssl -B msstd:tsnext.microsoft.com Please try these commands from the client where your experince is good and bad.



    Thanks & Regards, Rajesh.
    Regards, Rajesh.
    Friday, June 19, 2009 11:56 AM
    Moderator
  • Hi Rajesh,

    I'm using password authentication for the gateway.

    Using the command:
    Rpcping -v 3 -e 3388 -t ncacn_http -s localhost -o RpcProxy= -c -H Cert -u SChannel -a connect -F ssl -B msstd:redmon dts.microsoft.com (replacing redmondts.microsoft.com with our ts gateway name).

    It prompts for a Username/Password, but the username field is grayed out and the only option in the drop-down is 'Insert smart card...'. If I click 'cancel' at this prompt, it says "Cannot retrieve smart card credentials 5 : Access is denied"

    Is there a command line parameter I am missing for RPCPing to force username/password authentcation  ?


    Thanks,
    Peter.

    Saturday, June 20, 2009 4:29 AM
  • here is the command for password authentication:

    Rpcping -v 3 -e 3388 -t ncacn_http -s localhost -o RpcProxy=<gateway-server-name>  "<username>,NT_PROD,*"   -I "<username>,NT_PROD,*"  -H NTLM -u NTLM -a connect -F ssl -B msstd:<gateway-server-name>



    Regards, Rajesh.
    Saturday, June 20, 2009 5:58 AM
    Moderator
  • Hi Rajesh,

    Thanks ...

    I think it's just a Windows 7 RC issue, so I wouldn't worry too much (it is still in Release Candidate stage!).
    I've tried a Vista SP2 and XP SP2 PC from the same remote location (behind the same firewall), and it works fine at full speed. Just the Windows 7 RC client that is really slow when using the TS Gateway.

    Here's the output from the RPCPing command, from the Windows 7 PC:
     RPCPing set Activity ID:  {097da53e-fd3f-4aca-bf09-cc871d843fd9}
     Completed 1 calls in 6427 ms
    0 T/S or 6427.000 ms/T


    And here's the output on the XP SP2 PC (in a Virtual Machine on the same PC):

    RPCPinging proxy server remote.****.net with Echo Request Packet
    Sending ping to server
    Response from server received: 200
    Pinging successfully completed in 601 ms


    Regards,
    Peter.

    Saturday, June 20, 2009 10:29 AM

  • Hi There
    Just installed Windows 7 RTM, and this is still an issue. I have a server with Gateway and connect to a remote desktop, but its really slow ....

    What to do ?

    Kenneth Karlsson
    Denmark
    Wednesday, August 19, 2009 11:29 AM
  • This is a huge issue for me as well.

    Windows 7 RDP Client through gateway = unusuably slow.
    Windows 7 RDP client direct to destination machine over 3389 = fast fast fast.

    Windows XP Client through gateway (to same destination machine) = FAST
    Windows XP Client direct to destination machine over 3389 = FAST.

    Why can't we get some response from MS on this?

    Rick
    Monday, September 14, 2009 8:58 PM
  • Same issue here, Windows 7 through TS Gateway; Direct RDP is fine. I am using a UCC certificate, wondering if anyone else is using the same?
    Monday, September 14, 2009 10:35 PM
  • Is your Windows 7 client machine joined to some private domain which is unaccessible from the Gateway server (like a private domain setup at home which can't be accessed by the Gateway server machine which is in your office network)?

    Thanks
    Vikash
    Tuesday, September 15, 2009 4:06 AM
    Moderator
  • Hi Vikash,

    This is happening for us as well, it's definitely a Windows 7 problem as Vista and XP are ok.  I am getting close to a 8000ms response time over the LAN from my Windows 7 PC and 800ms from my XP Pro.

    They are both part of the domain, but I have tried remotely from the both XP and windows 7 when they are part of a workgroup and also part of a different domain.

    We're also using a UCC certificate generated by our own MS certificate authority.

    Ed
    Tuesday, September 15, 2009 10:08 AM
  • Since both Eddrick and Albe (above) having UCC certificate in common, in order to help us isolate the issue-- can both of you guys try by using a self signed certificate on Gateway server and report back in case you still face this issue of connection time getting a little longer?

    @Edrick -- you did not clarify whether it makes a difference or not if your Win7 client machine is joined to a domain (unreachable from the gateway server) or is kept in workgroup? Can you please post that here?

    Thanks
    Vikash
    Thanks, Vikash
    Tuesday, September 15, 2009 10:56 AM
    Moderator
  • Hi Vikash,

    It doesn't make a difference where the Win7 machine is or whether its on a domain or not, the performance is still poor.  Conversely the XP machines are always fast.

    I will try it with a self signed certificate and post back soon.

    Thanks,
    Ed
    Tuesday, September 15, 2009 11:15 AM
  • I have just tried it with a self signed certificate and the same thing happens.

    Our production server is a Windows 2008 x64 SP2 box but we also have a test server running 2008 R2 so out of interest I tried setting that up as an RD Gateway but it does exactly the same thing - Windows 7 still very slow.

    Many thanks,
    Ed

    Tuesday, September 15, 2009 11:32 AM
  • Are you complaining about connecting time poor performance or poor performance after getting connected?

    Thanks
    Vikash
    Thanks, Vikash
    Tuesday, September 15, 2009 11:33 AM
    Moderator
  • Connecting time is fine, it's after you've connected and you're trying to use the TS session that the lag occurs.  There is a good 5 - 10 second delay to anything you type in Notepad for example.
    Tuesday, September 15, 2009 12:27 PM
  • My home machine is in a workgroup.  No domain at all.

    Rick
    Tuesday, September 15, 2009 4:23 PM
  • Hi Vikash,

    This is happening for us as well, it's definitely a Windows 7 problem as Vista and XP are ok.  I am getting close to a 8000ms response time over the LAN from my Windows 7 PC and 800ms from my XP Pro.

    They are both part of the domain, but I have tried remotely from the both XP and windows 7 when they are part of a workgroup and also part of a different domain.

    We're also using a UCC certificate generated by our own MS certificate authority.

    Ed

    In my scenario I am using a wildcard certificate issued by Digicert.  We have no issues with this setup connecting through the TS gateway with any other operating system other than Windows 7.  Definitely a Windows 7 issue.

    Rick
    Tuesday, September 15, 2009 4:24 PM
  • Are you complaining about connecting time poor performance or poor performance after getting connected?

    Thanks
    Vikash
    Thanks, Vikash

    My connecting time is also terrible.  Takes 20 seconds to start to display the first screen of the remote machine.  Each phase of the handshaking takes at least 5 seconds.

    Rick
    Tuesday, September 15, 2009 4:29 PM
  • hello,

    You are not alone, I have the same issue.
    When I connect my server through RDP directly, no problem.
    For mapped drives, no problem


    When I try to connect my server through a TS gateway, it's very slow when I try to look in a local mapped drive.

    I hope a solution in the following post
    Tuesday, September 15, 2009 5:56 PM
  • For issues where connection time through Gateway takes long enough, please read this post http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/e8af9624-cdf6-4771-a0a0-7b332cfbe9e8 to see if you have similar issues.

    For runtime performance issues, can you guys please tell me the exact version of the OS on all three machines that you have?

    Client -- Vista RTM/Vista SP1/XP SP3/ Windows 7 (which version -- RC/Beta etc).
    RD Gateway -- Windows Server 2008 R2 (which version -- RC/Beta)
    Remote TS server -- Windows Server 2008/ Windows Server 2008 R2 (which version RC/Beta)

    Thanks
    Vikash
    Thanks, Vikash
    Wednesday, September 16, 2009 6:24 AM
    Moderator
  • Hi Vikash,

    Client = Windows 7 Ultimate (also tried Business), Version 6.1 Build 7600
    RD(TS) Gateway = Windows Server 2008 Standard, Version 6.0 Build 6002 SP2
    TS Server = Windows Server 2008 Standard, Version 6.0 Build 6002 SP2

    As previously mentioned I have also tried using an RTM release of Windows Server 2008 R2 Standard (from MSDN) as the RD Gateway and this also has the problem.

    Thanks for your help on this!

    Ed
    Wednesday, September 16, 2009 12:33 PM
  • HuntIt or dredge999 , or others,

    I would like to offer to take a quick remote look at what is going on for you.

    I just ran into this with another person, and was able to speed up his login times (his were cert related issues)

    Email me at kristin.l.griffin@gmail.com if you would like this.

    Thanks!

    Hope this helps,

    Kristin L. Griffin

    Co-Author of the Windows Server 2008 Terminal Services Resource Kit (and a SUPER BIG fan of the Microsoft RDV Team!!!) 
    Wednesday, September 16, 2009 2:33 PM
    Moderator

  • Hi Kristin,

    Thank you very much for your help on this.

    Hi All,

    Thanks very much for reporting the issue.  We need traces on client and server to find some co-relation.  Please follow the below steps to give us the traces.

      1. Create files start_client_trace.cmd, stop_client_trace.cmd on win7 client with the respective contents contents below.
      2. Create files start_rdgserver_trace.cmd, stop_rdgserver_trace.cmd on RD Gateway server with the respective contents below.
      3. Before connecting through gateway, Execute start_client_trace.cmd on client and start_rdgserver_trace.cmd on Gateway server.
      4. Wait until you have the repro for low performance issue
      5. Now Execute stop_client_trace.cmd on client and stop_rdgserver_trace.cmd on Gateway server.
      6. Provide us all the .etl files created under %USERPROFILE%\Documents directory.



    start_client_trace.cmd
    ============================================
    logman create trace aaclient_trace -m start -p {70DB53D8-B6F3-428d-AA33-5B2CE56718C5} 0xFFFF 5 -o  %USERPROFILE%\Documents\aaclient_trace.etl
    logman create trace mstscax_trace -m start -p {DAA6CAF5-6678-43f8-A6FE-B40EE096E06E} 0xFFFF 5 -o  %USERPROFILE%\Documents\mstscax_trace.etl
    logman create trace mstsc_trace -m start -p {0C51B20C-F755-48a8-8123-BF6DA2ADC727} 0xFFFF 5 -o  %USERPROFILE%\Documents\mstsc_trace.etl
    netsh trace start capture=yes tracefile=%USERPROFILE%\Documents\rpc_trace.etl fileMode=circular correlation=no provider=Microsoft-Windows-RPC
    logman start aaclient_trace
    logman start mstscax_trace
    logman start mstsc_trace
    ============================================

    start_rdgserver_trace.cmd
    ============================================
    logman create trace aatspp_trace -m start -p {909ED641-D5EF-4299-B898-F13451A59F50} 0xFFFF 5 -o  %USERPROFILE%\Documents\aatspp_trace.etl
    logman create trace mstscax_trace -m start -p {6F539394-F34F-45fd-B4CA-BD5C547B0BCB} 0xFFFF 5 -o  %USERPROFILE%\Documents\aaedge_trace.etl
    logman start aatspp_trace
    logman start aaedge_trace
    ============================================

    stop_client_trace.cmd
    ============================================
    logman stop aaclient_trace
    logman stop mstscax_trace
    logman stop mstsc_trace
    netsh trace stop
    netsh trace convert input=%userprofile%\Documents\rpc_trace.etl output=%userprofile%\Documents\rpc_trace.csv dump=CSV
    logman delete aaclient_trace
    logman delete mstscax_trace
    logman delete mstsc_trace
    ============================================

    stop_rdgserver_trace.cmd
    ============================================
    logman stop aatspp_trace
    logman stop aaedge_trace
    logman delete aatspp_trace
    logman delete aaedge_trace
    ============================================

     


    Regards, Rajesh.
    Wednesday, September 16, 2009 3:35 PM
    Moderator
  • For issues where connection time through Gateway takes long enough, please read this post http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/e8af9624-cdf6-4771-a0a0-7b332cfbe9e8 to see if you have similar issues.

    For runtime performance issues, can you guys please tell me the exact version of the OS on all three machines that you have?

    Client -- Vista RTM/Vista SP1/XP SP3/ Windows 7 (which version -- RC/Beta etc).
    RD Gateway -- Windows Server 2008 R2 (which version -- RC/Beta)
    Remote TS server -- Windows Server 2008/ Windows Server 2008 R2 (which version RC/Beta)

    Thanks
    Vikash
    Thanks, Vikash
    I am not nearly as concerned about the startup time (for me 10-20 seconds) as the unusable state that the connection is in once I am connected.

    I am using a wildcard certificate so mine should not have certificate error issues (nor am I seeing any popups regarding this).

    I can live with 10 seconds to connect, I cannot live with 3-4 seconds for the client to respond to typing and/or mouse clicks.

    Rick
    Wednesday, September 16, 2009 9:11 PM
  • Hi,

    Can you please provide us the traces.

    Thanks,
    Regards, Rajesh.
    Thursday, September 17, 2009 4:38 AM
    Moderator
  • Hi Rajesh,

    Just performed the requested traces from a Windows 7 machine over the LAN.  I have zipped up the etl files and uploaded them to MediaFire, they can be downloaded from: http://www.mediafire.com/?kqz5enggzte

    Many thanks,
    Ed
    Thursday, September 17, 2009 11:02 AM
  • Thank you very much. We will analyze the logs and get back to you.

    Regards, Rajesh.
    Thursday, September 17, 2009 4:06 PM
    Moderator
  • Hi,

    Can you please provide us the traces.

    Thanks,
    Regards, Rajesh.
    http://www.xformity.com/downloads/XFM_ETL_Trace.zip

    Please respond when you have the download so I can remove this from our site.

    Rick
    Thursday, September 17, 2009 5:00 PM
  • Rajesh,

    How are you analyzing these logs?  I have converted to CSV, and EVTX using tracerpt, and have also pull ed them straight into Event Viewer and both give no telling data.  If you could share your analytic method we could all see what you see?

    Many thanks!

    Kristin
    Hope this helps,

    Kristin L. Griffin

    Co-Author of the Windows Server 2008 Terminal Services Resource Kit (and a SUPER BIG fan of the Microsoft RDV Team!!!) 
    Thursday, September 17, 2009 6:44 PM
    Moderator
  • Hi,

    Can you please provide us the traces.

    Thanks,
    Regards, Rajesh.
    http://www.xformity.com/downloads/XFM_ETL_Trace.zip

    Please respond when you have the download so I can remove this from our site.

    Rick

    Hi Rick,
    Thanks for sharing the traces. We have copied it locally, so you can remove this from your site. We will get back after analyzing them.


    Thanks, Vikash
    Friday, September 18, 2009 4:19 AM
    Moderator
  • Has there been any further progress with this issue please?
    Monday, September 21, 2009 3:13 PM
  • Hi Rajesh,

    Have you found anything interesting in the logs yet?

    Regards,
    Ed
    Monday, September 21, 2009 6:59 PM
  • Hi,

    As per these traces, mstsc does not have any problems.  May be the slowness can be because of underlying transport RPC/HTTP or network.  By the way, we have self-hsoted win7 clients and never experienced these problems.

    We will work with RPC/networking  team to find the root causes.


    To all who experience the slowness from Win7 client but not vista/XP clients:

    When you experience the slowness , please execute rpcping command and provide us the time taken on Win7 and XP clients. This confirms that the problem is at either network/transport level.

    Thanks all for your help.
    Regards, Rajesh.
    Tuesday, September 22, 2009 6:45 PM
    Moderator
  • Hi,

    As per these traces, mstsc does not have any problems.  May be the slowness can be because of underlying transport RPC/HTTP or network.  By the way, we have self-hsoted win7 clients and never experienced these problems.

    We will work with RPC/networking  team to find the root causes.


    To all who experience the slowness from Win7 client but not vista/XP clients:

    When you experience the slowness , please execute rpcping command and provide us the time taken on Win7 and XP clients. This confirms that the problem is at either network/transport level.

    Thanks all for your help.
    Regards, Rajesh.

    I hope this isn't the end of this discussion because it is obvious to me and the others having this issue that the problem is not just one person but many.

    The "network" in this case is 10mbit on both sides, pings (not RPCPing) are in the 20ms range (obviously it is not congested at the time of the slowness).  I have tested all of this before reporting the problem.

    When I can connect directly through straight RDP on port 3389 without a gateway and performance is outstanding, then connect via the TS gateway and performance is horrible (within a minute of each other) then I know there is an issue that is not related to the destination machine, the source network or the destination network.

    I hereby volunteer to have you remote control my machine or perform any other more intrusive testing to get this situation resolved.  I literally cannot manage our servers without a "double" RDP session (direct to my PC at work via 3389 and then RDP again to servers).  This is a huge issue for me and now we cannot roll out Windows 7 clients remotely until this is resolved.

    I also believe that someone has already posted RPCPing results in the thread above.  If you need more results let me know (his were 6000+ms using Windows 7 with TS Gateway and 200ms on Windows XP with TS Gateway).

    Rick
    Tuesday, September 22, 2009 9:38 PM
  • I agree, this is clearly affecting many people.

    I have the issue over a 100Mbps LAN with normal pings at <1ms, it is obviously a problem with Windows 7 and is beginning to cause us serious problems and is also a major barrier to rolling out Windows 7 to all our remote users.

    Can the 'RPC/Networking team' join this thread and provide further troubleshooting steps?

    Ed
    Tuesday, September 22, 2009 9:50 PM
  • I might have the same issue when connecting to server 2008 sp2.
    When connecting from Vista Business SP2 32-bit through tsgateway the link is slow and delay for keyboard input can be seen clearly when connected.
    rcpping 6.0 ran as following:
    0 T/S or 5366.000 ms/T

    When not using tsgateway there is no lag in connection.

    When switching network cable to Xp Pro computer for testing, it can connect without delay through tsgateway using same certs and setup.

    I also tried with vista ultimate with same certificate through tsgateway and it has no lag problems.

    Is there a way to troubleshoot what is causing the lag with tsgateway?

    J
    Wednesday, September 23, 2009 2:48 PM
  • The same for me.

    Is there any progress/workaround on that? I just installed Win 7 RTM and these lags are terrible.

    Lags are present regardless I connect to 2008 server or another Win 7 box.

    Thanks,
    Nikita
    Monday, September 28, 2009 5:18 PM
  • I have made some pretty desperate attempts to find a workaround.

    Just as an FYI, I found a site that gave me the idea to run the Terminal Services Client in Windows XP Mode on my client Windows 7 box.

    I figured out how to do this and was looking at the site below:

    http://wunger.spaces.live.com/blog/cns!9E6927A42561030E!1198.entry

    Basically I want to run the XP TS Client as a remote app so that I don't have these lag issues with the Windows 7 client.

    Got this all set up and many applications work, however I think that I am having issues due to the fact the the XP client is RDC 6.0 (supporting protocol 6.1) and the Windows 7 client is RDC 6.1 (supporting protocol 6.1).

    The following error occurs "procedure entry point _snprintf_s could not be located in the dynamic link library msvcrt.dll".

    I am not confident that this can be fixed the the implications of the whole process are intriguing. 

    Check out the site for more info.

    Rick
    Wednesday, September 30, 2009 3:49 PM
  • Can you folks run RPCPING twice, once with -i 1 and once with –i 1000?

     

    The time reported by RPCPING consists of both connection establishment as well as latency. By running multiple iterations, you can subtract the connect time and more accurately assess the response time.

    Please measure this independently on non-problemmatic OS (XP) and Windows 7 OS (problemmatic one).

    Thursday, October 01, 2009 8:29 PM
  • By RTM, do you mean 7600 version binaries? Please provide us with the MSTSC client version.

    Thanks,
    Gk

    Thursday, October 01, 2009 8:30 PM
  • Can you please re-run RPCPING twice, once with -i 1 and once with –i 1000?

     

    The time reported by RPCPING consists of both connection establishment as well as latency. By running multiple iterations, you can subtract the connect time and more accurately assess the response time.

    Please measure this independently on both non-problemmatic OS (XP) and Windows 7 OS (problemmatic one). Kindly print out the entire output.

    Thursday, October 01, 2009 8:34 PM
  • Do any of you happen to run NOD32 or any other AV with http/https checking?

    I have discovered that despite having SSL checking disabled in NOD32 it still appears to be interferring. Having disabled HTTP checking the RDP session has become usable again:

    RPC Ping http checking enabled :

    RPCPing set Activity ID:  {d0a1ce8e-4f02-4b22-8495-5aecbc5d74c3}

     Completed 1 calls in 5850 ms

    0 T/S or 5850.000 ms/T

     

    RPC Ping http checking disabled :

    RPCPing set Activity ID:  {83d848bd-a082-4c6e-a1cf-82be7ce5bbc9}

     Completed 1 calls in 1747 ms

    0 T/S or 1747.000 ms/T

     

    I also tried adding our ts gateway address to the Addresses excluded from checking, and it seemed to cause even more delay to the RPC Ping.

     

    RPCPing set Activity ID:  {b5310b70-dcd8-4ec0-95e9-ab8ac272d76a}

     Completed 1 calls in 6942 ms

    0 T/S or 6942.000 ms/T

     

    RPCPing set Activity ID:  {52727588-f1ae-4444-a4f4-80f4b8af58b3}

     Completed 1 calls in 6676 ms

    0 T/S or 6676.000 ms/T

     

    Also worth noting is that once the connection is established with HTTP checking disabled, minimizing the session and enabling the http checking again does not appear to impact the session (or at least hadn't after 10 minutes of been connected)

    Thursday, October 01, 2009 10:01 PM
  • I am running NOD32.

    When I turn off Web access protection it solves the problem.  I hereby raise a beer in your honor sir.

    Now we need to figure out how to get the exclusion to work.


    JB - have you opened a case with ESET yet?

    Rick
    Thursday, October 01, 2009 10:32 PM
  • I have had a look at the ESET configuration and you don't need to fully disable the web filtering.

    Under the "HTTP, HTTPS" section you just need the "Do not use HTTPS protocol checking".  This is normally greyed out because the SSL section is set to "Do not scan SSL protocol" by default so you just need to temporarly change this to "Always scan SSL protocol" while you make the change to the "HTTP, HTTPS" section.

    We haven't opened a case with ESET as we don't really have a requirement to check HTTPS, also as SSL checking is disabled by default I'm not entirely sure what this would have been doing anyway!

    Hope this helps,
    Ed

    • Edited by Eddrick83 Friday, October 02, 2009 8:32 AM typo
    • Proposed as answer by seansatu Tuesday, October 06, 2009 10:26 AM
    Friday, October 02, 2009 8:31 AM
  • Thanks a lot. Disabling SSL in NOD32 solved the problem!
    Friday, October 02, 2009 3:12 PM
  • Thanks!

    NOD32 ssl checking was causing the problem here too. I swear I tried disabling antivirus :-)

    J
    Saturday, October 03, 2009 8:35 AM
  • Rick\JB

    Can you please tell us the behaviour of ESET Nod32 AV on XP\Vista machine? Does your clients (non win7) which were giving good performance also had the AV installed?

    Regards
    Rochak

    Monday, October 05, 2009 5:40 AM
  • Yes, all the clients I tested had NOD32 v4 installed but only the Windows 7 clients experienced the problem.  We are using the latest build (4.0.467) which states Windows 7 compatibility.
    Tuesday, October 06, 2009 8:27 AM
  • Same here ... problem is only with Windows 7 clients (RC and RTM), running ESET NOD32 V4 ... thanks for the detective work everyone!

    I'll see if I can lodge something with ESET.
    Tuesday, October 06, 2009 8:35 AM
  • jbaxis, dredge999, eddrick83, huntit, thank you so much for getting to the bottom of this.

    This problem has been tormenting me for weeks.

    Just goes to show you that as in "the rake" the solution is generally the most obvious, even if you do not believe it to be so !!
    The disabled box in "Do not use HTTPS protocol checking" in nod32 was the one that got to me !!

    And as with other who have noted this behavior, I agree, I have only noticed it on Windows 7.

    Thanks for putting me out of my misery!!

    Tuesday, October 06, 2009 10:37 AM
  • Has anyone experienced similar issue on Vista SP2 client as well? Just checking...
    Thanks, Vikash
    Tuesday, October 06, 2009 10:39 AM
    Moderator
  • No, Just Win7
    Thursday, October 08, 2009 8:27 AM
  • My problem with NOD32 and tsgateway was with Vista Business 32bit with latest service packs so its not only WIN7.
    HTTPS protocol checking was the problem liek with others.

    J
    Tuesday, October 20, 2009 8:24 AM
  • Thanks a lot. Problem is gone. 
    I hope ESET publish updates at nearest time for Windows 7. So my old configuration (Windows XP) was worked correctly with ESET.

    OFFTOPIC
    In situation when HTTS scanning is Enabled (under disabled box) and disable NOD32 totaly any activity (spyware and antivirus) - problem is still.
    The problem is gone only when disable HTTS scanning.
    Sunday, October 25, 2009 11:26 AM
  • Thanks a lot.  I use ESET 4.0.467.0 (last)  and still same problem with HTTS scanning.
    Lembit
    Thursday, November 05, 2009 2:19 PM
  • Me too...with the lastest NOD32 V4 problem still there...this need to be addresed to ESET
    Monday, November 23, 2009 12:59 PM
  • If you turn on ssl inspection, then go to http https, https is not changeable when ssl is off but is when it is on, change it to do not use https protocol checking, then go back and turn ssl inspection back off.  This resolves the issue.  I have reported it to eset/nod32
    Wednesday, March 03, 2010 4:59 PM
  • thank you very very much !
    I was despairing to find a solution to that for months !

    I love NOD32 and never had a problem with it, shame on them for that bug !

    I find also incredible to have already that bug months after it has been discovered.
    Monday, March 15, 2010 2:08 PM
  • Even though, i've disabled NOD32 but the problem is still there. Any other idea friends ?

    BAHADURI

    Sunday, November 27, 2011 10:06 PM