locked
Windows 7 Clients Fail to Establish User Tunnel to DirectAccess 2012 R2 Server RRS feed

  • Question

  • I have a load-balanced pair of DA 2012 R2 servers... the Operations Status of both servers is all good.

    Configured as an edge topology with 2 NICs and 2 consecutive public-facing IPs for Teredo on the external NIC.

    'Enable Windows 7 client computers to connect via DirectAccess' IS ticked and force tunneling is NOT enabled. 

    A Windows 7 client establishes an infrastructure tunnel with the DA 2012 R2 server(s) and I can see it listed under Remote Client Status (sometimes connected as IPHTTPS and other times Teredo) but no user tunnel is ever established.

    When running the DA Client Troubleshooting tool...

    Interface Tests (pass), Network Location Tests (pass), IP Connectivity Tests (warning - no response received from xxx.yyy.gov.uk), Windows Firewall Tests (pass), Certificate Tests (pass), Infrastructure Tunnel Tests (fail - failed to connect to domain sysvol share \\xxx.yyy.gov.uk\sysvol\xxx.yyy.gov.uk\Policies), User Tunnel Tests (fail - failed to connect to HTTP probe at http://directaccess-WebProbeHost.xxx.yyy.gov.uk)

    When the infrastructure tunnel is established, if I ping an internal (IPv4) resource, the host name is resolved to an IPv6 address (so it appears that DNS64 is working OK) but the pings always time out.

    'netsh adv mon show mmsa' shows 2 security associations. Both Auth1: ComputerCert, Auth2: UserNTLM

    I am assuming these are for the infrastructure tunnel and I should also be seeing an SA for Auth1: ComputerCert, Auth2: UserKerb for the Kerberos authenticated user tunnel. However nothing I can see gives any clues as to why this has failed to establish. 

    Anyone know what is going on here and why the user tunnel would fail to establish? I am not seeng anything particularly useful in the Troubleshooting Tool trace log, or from the Advanced Diagnostics created by the DA Connectivity Assistant.

    Or just any suggestions what I could try next.

    Is it likely to be a certificate issue? Seems unlikely to me when the infrastructure tunnels are establishing ok.






    • Edited by snail17 Thursday, December 31, 2015 2:27 PM
    Thursday, December 31, 2015 11:51 AM

All replies

  • Hi,

    'netsh adv mon show mmsa' is the command to check Main Mode Security Association used by the Infrastructure Tunnel.
    'netsh adv mon show qmsa' is the command to check Quick Mode Security Association used by the User Tunnel.

    You can enable the IPsec audit mode on both client and server by deploying an additional GPO then check in Event Viewer why the User Tunnel is failing.


    Gerald

    Monday, January 4, 2016 10:27 AM
  • OK... having enabled auditing for IPsec events, I am seeing the following on the client PC:-

    2 success events for IPsec Extended Mode and IPsec Quick Mode.

    1 failure event for IPsec Main Mode:-

    Log Name:       Security
    Source:         Microsoft-Windows-Security-Auditing
    Date:           05/01/2016 08:28:00
    Event ID:       4981
    Task Category: IPsec Extended Mode
    Level:         Information
    Keywords:       Audit Success
    User:           N/A
    Computer:       WLTR9HL240.xxx.yyy.gov.uk
    Description: IPsec main mode and extended mode security associations were established.


    Log Name:       Security
    Source:         Microsoft-Windows-Security-Auditing
    Date:           05/01/2016 08:28:00
    Event ID:       5451
    Task Category: IPsec Quick Mode
    Level:         Information
    Keywords:       Audit Success
    User:           N/A
    Computer:       WLTR9HL240.xxx.yyy.gov.uk
    Description: An IPsec quick mode security association was established.


    Log Name:       Security
    Source:         Microsoft-Windows-Security-Auditing
    Date:           05/01/2016 08:28:27
    Event ID:       4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:       Audit Failure
    User:           N/A
    Computer:       WLTR9HL240.xxx.yyy.gov.uk
    Description: An IPsec main mode negotiation failed.

    Local Endpoint:
    Local Principal Name: -
    Network Address: 2001:0:c2a5:de7:22:3227:a97b:da98
    Keying Module Port: 500

    Remote Endpoint:
    Principal Name: -
    Network Address: 2002:c2a5:de8::c2a5:de8
    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: ecabc4e4cf134a51
    Responder Cookie: 0000000000000000

    After this I am seeing 1 SA when I run netsh adv mon show mmsa and 1 SA when I run netsh adv mon show qmsa

    A ping of an internal IPv4 resource resolves to an IPv6 address, but does not reply.

    No internal resources are accessible (file shares, intranet pages etc.)

    The DirectAccess Client Troubleshooting Tool returns the following:-

    Interface Tests (pass), Network Location Tests (pass), IP Connectivity Tests (warning - no response received from xxx.yyy.gov.uk), Windows Firewall Tests (pass), Certificate Tests (pass), Infrastructure Tunnel Tests (fail - failed to connect to domain sysvol share \\xxx.yyy.gov.uk\sysvol\xxx.yyy.gov.uk\Policies), User Tunnel Tests (fail - failed to connect to HTTP probe at http://directaccess-WebProbeHost.xxx.yyy.gov.uk)

    In the server Security event logs I am seeing corresponding success events for the IPsec Quick Mode and IPsec Extended Mode connections. There are no failure events at all.  

    Any ideas...??

    • Edited by snail17 Tuesday, January 5, 2016 9:30 AM
    Tuesday, January 5, 2016 9:19 AM
  • If you have both Main and Quick mode associations, your tunnels are up.
    You can also check this in your client's firewall:

    I have less experience using Teredo but if I remember well, Teredo requires ICMP to be outside the tunnels to work properly.
    That may explains why you can't ping your internal servers.

    Check this TechNet article: http://blogs.technet.com/b/tomshinder/archive/2010/07/14/considerations-when-using-ping-to-troubleshoot-directaccess-connectivity-issues.aspx

    Tuesday, January 5, 2016 9:50 AM
  • Are you using the DCA 2.0on your Windows 7 client? I think that logs from this tool are more usefull than the troubleshooter
    Tuesday, January 5, 2016 9:58 AM
  • Yes I am running DCA 2.0 so will re-run the logs and see if there is anything useful.

    I have 1 x MMSA and 1 x QMSA (not sure if I should have more). 

    (apologies for non-hyperlinked URLs but for some reason I can't add in-line images or hyperlinks):-

    https://drive.google.com/file/d/0B8UBjrMNLIqLRlctVnY0OWpKUTA/view?usp=sharing
    https://drive.google.com/file/d/0B8UBjrMNLIqLdjZBSGlUb2dhQ2M/view?usp=sharing

    The QMSA seems to drop every few minutes and then re-establishes itself. Not sure if this is normal behaviour.

    I was assuming that I should have multiple MMSAs for infrastructure and intranet tunnels (pretty sure this was the case for 2008 R2 UAG DA)


    • Edited by snail17 Tuesday, January 5, 2016 11:16 AM
    Tuesday, January 5, 2016 11:15 AM
  • Mine doesn't do that...

    It seems that the connection between the outside client and the DirectAccess Cluster is working but your client is not able to use the DirectAccess Cluster to contact your internal servers

    From the connected client, can you ping the IPv6 addresses of the DirectAccess servers?
    Do you have a firewall between the server's Domain NIC and your internal network?

    Are you sure the routing between the DirectAccess Cluster and your internal servers is correct?

    Tuesday, January 5, 2016 12:37 PM
  • I can ping the IPV6 addresses of the external NIC from an externally connected client.

    I can successfully ping the 2 IPv6 VIP addresses assigned to the NIC (2 consecutive addresses for Teredo purposes) as well as the IPv6 address of the DIP assigned to the card.

    Yes there is a firewall between the DA servers and the internal network.

    However the same rules have been applied to these servers as has been used for 2008 R2 UAG DA (which is 'live' and in use).

    Am not sure about the routing... no default gateway is configured on the internal NIC but I have added IPv4 static routes for the IP ranges of my internal subnets (networking is not my specialism but I think this is right). 

    All pings to internal IPv4 addresses are transitioned to IPv6 but do not respond.


    • Edited by snail17 Monday, January 11, 2016 3:10 PM
    Monday, January 11, 2016 3:05 PM
  • Hi,

    As I said before, I have less experience with Teredo but in my environment, the IPv6 addresses are assigned to the Internal NIC.

    Are you sure they are on the External NIC ?

    Gerald

    Monday, January 11, 2016 3:55 PM
  • Sorry I misunderstood. I was referring to the external 6to4 addresses.

    I can also successfully ping the IPv6 address assigned to the internal NIC.

    This is also the address used as the DNS server for the NRPT entries that use the DA tunnel.

    This all seems OK as the IPv6/IPv4 transitioning/name resolution works when pinging an IPv4 internal address from the external IPv6 client PC. (if I ping an internal IPv4 only resource from the external IPv6 client PC, it resolves to an IPv6 address, but does not respond)

    Monday, January 11, 2016 4:58 PM
  • If you can resolve the names, it means that the DNS64 is working correctly.

    Anyway, it seems that the NAT64 is not because you can't access your internal servers. That's why I'm thinking about routing problems.

    Can you share a DCA 2.0 log so I see if something may be wrong from the client?

    Tuesday, January 12, 2016 9:04 AM
  • Hi Gérald,

    DCA 2.0 log is here:-

    https://drive.google.com/file/d/0B8UBjrMNLIqLRlRBRUZUOVNQU28/view?usp=sharing

    Thanks for taking the time to have a look.

    Wednesday, January 13, 2016 9:01 AM
  • Hi,

    Remember that for DCA 2.0, you need to deploy and configure the DCA GPO also.
    If not, it will always report that the connectivity is not working.

    I see that you're connected with Teredo and IP-HTTPS at the same time and that, in the Firewall, one tunnel seems to connect using the Teredo address and one with the IP-HTTPS address.

    Can you try to work only with IP-HTTPS and see if it works?

    netsh int teredo set state disable

    Gerald

    Wednesday, January 13, 2016 12:06 PM
  • Hi,

    No joy. Same deal with Teredo disabled.

    Am I missing something really obvious here...? Seems like it must be a routing or firewall issue.

    Here is the log from the DA Client Troubleshooter Tool. Not sure if this helps any more than the DCA 2.0 log:-

    https://drive.google.com/file/d/0B8UBjrMNLIqLM3lIRlc2OWxJdGs/view?usp=sharing

    Thanks again.

    Friday, January 15, 2016 8:47 AM
  • The problem with the Troubleshooter log is that it's mostly unreadable if you're not in front of the GUI.
    At least, the DCA Log creates an HTML file that is readable.
    Friday, January 15, 2016 1:39 PM
  • It seems that you're not using the same DNS server in all of your NRPT ...

    2002:c2a5:de7:3333::1 is normally your DirectAccess DNS Server for NRPT.

    What's 2002:c2a5:dee::c2a5:dee ?

    Friday, January 15, 2016 1:47 PM
  • Sorry... please ignore that DNS server.

    That is the DNS server from my 2008 UAG DA setup (which works just fine).

    Seems that there was a residual entry in the registry for this that was not removed (I have now refreshed everything and removed any reference).

    I am curious as to why on the DA Client Troubleshooting Tool, I am seeing

    Interface Test - Success

    Network Location Tests - Success

    IP Connectivity Tests - Teredo is used as IPv6 transition technology, No response received from xxx.yyy.gov.uk

    Infrastructure Tunnel Tests - Failed to connect to domain sysvol share \\xxx.yyy.gov.uk\sysvol\xxx.yyy.gov.uk\Policies

    This is separate to the user tunnel tests. And my infrastructure tunnel seems to connect OK. So why is it still failing to connect to and get responses from my internal resources?

    Presumably as these are part of the infrastructure tests, these should work regardless of whether a user tunnel is connected.

    Tuesday, January 19, 2016 9:55 AM
  • Hi,

    The Main tunnel is established but your client can't use it to access the DC, that's why the troubleshooter reports the failure.

    Just to be sure, have you implemented the recommended hotfixes for Windows 7 using a DirectAccess 2012 infrastructure?

    https://support.microsoft.com/en-us/kb/978738

    Maybe if some hotfixes seems not relevant for the problem, I recommend to install them.

    Gerald

    Tuesday, January 19, 2016 10:28 AM