none
Issues with new UAG DirectAccess Installation. RRS feed

  • Question

  • Hi there, only new to UAG and have just implemented my first system following the lab set out in: http://www.microsoft.com/download/en/details.aspx?id=17146

    After running the lab a few times I have got through it without any installation errors. 

    Setup is as follows:

    DOMAIN-001: Domain Controller, DNS

    NLS-001: Network Location Server

    DHCP-001: DHCP Server

    UAG-001: Unified Access Gateway

    ROAM-006: The Windows 7 Ultimate Client

    I am initially trying to connect from inside the corporate network but am receiving the following errors on the client when I try to connect to a Shared Resource:

    ------------------------------------------------------------------------------------------------

    Windows Network Diagnostics

    Publisher details

    Issues found

    Windows can't communicate with the device or resource (Teredo server)

    Windows can't communicate with the device or resource (Teredo server)

    The device or resource is not responding to requests.

    Detected

    Contact your network administrator or Internet service provider (ISP)

    Completed

    Windows received an HTTP error message: 403 (Forbidden) from "uag-001.domain.com.au"

    Windows received an HTTP error message: 403 (Forbidden) from "uag-001.domain.com.au"

    Detected

    Contact the owner of the remote site for permission

    Completed

     

     

     

    Issues found

    Detection details

    6

    Windows can't communicate with the device or resource (Teredo server)

    Detected

    The device or resource is not responding to requests.

    Contact your network administrator or Internet service provider (ISP)

    Completed

    Windows can't communicate with the device or resource (Teredo server). If you are at home, contact your ISP. Otherwise, contact your network administrator for assistance.

     

     

     

    5

    Windows received an HTTP error message: 403 (Forbidden) from "uag-001.domain.com.au"

    Detected

    Contact the owner of the remote site for permission

    Completed

    Windows can reach the site, but you do not have permission to access the content.

    Detection details

     

     

     

    Diagnostics Information (IPHTTPS)

    Details about IPHTTPS diagnosis:

    Interface iphttpsinterface Parameters

    ------------------------------------------------------------

    Total bytes received       : 0

    Total bytes sent           : 0

     

    Interface IPHTTPSInterface (Group Policy)  Parameters

    ------------------------------------------------------------

    Role                       : client

    URL                        : https://uag-001.domain.com.au:443/IPHTTPS

    Last Error Code            : 0x800b0109

    Interface Status           : failed to connect to the IPHTTPS server. Waiting to reconnect

     

     

     

     

    Diagnostics Information (Teredo)

    Details about Teredo diagnosis:

     

    Teredo Parameters

    ---------------------------------------------

    Type                    : client

    Server Name             : 203.35.237.XXX (Group Policy)

    Client Refresh Interval : 30 seconds

    Client Port             : unspecified

    State                   : probe (primary server)

    Client Type             : teredo client

    Network                 : unmanaged

    ------------------------------------------------------------------------------------------------

    I am unsure as to what the issue is.

    I am also unsure as to whether or not my ISP has correctly configured to two sequential external IP's, what is the best way to troubleshoot this?

    Any help would be greatly appreciated. 


    • Edited by appyours Thursday, December 1, 2011 4:14 AM
    Thursday, December 1, 2011 4:12 AM

All replies

  • Am I correct in understanding that the client, when on the internal network, cannot access internal resources?

     

    The log snippet above seems to indicate that the client cannot reach the NLS.

     

    For easier troubleshooting, I'd recommend that you deploy the DCA in your testenvironment as per http://technet.microsoft.com/en-us/library/gg502552.aspx.


    Hth, Anders Janson Enfo Zipper
    Thursday, December 1, 2011 9:53 AM
  • Correct,

    since adding the computer to the Direct Access group and applying the GPO the machine no longer has access to shared resources and cannot even ping the domain controller, nls or uag servers. 

    Any ideas?

    I will take a look at the DCA and see what I can come up with, thanks for the advice.

    Thursday, December 1, 2011 12:26 PM
  • Yes I agree, based on the information provided (though DCA logs would be better) it seems Windows is trying to troubleshoot the DA connection, which would imply it is trying to create a DA connection - and when you are inside the corporate network it should not be trying to establish the DA tunnels. Which could mean the client is not validating connectivity to the NLS website correctly.

    netsh name show effective

    If you run this command and see your NRPT entries - that means the NLS website was not successfully contacted (you should only see your NRPT show up in the output of this command when you are outside of your corporate network)

    Thursday, December 1, 2011 1:31 PM
  • Running netsh name show effective gives the following response listed below, any ideas?
    DNS Effective Name Resolution Policy Table Settings
    Settings for nls.domain.com.au
    ----------------------------------------------------------------------
    Certification authority                 : DC=au, DC=com, DC=domain, CN=domain-DOMAIN-001-CA
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Use default browser settings
    Settings for uag-001.domain.com.au
    ----------------------------------------------------------------------
    Certification authority                 : DC=au, DC=com, DC=domain, CN=domain-DOMAIN-001-CA
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Use default browser settings
    Settings for .domain.com.au
    ----------------------------------------------------------------------
    Certification authority                 : DC=au, DC=com, DC=domain, CN=domain-DOMAIN-001-CA
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              : 2002:cb23:eddb::cb23:eddb
    DirectAccess (Proxy Settings)           : Bypass proxy
    Thursday, December 1, 2011 11:56 PM
  • You need to validate your Network Location Service configuration. Can the client, while on the inside, ping the NLS? Can you browse the NLS site on https://whatever-internal-url-you-have-defined? (you should be able to)

    Furthermore, configure the DirectAcces Connectivity Assistant through UAG and deploy it to the client. It will help you to get more diagnostic data.

    Question, if you move the client to the external network, does the DA connection work?


    Hth, Anders Janson Enfo Zipper
    Monday, December 5, 2011 7:37 PM
  • Sorry appyours, the forums never emailed me when you replied...and now they are being very cranky today :)

    Anyhow, as Anders stated if you see all of this information from a netsh name show effective while you are inside your corporate network, this is definitely what is causing the trouble you are seeing and it means that your client is not correctly contacting the NLS website. One question - are you using the default IIS7 website for the NLS website? If so, please swap out that default page with a simple default.htm file that simply says "This is the NLS website for DirectAccess" or something like that. I have had more than a few installations where the default IIS7 webpage would not work as the NLS site, and as soon as we ditched that page and put in our own page with simple text, then NLS worked great.

    Tuesday, December 6, 2011 7:12 PM
  • Anders, 

     

    Thanks for your response, I cannot seem to ping or browse any internal resources from the test machine since the polices went in to effect. I have installed DCA but am not having much luck with the configuration of it. The machine will not connect when outside the network either :(

    Wednesday, December 7, 2011 1:22 PM
  • Try browsing to the NLS website from another machine on your corporaet network - you should be able to hit https://nlssite from any machine inside your network, and you should be able to view the site without any certificate warnings - if you get any warnings or errors that would explain why your DA machine thinks it is outside the network and is trying to establish DA tunnels. Again, if you are using the default IIS7 page for the NLS site, swap it out with something else.

    Once you get the NLS website working correctly, the DA machine will recognize that it's inside the corporate network again and the NRPT will turn itself off, which will then allow your internal communications to work again.

    Wednesday, December 7, 2011 2:08 PM