none
Problems with UAG Client's components ?

    Question

  • Hi,

    I installed a new UAG infrastructure and updated to the last Update 2. In the portal I try to publish a Socket Forwarder for publish a RDM connection.

    I have some clients who can connect and other one that can't connect. There are no common poit to determine why someone clients have trouble tu use RDP Connection over the SSL tunnel.

    For improve my research, I try to connect theses "bad clients" to an another UAG server with the samed update level. The workstations who didn't works in the previous infrastructure, don't work with the new.

    On theses clients, I try to uninstall and reinstall UAG components, no changes :( I reset IE settings, no more lucks ... Theses clients are on XP, Vista, 7 with IE6 to 8 on x86 and x64; so no common points.

    The error in client side, is when the user try to lauch RDP, the mstsc.exe is running and said that the serever is unavailable.

    With theses results, I think that the problem come from UAG components. Do you have any elements that could help me to investigate ?

    Thank you


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Wednesday, December 01, 2010 9:57 AM

Answers

  • Hi Alex,  I think I may have replicated the issue.  Would it be possible to see if the "client" who is having problems, cannot connect to either of your customers?   I have 2 customers who are publishing RPM and the "client" is having problems connecting to both sites.

    The client in question is actually one of my Windows 7 HOME edition test laptops.

    Thank you.

    Tuesday, December 14, 2010 6:40 PM
  • Hi Everyone,

    Finaly the problem has been solved with Microsoft support.

    In this thread I don't speak about that the problem concern ICA Citrix too, because I thought that the problem with RDP was the same with ICA. In fact, I had 3 child issues on my problem.

    1- The first one is about x64 machines only that they was not to be able to connect RDP because UAG doesn't support "native" x64 socket tunneling, only WOW64. So in this case, I have to use a workaround for launch mstsc.exe in 32 bit mode under a x64 system.

    2- For others x86 machine who was not to be able to connect to RDP, this came from a LSP problem installation. The command "netsh winsock show catalog" have to see the dll with WhlLSP.dll who is called "SSL Application Tunneling over [MSAFD Tcpip[TCP/IP]]"

    Winsock Catalog Provider Entry
    ------------------------------------------------------
    Entry Type:             Layered Chain Entry (32)
    Description:            SSL Application Tunneling over [MSAFD Tcpip
    [TCP/IP]]
    Provider ID:            {3CDD90C6-A2EC-4C94-85F4-05852585CE8A}
    Provider Path:           C:\PROGRA~1\MID171~1\ENDPOI~1\318FB7~1.0\Whl
    LSP.dll
    Catalog Entry ID:          1039
    Version:              2
    Address Family:           2
    Max Address Length:         16
    Min Address Length:         16
    Socket Type:            1
    Protocol:              6
    Service Flags:           0x66
    Protocol Chain Length:       2
    Protocol Chain: 1038 : 1001
    
    
    Winsock Catalog Provider Entry
    ------------------------------------------------------
    Entry Type:             Layered Chain Entry (32)
    Description:            SSL Application Tunneling over [MSAFD Tcpip
    [UDP/IP]]
    Provider ID:            {3CDD90C6-A2EC-4C94-85F4-05852585CE8A}
    Provider Path:           C:\PROGRA~1\MID171~1\ENDPOI~1\318FB7~1.0\Whl
    LSP.dll
    Catalog Entry ID:          1040
    Version:              2
    Address Family:           2
    Max Address Length:         16
    Min Address Length:         16
    Socket Type:            2
    Protocol:              17
    Service Flags:           0x609
    Protocol Chain Length:       2
    Protocol Chain: 1038 : 1002
    
    
    Winsock Catalog Provider Entry
    ------------------------------------------------------
    Entry Type:             Layered Chain Entry (32)
    Description:            SSL Application Tunneling over [MSAFD Tcpip
    [RAW/IP]]
    Provider ID:            {3CDD90C6-A2EC-4C94-85F4-05852585CE8A}
    Provider Path:           C:\PROGRA~1\MID171~1\ENDPOI~1\318FB7~1.0\Whl
    LSP.dll
    Catalog Entry ID:          1041
    Version:              2
    Address Family:           2
    Max Address Length:         16
    Min Address Length:         16
    Socket Type:            3
    Protocol:              0
    Service Flags:           0x609
    Protocol Chain Length:       2
    Protocol Chain: 1038 : 1003

    If the LSP is not present, we have to reset LSP catalog "netsh winsock reset catalog" and uninstall UAG components. After a reboot, we have to reinstall components from UAG portal and now finaly it will works fine (had to be sure that the LSP are now correctly installed).

    3- For ICA Problem, this problem has no relation with previous RDP problem. The last ICA Client version (12.1) has known problem on proxy FQDN. There is 3 solutions :
     a) Downgrade 12.0.3
     b) Change registry key on the ICA client TRUE in HKLM(or HKCU)\Software\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\Proxy\ProxyUseFQDN 
    c) Change XenApp settings for generate an ICA file from Citrix Web Interface that contain ProxyUseFQDN=on in [WFClient].

    Hope to help you for sharing this ;)

    Regards,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Tuesday, December 28, 2010 11:57 AM

All replies

  • Hi Alex,

    I'm sorry to hear your facing issues with your new UAG deployment.   Do you think its fair to say that, since it works for some clients, that the UAG Client components aren't at fault?

    After you click on the link to launch the application.  Open the the SSL-VLN Portal activity application thats in the toolbar (the big yellow and blue arrow icon) .  Perform and RDP connect, does it say "X.X.X.X:3389 via SOCKS started" at all?

    I suspect there is something wrong with the clients themselves.  We need to figure out what that common point is... 

    Are these home computers?  Fully patched?
    Are they domain computers? if so, using the same client AV|Firewall
    Do you using a fully trusted and valid SSL certificate on the trunk?

    Thanks,
    Dennis

    Wednesday, December 01, 2010 11:12 AM
  • Hi Dennis,

    Thank you for ur quick reply. I'm wonder if the problem came from UAG components or directly the clients, but I supose not server side.

    I already remark that on clients who can't connect that I have no active connection in the portal activity. After trying to launch RDP connection, if I type a netstat for 127.0.0.* I have :

    TCP    127.0.0.1:1081         0.0.0.0:0              LISTENING
    TCP    127.0.0.1:10081        0.0.0.0:0              LISTENING
    TCP    127.0.0.3:1080         0.0.0.0:0              LISTENING
    TCP    127.0.0.3:10080        0.0.0.0:0              LISTENING

    On a working computer, I have an active connection and with a netstat I have more information :

    TCP    127.0.0.1:1081         0.0.0.0:0              LISTENING
    TCP    127.0.0.1:10081        0.0.0.0:0              LISTENING
    TCP    127.0.0.1:10081        127.0.0.1:64348        ESTABLISHED
    TCP    127.0.0.1:13579        0.0.0.0:0              LISTENING
    TCP    127.0.0.1:49158        0.0.0.0:0              LISTENING
    TCP    127.0.0.1:49217        0.0.0.0:0              LISTENING
    TCP    127.0.0.1:49217        127.0.0.1:49229        ESTABLISHED
    TCP    127.0.0.1:49229        127.0.0.1:49217        ESTABLISHED
    TCP    127.0.0.1:49392        0.0.0.0:0              LISTENING
    TCP    127.0.0.1:63859        127.0.0.1:63860        ESTABLISHED
    TCP    127.0.0.1:63860        127.0.0.1:63859        ESTABLISHED
    TCP    127.0.0.1:63880        127.0.0.1:63881        ESTABLISHED
    TCP    127.0.0.1:63881        127.0.0.1:63880        ESTABLISHED
    TCP    127.0.0.1:64348        127.0.0.1:10081        ESTABLISHED
    TCP    127.0.0.3:1080         0.0.0.0:0              LISTENING
    TCP    127.0.0.3:10080        0.0.0.0:0              LISTENING

    For answer your question :

    - I have more home computers works than corporate. I can reproduce the problem after a full Windows Update
    - I can reproduce the problem on member and workgroup computers. If a member computer doesn't work and I detach from the domain, the problem still persist
    - I already try with no AV and the FW as disabled
    - Yes I use commercial and public SSL certificates (GlobalSign)

    Thank you,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Wednesday, December 01, 2010 12:03 PM
  • Hi,

    So strange but just FYI, I encounter the same problem with an another customer ... :( two UAG consecutives projects, with the same issue, ... I have to solved it quickly :) I will aprreciate your differents idea.

    Thank you,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Tuesday, December 14, 2010 11:02 AM
  • To continue ...

    I trace two connections with trace.hta on endpoints, one on working computer and another on a failed computer. I compare theses resultats, and remark that on the tracing file for the bad endpoint I have :

    [lsp WSPConnect spi.cpp@985] ERROR:Socket 000008a8 (type 1, protocol 6) failed to connect to 123.45.67.89:443, error 10035

    On the working computer I don't have this error. I suppose so, that the problem is not with UAG endpoints, but with Winsock (WSAEWOULDBLOCK) ...

     


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Tuesday, December 14, 2010 3:01 PM
  • Hi Alex,  I think I may have replicated the issue.  Would it be possible to see if the "client" who is having problems, cannot connect to either of your customers?   I have 2 customers who are publishing RPM and the "client" is having problems connecting to both sites.

    The client in question is actually one of my Windows 7 HOME edition test laptops.

    Thank you.

    Tuesday, December 14, 2010 6:40 PM
  • Yes Dennis, you're right. I have many virtual workstation (XP, W7, ...). If one of them don't work for one customer, don't work too for others customers. In fact, the bad workstation will never works again for Socket Forwarding.

    So, I can say that the problem is not come from the UAG Server and configuration.. but on the workstation.

    I tried to reset winsock, to hard uninstall/reinstall UAG components, ... I have really NO idea where to search now. I'm despite :(


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Wednesday, December 15, 2010 11:22 AM
  • Alex, I am going to try and troubleshoot this issue on my test laptop and see if I find any information.   However, at this time (good news for me) I haven't had any customers who have reported this issue.  (bad news for us)

    I will keep you posted.

    Thanks
    Dennis

     

    Wednesday, December 15, 2010 8:17 PM
  • Hi,

    I installed a new UAG infrastructure and updated to the last Update 2. In the portal I try to publish a Socket Forwarder for publish a RDM connection.

    I have some clients who can connect and other one that can't connect. There are no common poit to determine why someone clients have trouble tu use RDP Connection over the SSL tunnel.

    For improve my research, I try to connect theses "bad clients" to an another UAG server with the samed update level. The workstations who didn't works in the previous infrastructure, don't work with the new.

    On theses clients, I try to uninstall and reinstall UAG components, no changes :( I reset IE settings, no more lucks ... Theses clients are on XP, Vista, 7 with IE6 to 8 on x86 and x64; so no common points.

    The error in client side, is when the user try to lauch RDP, the mstsc.exe is running and said that the serever is unavailable.

    With theses results, I think that the problem come from UAG components. Do you have any elements that could help me to investigate ?

    Thank you


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog

    Not experienced this yet either :(
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, December 16, 2010 12:14 AM
  • Alex, I am going to try and troubleshoot this issue on my test laptop and see if I find any information.   However, at this time (good news for me) I haven't had any customers who have reported this issue.  (bad news for us)

    I will keep you posted.

    Thanks
    Dennis

     


    Oh Thank you Dennis, let me know if we have the same issue.
    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Friday, December 17, 2010 1:44 AM
  • Hi,

    I installed a new UAG infrastructure and updated to the last Update 2. In the portal I try to publish a Socket Forwarder for publish a RDM connection.

    I have some clients who can connect and other one that can't connect. There are no common poit to determine why someone clients have trouble tu use RDP Connection over the SSL tunnel.

    For improve my research, I try to connect theses "bad clients" to an another UAG server with the samed update level. The workstations who didn't works in the previous infrastructure, don't work with the new.

    On theses clients, I try to uninstall and reinstall UAG components, no changes :( I reset IE settings, no more lucks ... Theses clients are on XP, Vista, 7 with IE6 to 8 on x86 and x64; so no common points.

    The error in client side, is when the user try to lauch RDP, the mstsc.exe is running and said that the serever is unavailable.

    With theses results, I think that the problem come from UAG components. Do you have any elements that could help me to investigate ?

    Thank you


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog

    Not experienced this yet either :(
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk


    you're Lucky Jason :p

     I reproduce it on many workstation now; more and more ... :(


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Friday, December 17, 2010 2:03 AM
  • Hi Everyone,

    Finaly the problem has been solved with Microsoft support.

    In this thread I don't speak about that the problem concern ICA Citrix too, because I thought that the problem with RDP was the same with ICA. In fact, I had 3 child issues on my problem.

    1- The first one is about x64 machines only that they was not to be able to connect RDP because UAG doesn't support "native" x64 socket tunneling, only WOW64. So in this case, I have to use a workaround for launch mstsc.exe in 32 bit mode under a x64 system.

    2- For others x86 machine who was not to be able to connect to RDP, this came from a LSP problem installation. The command "netsh winsock show catalog" have to see the dll with WhlLSP.dll who is called "SSL Application Tunneling over [MSAFD Tcpip[TCP/IP]]"

    Winsock Catalog Provider Entry
    ------------------------------------------------------
    Entry Type:             Layered Chain Entry (32)
    Description:            SSL Application Tunneling over [MSAFD Tcpip
    [TCP/IP]]
    Provider ID:            {3CDD90C6-A2EC-4C94-85F4-05852585CE8A}
    Provider Path:           C:\PROGRA~1\MID171~1\ENDPOI~1\318FB7~1.0\Whl
    LSP.dll
    Catalog Entry ID:          1039
    Version:              2
    Address Family:           2
    Max Address Length:         16
    Min Address Length:         16
    Socket Type:            1
    Protocol:              6
    Service Flags:           0x66
    Protocol Chain Length:       2
    Protocol Chain: 1038 : 1001
    
    
    Winsock Catalog Provider Entry
    ------------------------------------------------------
    Entry Type:             Layered Chain Entry (32)
    Description:            SSL Application Tunneling over [MSAFD Tcpip
    [UDP/IP]]
    Provider ID:            {3CDD90C6-A2EC-4C94-85F4-05852585CE8A}
    Provider Path:           C:\PROGRA~1\MID171~1\ENDPOI~1\318FB7~1.0\Whl
    LSP.dll
    Catalog Entry ID:          1040
    Version:              2
    Address Family:           2
    Max Address Length:         16
    Min Address Length:         16
    Socket Type:            2
    Protocol:              17
    Service Flags:           0x609
    Protocol Chain Length:       2
    Protocol Chain: 1038 : 1002
    
    
    Winsock Catalog Provider Entry
    ------------------------------------------------------
    Entry Type:             Layered Chain Entry (32)
    Description:            SSL Application Tunneling over [MSAFD Tcpip
    [RAW/IP]]
    Provider ID:            {3CDD90C6-A2EC-4C94-85F4-05852585CE8A}
    Provider Path:           C:\PROGRA~1\MID171~1\ENDPOI~1\318FB7~1.0\Whl
    LSP.dll
    Catalog Entry ID:          1041
    Version:              2
    Address Family:           2
    Max Address Length:         16
    Min Address Length:         16
    Socket Type:            3
    Protocol:              0
    Service Flags:           0x609
    Protocol Chain Length:       2
    Protocol Chain: 1038 : 1003

    If the LSP is not present, we have to reset LSP catalog "netsh winsock reset catalog" and uninstall UAG components. After a reboot, we have to reinstall components from UAG portal and now finaly it will works fine (had to be sure that the LSP are now correctly installed).

    3- For ICA Problem, this problem has no relation with previous RDP problem. The last ICA Client version (12.1) has known problem on proxy FQDN. There is 3 solutions :
     a) Downgrade 12.0.3
     b) Change registry key on the ICA client TRUE in HKLM(or HKCU)\Software\Citrix\ICA Client\Engine\Lockdown Profiles\All Regions\Lockdown\Network\Proxy\ProxyUseFQDN 
    c) Change XenApp settings for generate an ICA file from Citrix Web Interface that contain ProxyUseFQDN=on in [WFClient].

    Hope to help you for sharing this ;)

    Regards,
    Alex


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Tuesday, December 28, 2010 11:57 AM
  • Thanks for sharing Alex!  I will try the LSP reset command tonight on my test box.
    Monday, January 03, 2011 10:10 PM
  • Thanks for sharing Alex!  I will try the LSP reset command tonight on my test box.


    Your always welcome ;)

    In addition, I found a workaround for RDP on x64 machine : use this trick http://www.davidmoore.info/2009/12/02/running-32-bit-remote-desktop-connection-on-windows-64-bit/ it's works !


    GIRAUD Alexandre - MVP Forefront France http://www.alexgiraud.net/blog
    Monday, January 03, 2011 10:33 PM