none
UAG DA some clients work, some don't RRS feed

  • Question

  • We have deployed UAG DA and for some clients, mostly ones that connect to the domain normally and are then taken home or on the road, seem to always work. However the ones we have deployed to remote offices only seem to work for the first few days and then the DCA logs looks like this:

     

    C:\Windows\system32\LogSpace\{289B8D90-2639-48D3-83E5-8CC4505284DC}>netsh int teredo show state
    Teredo Parameters
    ---------------------------------------------
    Type                    : client
    Server Name             : 12.x.x.x (Group Policy)
    Client Refresh Interval : 30 seconds
    Client Port             : unspecified
    State                   : offline
    Error                   : general system failure
    Error Code              : 30


    C:\Windows\system32\LogSpace\{289B8D90-2639-48D3-83E5-8CC4505284DC}>netsh int httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://xx.xxx.xxx:443/IPHTTPS
    Last Error Code            : 0x80092013
    Interface Status           : failed to connect to the IPHTTPS server. Waiting to reconnect

     

    I can browse to the CRL from the internet and we do not run any other VPN clients.

    Friday, April 1, 2011 5:31 PM

Answers

All replies

  • Have you checked the windows firewall in whether client pc and opened the necessary ports. It seems like the ports are not opened. Second thing you can check is whether the necessary gpo have been correctly applied. You may want to put the outcome of the following command.

    netsh advf monitor show mmsa

     

    -Ashish

    Friday, April 1, 2011 11:21 PM
  • I would look at setting the Teredo default state to Enterprise Client as discussed here: http://blogs.technet.com/b/tomshinder/archive/2010/05/27/directaccess-and-teredo-adapter-behavior.aspx

    If fall back to IP-HTTPS is also failing, you may want to consider using a public certificate to eliminate portential CRL publishing issues...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Sunday, April 3, 2011 12:26 AM
    Moderator
  • Ashish,

    I have checked all of that, it does work for a few days and then stops so I think everything is getting deployed correctly with GPO.

    Monday, April 4, 2011 11:57 AM
  • Jason,

    I set the client to enterpriseclient, but still no luck. Any idea why it would work for a few days and then stop working? Does CRL checking have any kind of caching function?

    Monday, April 4, 2011 12:07 PM
  • CRL lifetime probably depends on your PKI setup, but the IP-HTTPS error you mention seems to imply CRL issues.

    Putting IP-HTTPS and CRLs to one side for a moment, I don't understand why Teredo would also fail...I've not seen both of them fail at once (especially if it works initially) :(

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Monday, April 4, 2011 12:12 PM
    Moderator
  • CRL lifetime probably depends on your PKI setup, but the IP-HTTPS error you mention seems to imply CRL issues.

    Putting IP-HTTPS and CRLs to one side for a moment, I don't understand why Teredo would also fail...I've not seen both of them fail at once (especially if it works initially) :(

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Ye, it is very hard to explain why they work for a few days, especially to the people that are trying to use it. Does teredo do any certificate checking? That would point me further towards a CRL/PKI issue, even though I can browse to the CRL and open the text file every time in the browser.
    Monday, April 4, 2011 12:25 PM
  • No, by default, IPsec peer authentication with certificates does not perform certificate revocation checking; so it probably another issue. It may be worth enabling some IPSec logging to see what happens when the clients fail:

    auditpol /set /subcategory:”IPsec Main Mode”,“IPsec Extended Mode” /success:enable /failure:enable

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Monday, April 4, 2011 2:27 PM
    Moderator
  • This got teredo working on my test machine, I am having our support guys try it on some other users:

    Start - All Programs - Accessories and right click on Command Prompt, select "Run as Administrator" to open a command prompt.

    Reset WINSOCK entries to installation defaults: netsh winsock reset catalog

    Reset IPv4 TCP/IP stack to installation defaults. netsh int ipv4 reset reset.log

    Reset IPv6 TCP/IP stack to installation defaults. netsh int ipv6 reset reset.log

    Reboot the machine.

    Not sure what the issue is, but resetting the IP stacks and winsock seemed to work.

    Tuesday, April 5, 2011 5:01 PM
  • How odd, you got any idea what happened to these machines?

    Is IP-HTTPS still failing?

    Anyhow, thanks for updating the thread with some good news! :)

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    • Marked as answer by Erez Benari Thursday, May 5, 2011 6:25 PM
    Tuesday, April 5, 2011 10:38 PM
    Moderator