locked
Some confusion about SSL Wrapper and Socket Forwarding RRS feed

  • Question

  • We are running IAG 2007 w/ SP2 and update 5.

    Somebody is having trouble accessing our terminal servers via the Whale client on their Vista Home x64 SP2 machine.   Whenever they try and open start a connection it says "This application cannot start since it is not supported by your operating system."

    We have tried uninstalling the Whale components and doing a winsock catalog reset.  He has all the settings right in his browser as well.  He has the current whale components and SSL Tunneling version 4.0.1152.100.

    My understanding now after looking at this article is that this 64 bit OS is not supported.

    http://technet.microsoft.com/en-us/library/dd277998.aspx

     

    Does this mean we have to turn off socket forwarding in order to use SSL Wrapper so he can connect to the terminal servers?

    Tuesday, March 22, 2011 8:43 PM

Answers

  • Hi again,

    I think I got the customization needed in order to work around the issue. Please follow these steps:

    1.   Copy the file SSLVPNTemplates.xml from the \Whale-Com\e-Gap\von\conf folder, to the \Whale-Com\e-Gap\von\conf\CustomUpdate folder

    2.   Open for editing the SSLVPNTemplates.xml file in the CustomUpdate folder, and locate the section that starts with: <template name="MSTSAC 800*600" We will customize this IAG application publishing template, so that it will allow running MSTSC also on a Vista 64-bit OS. You will need to delete all the other application templates from this custom XML file, both above and under this template. However, you need to make sure that you maintain the correct XML syntax of the entire file

    3.   The original MSTSAC template has a userrights attribute with a value of 16384. In your custom SSLVPNTemplates.xml file, change this value to 0 (zero)

    4.   The end result should be this:

    <config>

    <templates version="3" use-lsp="1">

    <!--
    *********************************************************************************
    ** Windows XP Terminal Services Client - variable screen resolution **
    *********************************************************************************
    -->

    <!-- Auto-Sense mode -->
    <template name="MSTSAC 800*600" userrights="0" use-with-lsp="yes" win="yes"><!--Windows-->
    <port id="0" remoteport="3389" localport="23456" flags="10" />
    <exec exe="mstsc.exe -v:%localip%:%localport% -w:%HRes% -h:%VRes%" flags="4" param="" use-with-lsp="no"/>
    <exec exe="mstsc.exe -w:%HRes% -h:%VRes% -v:%leadserver%" flags="4" param="" use-with-lsp="only"/>
    <config-file flags="33" path="" ><![CDATA[
    [1\Software\Microsoft\Terminal Server Client\Default]
    MRU0=C%localip%:%localport%
    Full Address=C%localip%:%localport%
    ]]>
    </config-file>
    </template>
    </templates>
    </config>

    4.   Save the modified file. Attempt to open the file in IE or in an XML editor, to ensure that the XML syntax is correct

    5.   Activate the configuration

    6.   Test from the Vista 64-bit client machine

     

    Regards,

    -Ran

    • Marked as answer by nmuleski Monday, April 4, 2011 9:54 PM
    Monday, March 28, 2011 10:01 AM

All replies

  • Well we just tried turning off Socket Forwarding (and therefore using SSL Wrapper in it's place) and that didn't not work either.  Same error.

     

    He is not having issues connecting to any of the services (outlook, our crm software, our intranet) besides the terminal servers.

     

    Any help/suggestions would be greatly appreciated.

    Tuesday, March 22, 2011 9:31 PM
  • Hi,

    What you are seeing might be a combination of a few things you should be aware of:

    1. Even though you have turned off Socket Forwarding (SF) on the UAG server side for a specific application, this does not mean that SF will not be used. As a matter of fact, if the IAG/UAG SF component is installed on a client machine, SF will always be used for tunneling traffic, instead of the SSL Wrapper. So, on your user's machine, you would have to first uninstall the IAG client components, and then perform the same test again. This time, only the SSL Wrapper would get installed and used.

    2. On 64-bit client machines, the IAG/UAG Socket Forwarding component tunnels traffic only for 32-bit apps (a.k.a. WOW64 apps). So you would need to make sure that the application template used on your IAG for publishing Terminal Servers is attempting to launch the WOW64 version of mstsc.exe, and not the 64-bit version

    3. But wait! Even if you would launch mstsc.exe on the client machine from %SystemRoot%\SysWOW64, that would still not necessarily mean that you are actually using the 32-bit version of this application (this has nothing to do with IAG/UAG!). Check out this blog: http://www.davidmoore.info/2009/12/02/running-32-bit-remote-desktop-connection-on-windows-64-bit/

    Regards,


    -Ran
    Wednesday, March 23, 2011 2:23 PM
  • Thank you for replying!

     

    I have a few questions that I will list in order with your points:

    1.  Even if I uninstall the components on the client, will the same components reinstall when I go to our web portal?  Or do components only install as needed (when we launch the application).  I ask because I was going to set up a new application just for this client, meaning the other applications that use SF would still be published in the portal for other users.  That makes me think that when I visit our site on the client and everything re installs that the SF components will reinstall automatically.

    2/3.  I do not understand how I can specify which version to launch?  I know that when the client computer is connected or our network, I can use the command mstsc.exe and gain access to our terminal servers, so I'm assuming that whatever version IAG/UAG is launching would also work.

     

    Sorry for the confusion, I'm new to UAG/IAG... I've read through countless white papers and forum postings to try and correct this issue, as the user swears that this feature worked on his client computer up until a month ago (when I got hired)... I've done nothing to the UAG/IAG besides download/install update 5.

    Wednesday, March 23, 2011 7:19 PM
  • Thank you for replying!

    You're very welcome!  

    I have a few questions that I will list in order with your points:

    1.  Even if I uninstall the components on the client, will the same components reinstall when I go to our web portal?  Or do components only install as needed (when we launch the application).  I ask because I was going to set up a new application just for this client, meaning the other applications that use SF would still be published in the portal for other users.  That makes me think that when I visit our site on the client and everything re installs that the SF components will reinstall automatically.

    If you install the IAG/UAG components from a client machine, you will not necessarily get the same exact set of components reinstalled. Here is how UAG client components get installed:

    1.   Upon the first connection to a UAG trunk, these components are installed:

                        I.         Component Manager

                       II.         Endpoint Detection

                      III.         Attachment Wiper (IAG) / Endpoint Session Cleanup (UAG)

    2.      From there on, the remaining components, all of which are components that handle tunneling through different methods, are each installed only when needed, when the user accesses an application which requires one or more of these components:

                        I.         SSL Wrapper (a.k.a. SSL Application Tunneling, or SSL Tunneling via port forwarding)

                       II.         Socket Forwarding

                      III.         Network Connector (IAG) / SSL Network Tunneling (UAG)

     

    2/3.  I do not understand how I can specify which version to launch?  I know that when the client computer is connected or our network, I can use the command mstsc.exe and gain access to our terminal servers, so I'm assuming that whatever version IAG/UAG is launching would also work.

    There is a way to control what EXE gets launched on the client machine, but this would require a customization that we may be able to avoid, if you'll publish TS using SSL Wrapper only. Note, however, that if the user gets Socket Forwarding installed on his client machine, for example by using another application that requires SF, then SF will be used for the Terminal Services application too, so that would get you back to square 1, I guess.

    Regards,

     


    -Ran
    Thursday, March 24, 2011 11:14 AM
  • OK, but if I publish a TS that has SF disabled, why would it automatically try and use SF and not SSL Wrapper?  What's the point of giving the option?  Why doesn't it just detect what O/S is installed and use the appropriate method?  ...I guess that's a perfect world scenario...

     

    I'm going to try publishing a TS w/ SF disabled and uninstalling UAG components on the client today.  I'm pretty sure last time I didn't uninstall the UAG components before trying the newly published TS that didn't have SF enabled.   It just really sucks that every time the UAG config is updated everybody gets kicked off our VPN. 

     

    Thanks again for all your help.  I'll keep this thread updated with my results.

    Thursday, March 24, 2011 1:38 PM
  • No luck! :(

    What I did:

    1.Published a TS with SF Disabled.
    2.Uninstalled Whale components on client (even went through registry and cleaned out all traces)
    3.Did a 'netsh winsock reset catalog'
    4.Restarted client
    5.Went to our UAG Site
    6.Logged on/Installed components

    Got the same error when I tried to launch the new TS.  A box pops up with header "SSL Application Tunneling" and the body:
    "This application did not start because the Operating System is not supported"

    The SSL Tunneling icon was in the toolbar and running with our site/ports in the connections

    I did find a registry setting that leads me to believe it is launching the 32 bit version of MSTSC as well.

    I'm stumped and frustrated...  Do you have anymore ideas??

    Friday, March 25, 2011 7:31 PM
  • Hi

    I'm sorry for your frustration. I was finally able to set up a lab with IAG and with a 64-bit Vista client and I reproduced the issue. There are a couple of possible workarounds that I can think of, and I will give them a try tomorrow, and let you know.

    Regards,


    -Ran
    Sunday, March 27, 2011 4:12 PM
  • Hi again,

    I think I got the customization needed in order to work around the issue. Please follow these steps:

    1.   Copy the file SSLVPNTemplates.xml from the \Whale-Com\e-Gap\von\conf folder, to the \Whale-Com\e-Gap\von\conf\CustomUpdate folder

    2.   Open for editing the SSLVPNTemplates.xml file in the CustomUpdate folder, and locate the section that starts with: <template name="MSTSAC 800*600" We will customize this IAG application publishing template, so that it will allow running MSTSC also on a Vista 64-bit OS. You will need to delete all the other application templates from this custom XML file, both above and under this template. However, you need to make sure that you maintain the correct XML syntax of the entire file

    3.   The original MSTSAC template has a userrights attribute with a value of 16384. In your custom SSLVPNTemplates.xml file, change this value to 0 (zero)

    4.   The end result should be this:

    <config>

    <templates version="3" use-lsp="1">

    <!--
    *********************************************************************************
    ** Windows XP Terminal Services Client - variable screen resolution **
    *********************************************************************************
    -->

    <!-- Auto-Sense mode -->
    <template name="MSTSAC 800*600" userrights="0" use-with-lsp="yes" win="yes"><!--Windows-->
    <port id="0" remoteport="3389" localport="23456" flags="10" />
    <exec exe="mstsc.exe -v:%localip%:%localport% -w:%HRes% -h:%VRes%" flags="4" param="" use-with-lsp="no"/>
    <exec exe="mstsc.exe -w:%HRes% -h:%VRes% -v:%leadserver%" flags="4" param="" use-with-lsp="only"/>
    <config-file flags="33" path="" ><![CDATA[
    [1\Software\Microsoft\Terminal Server Client\Default]
    MRU0=C%localip%:%localport%
    Full Address=C%localip%:%localport%
    ]]>
    </config-file>
    </template>
    </templates>
    </config>

    4.   Save the modified file. Attempt to open the file in IE or in an XML editor, to ensure that the XML syntax is correct

    5.   Activate the configuration

    6.   Test from the Vista 64-bit client machine

     

    Regards,

    -Ran

    • Marked as answer by nmuleski Monday, April 4, 2011 9:54 PM
    Monday, March 28, 2011 10:01 AM
  • Hello again,

    I finally have the time to try this work around today.  I have the template modified to look near to what you have listed above. 

    My only question before I proceed with activating the configuration is this:  Will this publish another TS or will it modify my current setup? 

     

    I really do appreciate all the help!

    Monday, April 4, 2011 1:58 PM
  • Hi again,

    I think I got the customization needed in order to work around the issue. Please follow these steps:

    1.   Copy the file SSLVPNTemplates.xml from the \Whale-Com\e-Gap\von\conf folder, to the \Whale-Com\e-Gap\von\conf\CustomUpdate folder

    2.   Open for editing the SSLVPNTemplates.xml file in the CustomUpdate folder, and locate the section that starts with: <template name="MSTSAC 800*600" We will customize this IAG application publishing template, so that it will allow running MSTSC also on a Vista 64-bit OS. You will need to delete all the other application templates from this custom XML file, both above and under this template. However, you need to make sure that you maintain the correct XML syntax of the entire file

    3.   The original MSTSAC template has a userrights attribute with a value of 16384. In your custom SSLVPNTemplates.xml file, change this value to 0 (zero)

    4.   The end result should be this:

    <config>

    <templates version="3" use-lsp="1">

    <!--
    *********************************************************************************
    ** Windows XP Terminal Services Client - variable screen resolution **
    *********************************************************************************
    -->

    <!-- Auto-Sense mode -->
    <template name="MSTSAC 800*600" userrights="0" use-with-lsp="yes" win="yes"><!--Windows-->
    <port id="0" remoteport="3389" localport="23456" flags="10" />
    <exec exe="mstsc.exe -v:%localip%:%localport% -w:%HRes% -h:%VRes%" flags="4" param="" use-with-lsp="no"/>
    <exec exe="mstsc.exe -w:%HRes% -h:%VRes% -v:%leadserver%" flags="4" param="" use-with-lsp="only"/>
    <config-file flags="33" path="" ><![CDATA[
    [1\Software\Microsoft\Terminal Server Client\Default]
    MRU0=C%localip%:%localport%
    Full Address=C%localip%:%localport%
    ]]>
    </config-file>
    </template>
    </templates>
    </config>

    4.   Save the modified file. Attempt to open the file in IE or in an XML editor, to ensure that the XML syntax is correct

    5.   Activate the configuration

    6.   Test from the Vista 64-bit client machine

     

    Regards,

    -Ran


    Hi Ran - can you explain why this is needed?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Monday, April 4, 2011 2:52 PM
  • My only question before I proceed with activating the configuration is this:  Will this publish another TS or will it modify my current setup?

    Hi,

    This customization will modify your current setup, it will not add an additional TS application to your trunk.

    Regards,


    -Ran
    Monday, April 4, 2011 5:49 PM

  • Hi Ran - can you explain why this is needed?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Hi Jason,

    This is needed because nmuleski has asked for it! Nah, just kidding :)

    This is needed since in the original, default, SSLVPNTemplates.xml file the template for the TS application limits which client OSes can launch it, and Vista 64-bit is not among those that are allowed to do so.

    Regards,


    -Ran
    Monday, April 4, 2011 5:55 PM
  • It worked!  A million thanks to you sir!

     

    I wonder why this was necessary though...  When I publish something to UAG I'm asked to define the managing policy and one of those options is selecting what O/Ss are allowed to access the published content.  Why doesn't simply selecting "Windows Vista 64 bit" do the same thing?

     

    I'm nit picking, but it something I'd be interested to know.

     

     

    Monday, April 4, 2011 9:58 PM
  • It worked!  A million thanks to you sir!

     Awesome, you're welcome!

    I wonder why this was necessary though...  When I publish something to UAG I'm asked to define the managing policy and one of those options is selecting what O/Ss are allowed to access the published content.  Why doesn't simply selecting "Windows Vista 64 bit" do the same thing?

     

    I'm nit picking, but it something I'd be interested to know.

    Well, you are right, from your point of view, that it looks like something that should/could be controlled by the UAG endpoint policies. Yes, you do have the option to set policies to allow or deny access to specific apps based on specific client OS. However, in this specific case, for whatever reason, tunneling of TS from Vista 64-bit client OS is not blocked due to an endpoint policy, but rather by a setting that you can think of as a "factory setting". This is what we changed by creating a custom SSLVPNTemplates.xml file.

    Regards,


    -Ran
    Tuesday, April 5, 2011 11:26 AM