none
Issues with name resolution, NLS and IPSec with DirectAccess server 2012 and Windows 7 clients

    Domanda

  • Hi all,

    I have been struggling finalise the configuration of my DirectAccess test lab for a few days and I was wondering if you could help.

    I believe there is a problem with the certificates being used by Directaccess.

    Here are some of the details of the configuration and the errors I am having, any assistance in troubleshooting would be greatly appreciated, I am sure it is something silly I have missed somewhere.

    At this moment in time the clients cannot see the NLS server which is currently running on the DirectAccess server. I have a CA running on the DirectAccess server (I would like to emphasise that this is a lab environment for a proof of concept).

    Clients appear to believe they are outside of the network at all times.

    DNS queries cannot be resolved externally and don't work internally unless DA is disabled.

    I have two Public Addresses - 90 and 91 configured on the external adaptor of the DA server.

    The Teredo and IPHTTPS tunnel both appear to be working however, IPsec does not.

    Here are is the output from a few commands I have been using to troubleshoot : 

    C:\Users\administrator.HRWPOC>netsh name sh eff

    DNS Effective Name Resolution Policy Table Settings


    Settings for nla.hrwpoc.local
    ----------------------------------------------------------------------
    Certification authority                 :
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              :
    DirectAccess (Proxy Settings)           : Use default browser settings

     

    Settings for .hrwpoc.local
    ----------------------------------------------------------------------
    Certification authority                 :
    DNSSEC (Validation)                     : disabled
    IPsec settings                          : disabled
    DirectAccess (DNS Servers)              : 2002:560c:9ff6:3333::1
    DirectAccess (Proxy Settings)           : Bypass proxy







    C:\Users\administrator.HRWPOC>netsh dns sh st

    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:\Users\administrator.HRWPOC>netsh int ter sh st
    Teredo Parameters
    ---------------------------------------------
    Type                    : client
    Server Name             : teredo.ipv6.microsoft.com.
    Client Refresh Interval : 30 seconds
    Client Port             : unspecified
    State                   : qualified
    Client Type             : teredo host-specific relay
    Network                 : unmanaged
    NAT                     : restricted
    NAT Special Behaviour   : UPNP: No, PortPreserving: No
    Local Mapping           : 192.168.1.34:58435
    External NAT Mapping    : 62.49.42.253:19054



    C:\Users\administrator.HRWPOC>netsh int htt sh int

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://dapoc.contoso.com:443/IPHTTPS
    Last Error Code            : 0x0
    Interface Status           : IPHTTPS interface active



    IPsec Events 

     

    An IPsec main mode negotiation failed.

    Local Endpoint:

    Local Principal Name: -

    Network Address: 2002:560c:9ff6:1000:402c:1c2d:615d:81a2

    Keying Module Port: 500

    Remote Endpoint:

    Principal Name: -

    Network Address: 2002:560c:9ff6::560c:9ff6

    Keying Module Port: 500

    Additional Information:

    Keying Module Name: IKEv1

    Authentication Method: Unknown authentication

    Role: Initiator

    Impersonation State: Not enabled

    Main Mode Filter ID: 0

    Failure Information:

    Failure Point: Local computer

    Failure Reason: No policy configured

    State: No state

    Initiator Cookie: 5fbac6fee3d5fe96

    Responder Cookie: 0000000000000000

     

     

     

     

    An IPsec main mode negotiation failed.

    Local Endpoint:

    Local Principal Name: -

    Network Address: 2002:560c:9ff6:1000:402c:1c2d:615d:81a2

    Keying Module Port: 500

    Remote Endpoint:

    Principal Name: -

    Network Address: 2002:560c:9ff6::560c:9ff6

    Keying Module Port: 500

    Additional Information:

    Keying Module Name: AuthIP

    Authentication Method: Unknown authentication

    Role: Initiator

    Impersonation State: Not enabled

    Main Mode Filter ID: 67359

    Failure Information:

    Failure Point: Local computer

    Failure Reason: Negotiation timed out

    State: Sent first (SA) payload

    Initiator Cookie: 8ece33e6340d05e8

    Responder Cookie: 0000000000000000





    As I said any help would be massively appreciated I will try and be as responsive as possible if anyone requires any more information.



    Thanks !



    Adam


    venerdì 2 agosto 2013 08:43

Tutte le risposte

  • What is your client says when it is inside the corp net? Is DNS client shows inside corpnet?

    It is recommended to run NLS server out of DA box.

    venerdì 2 agosto 2013 13:48
  • I have now resolved the NLS issue, the IP-HTTPS binding overwrote the SSL binding for NLS. 

    I have added a second IPv4 Address to the DA server and bound the HTTPS certificate to the new IP. NLS is now working as expected.

    From there I have enabled auditing of IPsec on both the server and client and I could not see the failure events on the server. After checking it would appear that after I changed the original IP's post the setup wizard the group policy IPsec IP's have not changed.

    Which IP's should be used for IPsec endpoints in directaccess in Group policy ? 

    venerdì 2 agosto 2013 13:51
  • <style type="text/css"><!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } --> </style>

    Hi,

    Regarding IPsec issue, I had similar problem, "An IPsec main mode negotiation failed........ble ble ble "

    Resolution in my case was - additional firewall rule (wf.msc) on Direct Access server - allow port UDP 500 (don't remember if it was for In or Out connections, check with both for tests)

    This solved my problem.

    regards

    domenica 4 agosto 2013 19:10
  • I would take a step back and build your lab out the right way. In production you shouldn't be putting NLS on the DirectAccess server, and especially not the CA role! Since it's a lab I assume you have virtual machines available to you and you should really start over and do it right. You could cause all kinds of strange issues that you are never going to encounter in your live environment.
    martedì 6 agosto 2013 13:26
  • I think I am at the bottom of them at the moment its just the ipsec tunnel, everything else appears to be working now. 

    It looks like the tunnel is attempting to connect to the wrong IP, I have enabled logging on both ends and I cannot see failures on the direct access box, it looks like it is either blocked or connecting to the wrong IP. 

    I am intending to rebuild the lab next week but I would really like to see a working solution on the current one before I tear it down. 

    Any help would be appreciated.

    martedì 6 agosto 2013 14:00
  • Did you re-run the DA wizards to make sure that the appropriate IPs are now selected? The wizard populates the GPOs with the information that the clients need to connect. If you changed IPs and didn't re-run the consoles, the clients could still be pointing to the wrong IPs. Also if you updated the GPOs but the clients haven't pulled down the new copy of those GPOs yet, it would cause the same thing.
    martedì 6 agosto 2013 14:57