none
UAG - DA Client "Corporate connectivity is not working correctly."

    General discussion

  • Hello, I have setup the UAG- DA access as per the guide and facing some issues. I want to know is this proper setup for the DA.

    1. My external DA site gives this message. "403 - Forbidden: Access is denied " screen. Is this normal.

    2. AT UAG server in the DA monitor -Active sessions I can see the DA client Intranet Session however ,  the certificate tab is empty. Is this normal.

    3. When I connect to internet I gets the message " Corporate connectivity is not working correctly" message . The DTE configured are pingable however the local access  to the resource fails.

    Please let me know if this log throws any clue to further troubleshoot.

    C:\Windows\system32\LogSpace\{0ABE63B8-3C8E-4AA7-AD0E-90CCF26132DD}>netsh int teredo show state
    Teredo Parameters
    ---------------------------------------------
    Type                    : client
    Server Name             : IP Adress (Group Policy)
    Client Refresh Interval : 30 seconds
    Client Port             : unspecified
    State                   : offline
    Error                   : client is in a managed network


    C:\Windows\system32\LogSpace\{0ABE63B8-3C8E-4AA7-AD0E-90CCF26132DD}>netsh int httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://uag.domain.net:443/IPHTTPS
    Last Error Code            : 0x0
    Interface Status           : IPHTTPS interface deactivated


    C:\Windows\system32\LogSpace\{0ABE63B8-3C8E-4AA7-AD0E-90CCF26132DD}>netsh dns show state

    Name Resolution Policy Table Options
    --------------------------------------------------------------------

    Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                            if the name does not exist in DNS or
                                            if the DNS servers are unreachable
                                            when on a private network

    Query Resolution Behavior             : Resolve only IPv6 addresses for names

    Network Location Behavior             : Let Network ID determine when Direct
                                            Access settings are to be used

    Machine Location                      : Outside corporate network

    Direct Access Settings                : Configured and Enabled

    DNSSEC Settings                       : Not Configured


    C:\Windows\system32\LogSpace\{0ABE63B8-3C8E-4AA7-AD0E-90CCF26132DD}>netsh name show policy

    DNS Name Resolution Policy Table Settings

    Settings for gdc-sccm-2007.site.domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Use default browser settings



    Settings for .domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              : 2002:7d3f:5927::7d3f:5927
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Bypass proxy




    C:\Windows\system32\LogSpace\{0ABE63B8-3C8E-4AA7-AD0E-90CCF26132DD}>netsh name show effective

    DNS Effective Name Resolution Policy Table Settings


    Settings for gdc-sccm-2007.site.domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Use default browser settings



    Settings for .domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              : 2002:7d3f:5927::7d3f:5927
    DirectAccess (Proxy Settings)           : Bypass proxy




     

     



    • Edited by Dharm Singh Tuesday, September 27, 2011 10:54 AM
    Tuesday, September 27, 2011 10:49 AM

All replies

  • Saw this:

    Error: client is in a managed network

    Where are you testing the DA client?

    Maybe look at this: http://blogs.technet.com/b/tomshinder/archive/2010/05/27/directaccess-and-teredo-adapter-behavior.aspx

    Cheers

    JJ

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, September 27, 2011 11:23 AM
    Moderator
  • I am testing the DA client form outside ( internet ). The ping to the DTE's is working however neither ping to corporate DNS or IP 6 to any corporate resource is not working.

     

    Tuesday, September 27, 2011 11:36 AM
  • Odd that the client thinks it is in a managed network then :S

    If you disable the Teredo interface, does IP-HTTPS work?

    This might be worth a look too: http://blogs.technet.com/b/tomshinder/archive/2011/04/19/ipv6-and-directaccess-troubleshooting-cheat-sheets.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, September 27, 2011 11:40 AM
    Moderator
  • I tried with this command which does not seems to be proper one. Please advice.

    C:\>netsh interface teredo set disable
    The following command was not found: interface teredo set disable.

     

     

    Tuesday, September 27, 2011 11:46 AM
  • netsh int teredo set state disabled
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, September 27, 2011 11:48 AM
    Moderator
  • Thank You. However after teredo disable it is still not working . Here is the new log .

    C:\Windows\system32\LogSpace\{174B0298-D329-450A-A771-8AD857CE6375}>netsh int teredo show state
    Teredo Parameters
    ---------------------------------------------
    Type                    : disabled
    Server Name             : Public IP (Group Policy)
    Client Refresh Interval : 30 seconds
    Client Port             : unspecified
    State                   : offline
    Error                   : client is in a managed network


    C:\Windows\system32\LogSpace\{174B0298-D329-450A-A771-8AD857CE6375}>netsh int httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://uag.domain.net:443/IPHTTPS
    Last Error Code            : 0x0
    Interface Status           : IPHTTPS interface deactivated


    C:\Windows\system32\LogSpace\{174B0298-D329-450A-A771-8AD857CE6375}>netsh dns show state

    Name Resolution Policy Table Options
    --------------------------------------------------------------------

    Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                            if the name does not exist in DNS or
                                            if the DNS servers are unreachable
                                            when on a private network

    Query Resolution Behavior             : Resolve only IPv6 addresses for names

    Network Location Behavior             : Let Network ID determine when Direct
                                            Access settings are to be used

    Machine Location                      : Outside corporate network

    Direct Access Settings                : Configured and Enabled

    DNSSEC Settings                       : Not Configured


    C:\Windows\system32\LogSpace\{174B0298-D329-450A-A771-8AD857CE6375}>netsh name show policy

    DNS Name Resolution Policy Table Settings

    Settings for gdc-sccm-2007.india.domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Use default browser settings



    Settings for .domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    DNSSEC (IPsec)                          : disabled
    DirectAccess (DNS Servers)              : 2002:7d3f:5927::7d3f:5927
    DirectAccess (IPsec)                    : disabled
    DirectAccess (Proxy Settings)           : Bypass proxy




    C:\Windows\system32\LogSpace\{174B0298-D329-450A-A771-8AD857CE6375}>netsh name show effective

    DNS Effective Name Resolution Policy Table Settings


    Settings for gdc-sccm-2007.india.domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Use default browser settings



    Settings for .domain.local
    ----------------------------------------------------------------------
    Certification authority                 : DC=local, DC=domain, CN=ca
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              : 2002:7d3f:5927::7d3f:5927
    DirectAccess (Proxy Settings)           : Bypass proxy



    Tuesday, September 27, 2011 11:52 AM
  • Time to follow the cheat sheet and post back your findings ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, September 27, 2011 11:53 AM
    Moderator
  • There seems to be issue with the state of IP-HTTPS 

    Interface Status           : IPHTTPS interface deactivated

    On the DA server the status is Active. However on the DA client it is deactivated.

    Will keep posting the progress , any help would be appreciated.

     

    Regards

     


    Tuesday, September 27, 2011 11:56 AM
  • I am using CRLD Distribution point on the UAG server itself. The CRLD URL is https:\\uag.domain.net\crld which is accessible  from the DA client.

    Does having CRLD on same UAG server is an issue.

    Regards

    Tuesday, September 27, 2011 2:03 PM
  • I would always recommend using a certificate from a public CA for IP-HTTPS...a lot of the potential CRL publishing issue go away then ;)

    I am not sure that is your actual problem however, as you get a different error on the IP-HTTPS interface in the case of CRL access failures...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, September 27, 2011 2:07 PM
    Moderator
  • Is this normal when you configured.

    1. My external DA site gives this message. "403 - Forbidden: Access is denied " screen. Is this normal.

    2. AT UAG server in the DA monitor -Active sessions I can see the DA client Intranet Session however ,  the certificate tab is empty. Is this normal.

     

    Thanks

    Tuesday, September 27, 2011 3:16 PM
  • Yes to both questions. The 403 is exactly what you should see. If you receive some kind of certificate warning prompt then you know you have a problem with the certificate. If you get directly to the 403, then the cert is typically setup correctly.

    I am looking at numerous IP-HTTPS connections on a DA box right now and none of them show anything in the Certificate field in UAG Web Monitor.

    So now that you are seeing the tunnel inside Web Monitor, is DA working? And does IP-HTTPS now show as connected successfully? In the Web Monitor you can also check to see what method the laptop is using to connect under "Transition Mode" - does that show IP-HTTPS?

    Tuesday, September 27, 2011 7:22 PM
  • Thank you Jordan , Yes I can see DA client having IP-HTTPS , Teredo and 6to4 transition mode.However ,  I am able to ping and access only couple of machines from outside network from DA client not all of them.

    Still working to troubleshoot this.

    Thanks

     

    Wednesday, September 28, 2011 5:28 AM
  • So, do you have a working connection now?

    Can you post your diagnostic output again if so?

    If so, what can and can't you connect to? Do the things you can connect to, correspond with the management servers you defined during setup?

    Be good to understand exactly where you are at this time, to help further...

    Cheers

    JJ 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, September 28, 2011 7:54 AM
    Moderator
  • Hello Jason ,

                         I am able to ping and access the corporate network from DA client now. The issue was related to IP 6 prefix which was implemented on corporate resources from Group policy of another previous DA implementation. I deleted those GP's and now the DA seems to be working fine. However , I have few question at this moment.

    1. I am able to ping and access corporate network form DA client using FQDN only. Is this the way we have to access the network as we might need to know FQDN of all the network resources before accessing them and IPv4 does not works after the connection.

    2. How can we manage or access the DA client from corporate network. I tried to ping and access the RDP of the connect DA client . However was not able to do that. Is there anything we which have to configure for managing the DA clients.

    3. Once more thing I noticed that I can not access the NLS point after the connection however Can access other corporate resources.

     

    Please advice.

     

    Regards

     

    Wednesday, September 28, 2011 9:46 AM
  • Hi Dharm,

    A1: Correct, that is by design. If you need to access IPv4 resources that are not in DNS already, you will need to create a "fake" name so that DNS64 will provide an address for NAT64. Alternatively, you can "predict" the NAT64 address as discussed here: http://blogs.technet.com/b/tomshinder/archive/2010/07/14/considerations-when-using-ping-to-troubleshoot-directaccess-connectivity-issues.aspx

    A2: You will need to manage DA clients from machines that are IPv6 capable because the NAT64 feature only works inbound, not outbound. You will also need to make some changes on the Windows 7 firewall to support remote management from internal clients as discussed here: http://blogs.technet.com/b/edgeaccessblog/archive/2010/12/01/uag-directaccess-and-the-windows-firewall-with-advanced-security-things-you-should-know.aspx

    A3: Correct, that is by design. If the DA client could access the NLS remotely, it would then turn off DirectAccess ;) If you need to access other resources on the NLS server, you need to consider assigning multiple IP address to the server so that you can isolate the NLS website.

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, September 28, 2011 9:58 AM
    Moderator
  • Hi Jason , Thank you for help and support the DA seems to be working fine for now.

    Right now we are accessing the corporate network using the ISATAP IPv6 address . i.e Ipv6 prefix::IPv4 which works well.

    I will check the post regarding managing the DA clients from corporate .

     

    Thanks

     

    Wednesday, September 28, 2011 10:24 AM
  • Ok, if you have ISATAP clients, these should be able to manage DA clients just fine as that satifies the IPv6 capable requirement; assuming Windows Firewall on those remote DA clients is configured appropriately (as above).

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, September 28, 2011 10:31 AM
    Moderator
  • Hi Jason , There seems to be one issue. Earlier the ping from DA client was working fine now it seems to be stopped . Earlier DNS was resolving 2002:7d3f:xxxx:xxxx:x:xxxx:10.9.21.8 which was accessible , however now it is resolving 2002:630c:xxxx:xxxx:x:xxxx:10.9.21.8 which is not accessible. Moreover , I can access the same internal resource by using the 2002:7d3f:xxxx:xxxx:x:xxxx: in place of 2002:630c:xxxx:xxxx:x:xxxx:

    When I checked the DA client GP policy under Windows Settings---> Security Settings --> Windows Firewall With Advanced Security--> Connection Security Settings--> Rules

    Here I have Endpoint  1 Configuration as " Any" and Endpoint 2 Configuration as

    2002:7d3f:xxxx.xxxx::xxx:2007, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.32.7, 2002:7d3f:xxxx.xxxx::xxx:1508, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.21.8, 2002:630c:xxxx.xxxx.x.xxxx:10.9.21.8, 2002:7d3f:xxxx.xxxx::xxx:150a, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.21.10, 2002:630c:xxxx.xxxx.x.xxxx:10.9.21.10, 2002:7d3f:xxxx.xxxx::xxx:2029, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.32.41, 2002:7d3f:xxxx.xxxx::xxx:10cb, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.16.203, 2002:7d3f:xxxx.xxxx::xxx:2029, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.32.41, 2002:7d3f:xxxx.xxxx::xxx:154b, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.21.75, 2002:7d3f:xxxx.xxxx::xxx:201a, 2002:7d3f:xxxx.xxxx.x.xxxx:10.9.32.26, 2002:7d3f:xxxx::xxxx:xxxx

    Is this any sort of misconfiguration.

     

    Regards

    Friday, September 30, 2011 9:28 AM
  • I found the reason and posting it assuming it may be help for others.

    The address's "2002:630c:xxxx.xxxx.x.xxxx:10.9.21.10" were coming in the DA GPO as the DC's were having entry for this address in DNS servers. This was due to the previous implementation, after removing the static entries from the DNS servers and deleted all DA related GPO's now the UAG apply policies wizard is showing the correct Ipv6 ISTAP address.

    Now applying the new policy.

     

    Regards


    • Edited by Dharm Singh Tuesday, October 04, 2011 12:19 PM
    Tuesday, October 04, 2011 11:59 AM