none
DirectAccess - Connected, but cannot access anything RRS feed

  • Question

  • Hi There,

    I'm having trouble connecting to services over DirectAccess. I have successfully established connection, and can ping devices, but that's all, nothing else works, including DNS.

    Where would be the best place to start troubleshooting?

    Thursday, March 22, 2012 10:35 PM

All replies

  • following up on this, i've enabled logging on the IPSec on the client and am receiving the following:

    Audit Failure: An IPsec main mode negotiation failed

    Local Endpoint:

           Local principal name: -

           Network address: xxxx

           Keying Module Port: 500

    Remote Endpoint:

           Principal name: -

           Network Address: xxxx

           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: 5002e4c37c14e7e8

           Responder cookie: 000000000000000

    Friday, March 23, 2012 2:38 AM
  • There are multiple tunnels at work in a DirectAccess connection. You have your transition tunnel (6to4, Teredo, or IP-HTTPS), and inside that tunnel you need to have your IPsec tunnels which actually carry the DA traffic. Pings move inside the transition tunnel, but outside of the IPsec tunnels. So it sounds like you are having problems authenticating your IPsec tunnels (and it sounds like you have already realized this). Problems with these tunnels most of the time are related to the Machine certificate that you have issued to your DA server and the DA clients. Did you issue a certificate to all machines from your internal CA server based off of the default "Computer" template? I always recommend using that one.
    Friday, March 23, 2012 6:30 PM
  • Thanks for the response. Yes, all computers have certificates based off the default computer template configured as an autoenrolment in GPO, and I have verified the certificate exists on all computers in question. I have also tried to add an IPSec certificate as well but to no avail. The thing that gets me is the failure reason: No policy configured. Does this mean DA Client is missing a configuration, or that no policy is configured because authentication has failed?

    Saturday, March 24, 2012 12:41 PM
  • Can you confirm that your UAG/DA server also has a valid certificate based off of the Computer template in its Computer/Personal store? The server must have one too, and if you request the certificate after you installed UAG then TMG will by default block the RPC communications between the UAG server and your CA server, and you will be unable to get a certificate until you create the necessary rule in TMG to allow that traffic.
    Monday, March 26, 2012 1:08 PM
  • The DA server does have a valid certificate installed, as do both the DC/DNS Server and the client, and they all match up to the computer name, based off the Computer template
    Monday, March 26, 2012 9:55 PM
  • If you open up "wf.msc", can you confirm that on both the client machine you are using and on your UAG server that you have DirectAccess rules established inside the "Connection Security Rules" section and also under the "Monitoring > Connection Security Rules" section?
    Tuesday, March 27, 2012 1:40 PM
  • Yes, there are the 3 DA tunnels there, and from my understanding they look correct. They are also listed under the monitoring section, with a status of OK. There are no entries under Security Associations.
    Tuesday, March 27, 2012 10:11 PM
  • My application servers have a directaccess GPO object associated to them, as does the DA server, and obviously the clients as well. Should the DC / DNS servers have one configured also? :/
    Tuesday, March 27, 2012 10:14 PM
  • Couple of things to check:

    • Verify NLS is working by opening a command prompt and enter netsh dns show state  and verify that the client identifies that it is outside the corporate network and that DirectAccess is "enabled"
    • Check to make sure the Local Security Policy does not have any non-standard configurations related to who is allowed to log on to the local computer. These should be the defaults.
    • Check the user account you are testing with to make sure the account is not locked out. (I know this is basic but this can be a reason for Main Mode tunnel not being established.
    • Run netsh Namespace Show EffectivePolicy make sure the DNS64 policy reflects that which was set in the DA configuration on the UAG Server.
    • Run netsh advfirewall monitor show mmsa post output here
    • Run netsh advfirewall monitor show qmsa post output here
    • Just one more crazy idea, check the UAG Server and make sure the DNS64 service is running. Also, you might open Web Monitor and look at the status of DirectAccess on the UAG Server.

    About all I can think of hope one of these will help you.


    Steve Angell - IAM Practice Director http://www.InfraScience.com)


    Wednesday, March 28, 2012 3:32 AM
  • Hi sangellga

    Thanks for the ideas

    • NLS is working, DirectAccess is enabled, and does negotiate an IP Address over IP-HTTPS
    • Local Security Policy - This is an interesting one, as we have delegated accesses to the Administrators group of our client PCs. The only changes are some domain accounts are added. However the "Logon to this computer locally" policies etc. are not changed, only the restricted groups setting.
    • Accounts cannot be locked out in our system, and I have checked anyway, and account is definitely not locked out
    • I'm not using UAG for the DirectAccess server, just the built-in one to Win2008. However, The DNS settings for NRPT are on the client PC correctly, and i can ping the DirectAccess (DNS Servers) addresses successfully
    • netsh advfirewall monitor show mmsa and qmsa show " No SAs match the specified criteria."
    • I'm not using UAG for DA, so i'm guessing this doesn't apply?
    Wednesday, March 28, 2012 3:43 AM
  • Hi sangellga

    Thanks for the ideas

    • NLS is working, DirectAccess is enabled, and does negotiate an IP Address over IP-HTTPS
    • Local Security Policy - This is an interesting one, as we have delegated accesses to the Administrators group of our client PCs. The only changes are some domain accounts are added. However the "Logon to this computer locally" policies etc. are not changed, only the restricted groups setting.
    • Accounts cannot be locked out in our system, and I have checked anyway, and account is definitely not locked out
    • I'm not using UAG for the DirectAccess server, just the built-in one to Win2008. However, The DNS settings for NRPT are on the client PC correctly, and i can ping the DirectAccess (DNS Servers) addresses successfully
    • netsh advfirewall monitor show mmsa and qmsa show " No SAs match the specified criteria."
    • I'm not using UAG for DA, so i'm guessing this doesn't apply?

    Are all internal resources IPv6, IPv4 or a mixture?
    So you can ping the DirectAccess Server, what happens if you try to ping an internal resource through the DirectAccess server?

    I have only set up DirectAccess without UAG once, and that was a long time ago, but it sounds like the same issue that is seen with UAG if the 6to4 service stops. Might want to look into any 6to4 service on a 2k8 R2 running DirectAccess. The fact that you are not establishing any SAs means DA is not being established but the other tests do re-enforce your statement that the client is receiving the configuration correctly.

    Also, dug up this article I had saved in my notes. Might help you out.

    http://technet.microsoft.com/en-us/library/ee844172(v=ws.10).aspx

    Regards,


    Steve Angell - IAM Practice Director http://www.InfraScience.com)

    Wednesday, March 28, 2012 12:07 PM
  • Yes, running native DirectAccess and not UAG changes the scope of troubleshooting. With native DirectAccess your internal network must be IPv6 (at least the part of the network you want to be able to communicate with over DA), you must be running Active Directory 2008 and your DNS servers must also be 2008. Are all of those things true in your environment?
    Wednesday, March 28, 2012 1:02 PM
  • No, there's no native IPv6, but ISATAP should be sufficient should it not? or is this not correct? The servers that are required to be accessed all have ISATAP addresses, and can be pinged
    Tuesday, April 3, 2012 3:52 AM
  • Just a crazy thought: Is the computer you're logging on to a member of the DirectAccess clients security group?

    This problem sounds exactly like the one I had when I forgot to add the computer account to that group:
    - I got an IPv6 IP on a teredo tunnel adapter.
    - I was able to ping machines inside the corporate network.
    - Nothing else worked.

    Seeing it reports a policy is missing (this could be caused by the computer account not being member of said group):

    - Did your computer get the NRPT settings?
    test this with: netsh namespace show policy
    if there's just one line of text, the policy is missing, you should get at least 2 blocks of text.

    - Does your computer correctly detect it's outside the network?
    test this with: netsh dnsclient show state
    check the "Machine Location" here, should be "Outside Corporate Network"
    and  check "DirectAccess Settings", should be "Configured and enabled" or "Configured and disabled" depending on your location. If it just says "Not Configured" the policy is missing.

    Friday, April 27, 2012 2:09 PM