Direct Access Windows 8 Client IPHTTPS active but no connectivity
This is a bit strange - I've set up a simple Server 2012R2 Direct Access server with single NIC behind a NAT, self signed cert though.
When I try and connect I just get "Connecting" forever - but when I check the IP-HTTPS interface is active and has an address but it's strange, it doesn't look like a public IPv6 address it starts with fd9f:3106 - alongside this there is also a
Teredo Tunnel active with a normal looking IPv6 address which I can't quite understand as it should be IP-HTTPS only with a single interface DA server behind NAT.
On running the Direct Access troubleshooter it says I'm connected to the Microsoft public teredo server... WHY??
It also says it successfully connected to the endpoint and the DNS tests worked
Then we come to the certs it says No Usable Machine Cert found - I've looked and the self signed certs have been put into Trusted Root Authority store by the policy - but no go - all the Infrastructure Tunnel test fails with Failed to connect to sysvol and
User Tunnel fails to connect to HTTP probe.
I'm guessing at least part of the problem is the self signed cert but some more experienced advice would be very much appreciated.
Thanks
Scott
January 29th, 2015 9:00am
From the Planning Guide on Technet:
- If the DirectAccess client has been assigned a public IPv4 address, it will use the 6to4 transition technology to connect to the intranet. If it is assigned a private IPv4 address, it will use Teredo.
- If the DirectAccess client cannot connect to the DirectAccess server with 6to4 or Teredo, it will use IP-HTTPS.
- To use Teredo, you must configure two consecutive IP addresses on the external facing network adapter.
- You cannot use Teredo if the DirectAccess server has only one network adapter.
This explains why you use IP-HTTPS
The IPv6 generated address seems fine for a "Behind a NAT" configuration because the DirectAccess Server create the range iself. Got the explanation once but I can't find it right now :D
Edit: Found the article (http://blog.msedge.org.uk/2013/03/windows-server-2012-directaccess-manage.html )
The Self-Signed certificate is only used to validate the IP-HTTPS Tunnel. Not the Infrastructure and Intranet IPsec tunnels.
You must use a PKI infrastructure to validate your client but this is only required if you want to use Windows 7 as a DirectAccess client.
Gerald
-
Proposed as answer by
Gerald Mathieu
Friday, January 30, 2015 11:27 PM
-
Edited by
Gerald Mathieu
Friday, January 30, 2015 11:28 PM
January 31st, 2015 1:28am
From the Planning Guide on Technet:
- If the DirectAccess client has been assigned a public IPv4 address, it will use the 6to4 transition technology to connect to the intranet. If it is assigned a private IPv4 address, it will use Teredo.
- If the DirectAccess client cannot connect to the DirectAccess server with 6to4 or Teredo, it will use IP-HTTPS.
- To use Teredo, you must configure two consecutive IP addresses on the external facing network adapter.
- You cannot use Teredo if the DirectAccess server has only one network adapter.
This explains why you use IP-HTTPS
The IPv6 generated address seems fine for a "Behind a NAT" configuration because the DirectAccess Server create the range iself. Got the explanation once but I can't find it right now :D
Edit: Found the article (http://blog.msedge.org.uk/2013/03/windows-server-2012-directaccess-manage.html )
The Self-Signed certificate is only used to validate the IP-HTTPS Tunnel. Not the Infrastructure and Intranet IPsec tunnels.
You must use a PKI infrastructure to validate your client but this is only required if you want to use Windows 7 as a DirectAccess client.
Gerald
-
Proposed as answer by
Gerald Mathieu
Friday, January 30, 2015 11:27 PM
-
Edited by
Gerald Mathieu
Friday, January 30, 2015 11:28 PM
-
Unproposed as answer by
Microsoft Designertech
16 hours 12 minutes ago
January 31st, 2015 1:28am
From the Planning Guide on Technet:
- If the DirectAccess client has been assigned a public IPv4 address, it will use the 6to4 transition technology to connect to the intranet. If it is assigned a private IPv4 address, it will use Teredo.
- If the DirectAccess client cannot connect to the DirectAccess server with 6to4 or Teredo, it will use IP-HTTPS.
- To use Teredo, you must configure two consecutive IP addresses on the external facing network adapter.
- You cannot use Teredo if the DirectAccess server has only one network adapter.
This explains why you use IP-HTTPS
The IPv6 generated address seems fine for a "Behind a NAT" configuration because the DirectAccess Server create the range iself. Got the explanation once but I can't find it right now :D
Edit: Found the article (http://blog.msedge.org.uk/2013/03/windows-server-2012-directaccess-manage.html )
The Self-Signed certificate is only used to validate the IP-HTTPS Tunnel. Not the Infrastructure and Intranet IPsec tunnels.
You must use a PKI infrastructure to validate your client but this is only required if you want to use Windows 7 as a DirectAccess client.
Gerald
-
Proposed as answer by
Gerald Mathieu
Friday, January 30, 2015 11:27 PM
-
Edited by
Gerald Mathieu
Friday, January 30, 2015 11:28 PM
-
Unproposed as answer by
Microsoft Designertech
Sunday, February 01, 2015 7:34 PM
January 31st, 2015 1:28am
From the Planning Guide on Technet:
- If the DirectAccess client has been assigned a public IPv4 address, it will use the 6to4 transition technology to connect to the intranet. If it is assigned a private IPv4 address, it will use Teredo.
- If the DirectAccess client cannot connect to the DirectAccess server with 6to4 or Teredo, it will use IP-HTTPS.
- To use Teredo, you must configure two consecutive IP addresses on the external facing network adapter.
- You cannot use Teredo if the DirectAccess server has only one network adapter.
This explains why you use IP-HTTPS
The IPv6 generated address seems fine for a "Behind a NAT" configuration because the DirectAccess Server create the range iself. Got the explanation once but I can't find it right now :D
Edit: Found the article (http://blog.msedge.org.uk/2013/03/windows-server-2012-directaccess-manage.html )
The Self-Signed certificate is only used to validate the IP-HTTPS Tunnel. Not the Infrastructure and Intranet IPsec tunnels.
You must use a PKI infrastructure to validate your client but this is only required if you want to use Windows 7 as a DirectAccess client.
Gerald
-
Proposed as answer by
Gerald Mathieu
Friday, January 30, 2015 11:27 PM
-
Edited by
Gerald Mathieu
Friday, January 30, 2015 11:28 PM
-
Unproposed as answer by
Microsoft Designertech
Sunday, February 01, 2015 7:34 PM
January 31st, 2015 1:28am
From the Planning Guide on Technet:
- If the DirectAccess client has been assigned a public IPv4 address, it will use the 6to4 transition technology to connect to the intranet. If it is assigned a private IPv4 address, it will use Teredo.
- If the DirectAccess client cannot connect to the DirectAccess server with 6to4 or Teredo, it will use IP-HTTPS.
- To use Teredo, you must configure two consecutive IP addresses on the external facing network adapter.
- You cannot use Teredo if the DirectAccess server has only one network adapter.
This explains why you use IP-HTTPS
The IPv6 generated address seems fine for a "Behind a NAT" configuration because the DirectAccess Server create the range iself. Got the explanation once but I can't find it right now :D
Edit: Found the article (http://blog.msedge.org.uk/2013/03/windows-server-2012-directaccess-manage.html )
The Self-Signed certificate is only used to validate the IP-HTTPS Tunnel. Not the Infrastructure and Intranet IPsec tunnels.
You must use a PKI infrastructure to validate your client but this is only required if you want to use Windows 7 as a DirectAccess client.
Gerald
-
Proposed as answer by
Gerald Mathieu
Friday, January 30, 2015 11:27 PM
-
Edited by
Gerald Mathieu
Friday, January 30, 2015 11:28 PM
-
Unproposed as answer by
Microsoft Designertech
Sunday, February 01, 2015 7:34 PM
January 31st, 2015 1:28am
Hi Gerald,
Thanks I appreciate that but you have not in fact answered all my questions, you've explained the IP-HTTPS address so that now makes sense, but not why I seem to have a Teredo tunnel to a public Microsoft Server - I don't want to use Teredo at all. If the
cert is only used to validate the IP-HTTPS tunnel why do i get a "No valid machine cert found" error message, and no Infrastructure or User tunnel access?
Only running Windows 8 by the way - no Windows 7 and was wanting to use the Kerberos Proxy option which I enabled
February 1st, 2015 2:48pm
Hi,
Teredo is available on DirectAccess server-side if you have two public IPv4 addresses. In your case, with a single NIC, Teredo is not available on DirectAccess-server side.
But on client-side, default behavior is try to negociate an interface for teredo. Just disable Teredo interface with a netsh interface teredo set state disable. You can do the same for 6to4 because in your scenario, only IPHTTPS
will be available at DirectAccess-server side.
Best regards.
February 1st, 2015 4:52pm
Hello,
Previous post from Benoit is correct, if you don't want to use Teredo and 6to4 interfaces, just disable them using netsh.
They're not required for your DirectAccess infrastructure.
If you're only using Windows 8.x clients, certificates are not mandatory for the Infrastructure Tunnel.
Can you check in the DirectAccess console setup --> Step 2 (Remote Access Server) --> Authentication if you checked the 'Use Computer Certificate" ?
If you checked this part, you need to have a PKI infrastructure deploying Computer Certificate on both the DirectAccess server and your clients.
Just disable the "Use Computer Certificate" and your clients should authenticate using Kerberos only.
Gerald
-
Edited by
Gerald Mathieu
1 hour 2 minutes ago
February 2nd, 2015 5:46am
Hello,
Previous post from Benoit is correct, your Teredo is active because your client is able to contact a Teredo server.
If you don't want to use Teredo and 6to4 interfaces, just disable them using netsh.
They're not required for your DirectAccess infrastructure.
If you're only using Windows 8.x clients, certificates are not mandatory for the Infrastructure Tunnel.
Can you check in the DirectAccess console setup --> Step 2 (Remote Access Server) --> Authentication if you checked the 'Use computer certificates" ?
If you checked this part, you need to have a PKI infrastructure deploying Computer Certificate on both the DirectAccess server and your clients. Also, this checkbox is active and greyed if you checked "Enable Windows 7 clients" at the bottom.
Just disable the "Use computer certificates" and your clients should authenticate using Kerberos only.
Gerald
-
Edited by
Gerald Mathieu
22 hours 25 minutes ago
-
Proposed as answer by
Gerald Mathieu
22 hours 22 minutes ago
-
Unproposed as answer by
Microsoft Designertech
15 hours 51 minutes ago
February 2nd, 2015 1:44pm
Hello,
Previous post from Benoit is correct, your Teredo is active because your client is able to contact a Teredo server.
If you don't want to use Teredo and 6to4 interfaces, just disable them using netsh.
They're not required for your DirectAccess infrastructure.
If you're only using Windows 8.x clients, certificates are not mandatory for the Infrastructure Tunnel.
Can you check in the DirectAccess console setup --> Step 2 (Remote Access Server) --> Authentication if you checked the 'Use computer certificates" ?
If you checked this part, you need to have a PKI infrastructure deploying Computer Certificate on both the DirectAccess server and your clients. Also, this checkbox is active and greyed if you checked "Enable Windows 7 clients" at the bottom.
Just disable the "Use computer certificates" and your clients should authenticate using Kerberos only.
Gerald
-
Edited by
Gerald Mathieu
Monday, February 02, 2015 1:22 PM
-
Proposed as answer by
Gerald Mathieu
Monday, February 02, 2015 1:25 PM
-
Unproposed as answer by
Microsoft Designertech
Monday, February 02, 2015 7:56 PM
February 2nd, 2015 1:44pm
Hello,
Previous post from Benoit is correct, your Teredo is active because your client is able to contact a Teredo server.
If you don't want to use Teredo and 6to4 interfaces, just disable them using netsh.
They're not required for your DirectAccess infrastructure.
If you're only using Windows 8.x clients, certificates are not mandatory for the Infrastructure Tunnel.
Can you check in the DirectAccess console setup --> Step 2 (Remote Access Server) --> Authentication if you checked the 'Use computer certificates" ?
If you checked this part, you need to have a PKI infrastructure deploying Computer Certificate on both the DirectAccess server and your clients. Also, this checkbox is active and greyed if you checked "Enable Windows 7 clients" at the bottom.
Just disable the "Use computer certificates" and your clients should authenticate using Kerberos only.
Gerald
-
Edited by
Gerald Mathieu
Monday, February 02, 2015 1:22 PM
-
Proposed as answer by
Gerald Mathieu
Monday, February 02, 2015 1:25 PM
-
Unproposed as answer by
Microsoft Designertech
Monday, February 02, 2015 7:56 PM
February 2nd, 2015 1:44pm
Hello,
Previous post from Benoit is correct, your Teredo is active because your client is able to contact a Teredo server.
If you don't want to use Teredo and 6to4 interfaces, just disable them using netsh.
They're not required for your DirectAccess infrastructure.
If you're only using Windows 8.x clients, certificates are not mandatory for the Infrastructure Tunnel.
Can you check in the DirectAccess console setup --> Step 2 (Remote Access Server) --> Authentication if you checked the 'Use computer certificates" ?
If you checked this part, you need to have a PKI infrastructure deploying Computer Certificate on both the DirectAccess server and your clients. Also, this checkbox is active and greyed if you checked "Enable Windows 7 clients" at the bottom.
Just disable the "Use computer certificates" and your clients should authenticate using Kerberos only.
Gerald
-
Edited by
Gerald Mathieu
Monday, February 02, 2015 1:22 PM
-
Proposed as answer by
Gerald Mathieu
Monday, February 02, 2015 1:25 PM
-
Unproposed as answer by
Microsoft Designertech
Monday, February 02, 2015 7:56 PM
February 2nd, 2015 1:44pm
Gerald
Thank you both and yes I understand it is correct as far as it goes but has not resolved my problem - it has explained something I did not quite comprehend as I expected only an IPHTTPS connection and for that I'm grateful.
You're suggestion has not resolved the problem either I'm afraid as I have not got "Use computer certificates" checked - I know an internal PKI infrastructure was needed for this and we don't have one. I only have "Active Directory credentials"
selected under Authentication.
Under Step 4 I have "Do not extend authentication to application servers" as my understanding was that I needed to authenticate to the DA server and it would use Kerberos proxy to authenticate to the other servers as needed so extending it was
not needed unless there were security requirements for that - is that correct?
February 2nd, 2015 2:58pm
Hi,
By defaut, DirectAccess IPsec tunnels are only created between the clients and the DirectAccess server.
Step 4 is only used if you want additional security between your client and specific servers by creating an IPsec tunnel between them and the client.
I've never used it because my client already use a lot of extra devices for limiting network access.
If you're using only Windows 8 clients and didn't checked the "Use computer certificates", you shouldn't have that problem.
Where did you find the message "No valid machine cert found" ?
Have you enabled the IPsec audit mode on your client for extra debugging?
Gerald
February 2nd, 2015 3:49pm
Hi Gerald,
Good OK thanks that confirms my understanding of Step 4.
The no machine cert found error came from the Direct Access Troubleshooting tool found here:
http://www.microsoft.com/en-us/download/details.aspx?id=41938
After the no machine cert error was an Infrastructure tunnel error about cannot connect to sysvol share and a user tunnel error about not finding the HTTP probe - I assumed the tunnel errors were because of the certificate error and the self-signed certificate
- the deployment instructions mention that you need to publish a CRL to the internet even with a self signed cert but I have not done that as I've never needed to before with a self signed cert and can't find much info about it.
In all so far I've found this "simplified" deployment more difficult than the Windows Server 2008R2 one I did 5 years ago!
February 2nd, 2015 7:55pm
What is the output of netsh Interface iphttps show Interface ?
Are you using both Win7 and Win8 Clients? Did you install some hotfixes? This link is recommended Reading:
http://support.microsoft.com/kb/2883952
February 3rd, 2015 3:12am
Hi,
If you don't use PKI, there's no need to publish a CRL because you don't have one.
Just tested the DirectAccess Troubleshooter on my lab reconfigured for Windows 8.x only without certificates.
It also reports an error on the certificate because I don't have one but my connection is working.
[03-02-15 12:06:40]: The public DNS Server (8.8.8.8) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: Running Inside/Outside location tests.
[03-02-15 12:06:41]: NLS is https://nls.corp.contoso.com/.
[03-02-15 12:06:41]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[03-02-15 12:06:41]: NRPT contains 2 rules.
[03-02-15 12:06:41]: Found (unique) DNS server: 2001:db8:2::1
[03-02-15 12:06:41]: Send an ICMP message to check if the server is reachable.
[03-02-15 12:06:41]: DNS server 2001:db8:2::1 is online, RTT is 385 msec.
[03-02-15 12:06:41]: Running IP connectivity tests.
[03-02-15 12:06:41]: The 6to4 interface service state is default.
[03-02-15 12:06:41]: Teredo inferface status is offline.
[03-02-15 12:06:41]: The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
[03-02-15 12:06:42]: The IPHTTPS interface is operational.
[03-02-15 12:06:42]: The IPHTTPS interface status is IPHTTPS interface active.
[03-02-15 12:06:42]: IPHTTPS is used as IPv6 transition technology.
[03-02-15 12:06:42]: The configured IPHTTPS URL is
https://direct.contoso.com:443.
[03-02-15 12:06:42]: IPHTTPS has a single site configuration.
[03-02-15 12:06:42]: IPHTTPS URL endpoint is:
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Successfully connected to endpoint
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Received response from corp.contoso.com, RTT is 53 msec.
[03-02-15 12:06:42]: Running Windows Firewall tests.
[03-02-15 12:06:42]: The current profile of the Windows Firewall is Public.
[03-02-15 12:06:42]: The Windows Firewall is enabled in the current profile Public.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
[03-02-15 12:06:42]: Running certificate tests.
[03-02-15 12:06:42]: No usable machine certificate found.
[03-02-15 12:06:42]: Found 0 machine certificates on this client computer.
[03-02-15 12:06:42]: Running IPsec infrastructure tunnel tests.
[03-02-15 12:06:43]: Successfully connected to domain sysvol share, found 11 policies.
[03-02-15 12:06:43]: Running IPsec intranet tunnel tests.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::1, RTT is 333 msec.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::2, RTT is 26 msec.
[03-02-15 12:06:44]: Successfully reached HTTP probe at
http://directaccess-WebProbeHost.corp.contoso.com.
[03-02-15 12:06:44]: Running selected post-checks script.
[03-02-15 12:06:44]: No post-checks script specified or the file does not exist.
[03-02-15 12:06:44]: Finished running post-checks script.
[03-02-15 12:06:44]: Finished running all tests.
This tool is probably configured to test for certificates even if you don't need one in your configuration so this error is normal.
Your problem is your IPsec tunnels not working. I'll suggest you to enable IPsec audit mode on your client and check the error messages in the Security log in your event viewer. Last thing i just remembered, are you using an anti-virus on your client and/or
server? I've got problem with one killing all IPsec packets
Gerald
-
Edited by
Gerald Mathieu
a few seconds ago
February 3rd, 2015 6:32am
Hi,
If you don't use PKI, there's no need to publish a CRL because you don't have one.
Just tested the DirectAccess Troubleshooter on my lab reconfigured for Windows 8.x only without certificates.
It also reports an error on the certificate because I don't have one but my connection is working.
[03-02-15 12:06:40]: The public DNS Server (8.8.8.8) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: Running Inside/Outside location tests.
[03-02-15 12:06:41]: NLS is https://nls.corp.contoso.com/.
[03-02-15 12:06:41]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[03-02-15 12:06:41]: NRPT contains 2 rules.
[03-02-15 12:06:41]: Found (unique) DNS server: 2001:db8:2::1
[03-02-15 12:06:41]: Send an ICMP message to check if the server is reachable.
[03-02-15 12:06:41]: DNS server 2001:db8:2::1 is online, RTT is 385 msec.
[03-02-15 12:06:41]: Running IP connectivity tests.
[03-02-15 12:06:41]: The 6to4 interface service state is default.
[03-02-15 12:06:41]: Teredo inferface status is offline.
[03-02-15 12:06:41]: The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
[03-02-15 12:06:42]: The IPHTTPS interface is operational.
[03-02-15 12:06:42]: The IPHTTPS interface status is IPHTTPS interface active.
[03-02-15 12:06:42]: IPHTTPS is used as IPv6 transition technology.
[03-02-15 12:06:42]: The configured IPHTTPS URL is
https://direct.contoso.com:443.
[03-02-15 12:06:42]: IPHTTPS has a single site configuration.
[03-02-15 12:06:42]: IPHTTPS URL endpoint is:
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Successfully connected to endpoint
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Received response from corp.contoso.com, RTT is 53 msec.
[03-02-15 12:06:42]: Running Windows Firewall tests.
[03-02-15 12:06:42]: The current profile of the Windows Firewall is Public.
[03-02-15 12:06:42]: The Windows Firewall is enabled in the current profile Public.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
[03-02-15 12:06:42]: Running certificate tests.
[03-02-15 12:06:42]: No usable machine certificate found.
[03-02-15 12:06:42]: Found 0 machine certificates on this client computer.
[03-02-15 12:06:42]: Running IPsec infrastructure tunnel tests.
[03-02-15 12:06:43]: Successfully connected to domain sysvol share, found 11 policies.
[03-02-15 12:06:43]: Running IPsec intranet tunnel tests.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::1, RTT is 333 msec.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::2, RTT is 26 msec.
[03-02-15 12:06:44]: Successfully reached HTTP probe at
http://directaccess-WebProbeHost.corp.contoso.com.
[03-02-15 12:06:44]: Running selected post-checks script.
[03-02-15 12:06:44]: No post-checks script specified or the file does not exist.
[03-02-15 12:06:44]: Finished running post-checks script.
[03-02-15 12:06:44]: Finished running all tests.
This tool is probably configured to test for certificates even if you don't need one in your configuration so this error is normal.
Your problem is your IPsec tunnels not working. I'll suggest you to enable IPsec audit mode on your client and check the error messages in the Security log in your event viewer. Last thing i just remembered, are you using an anti-virus on your client and/or
server? I've got problem with one killing all IPsec packets
Gerald
-
Edited by
Gerald Mathieu
Tuesday, February 03, 2015 11:45 AM
February 3rd, 2015 2:30pm
Hi,
If you don't use PKI, there's no need to publish a CRL because you don't have one.
Just tested the DirectAccess Troubleshooter on my lab reconfigured for Windows 8.x only without certificates.
It also reports an error on the certificate because I don't have one but my connection is working.
[03-02-15 12:06:40]: The public DNS Server (8.8.8.8) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: Running Inside/Outside location tests.
[03-02-15 12:06:41]: NLS is https://nls.corp.contoso.com/.
[03-02-15 12:06:41]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[03-02-15 12:06:41]: NRPT contains 2 rules.
[03-02-15 12:06:41]: Found (unique) DNS server: 2001:db8:2::1
[03-02-15 12:06:41]: Send an ICMP message to check if the server is reachable.
[03-02-15 12:06:41]: DNS server 2001:db8:2::1 is online, RTT is 385 msec.
[03-02-15 12:06:41]: Running IP connectivity tests.
[03-02-15 12:06:41]: The 6to4 interface service state is default.
[03-02-15 12:06:41]: Teredo inferface status is offline.
[03-02-15 12:06:41]: The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
[03-02-15 12:06:42]: The IPHTTPS interface is operational.
[03-02-15 12:06:42]: The IPHTTPS interface status is IPHTTPS interface active.
[03-02-15 12:06:42]: IPHTTPS is used as IPv6 transition technology.
[03-02-15 12:06:42]: The configured IPHTTPS URL is
https://direct.contoso.com:443.
[03-02-15 12:06:42]: IPHTTPS has a single site configuration.
[03-02-15 12:06:42]: IPHTTPS URL endpoint is:
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Successfully connected to endpoint
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Received response from corp.contoso.com, RTT is 53 msec.
[03-02-15 12:06:42]: Running Windows Firewall tests.
[03-02-15 12:06:42]: The current profile of the Windows Firewall is Public.
[03-02-15 12:06:42]: The Windows Firewall is enabled in the current profile Public.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
[03-02-15 12:06:42]: Running certificate tests.
[03-02-15 12:06:42]: No usable machine certificate found.
[03-02-15 12:06:42]: Found 0 machine certificates on this client computer.
[03-02-15 12:06:42]: Running IPsec infrastructure tunnel tests.
[03-02-15 12:06:43]: Successfully connected to domain sysvol share, found 11 policies.
[03-02-15 12:06:43]: Running IPsec intranet tunnel tests.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::1, RTT is 333 msec.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::2, RTT is 26 msec.
[03-02-15 12:06:44]: Successfully reached HTTP probe at
http://directaccess-WebProbeHost.corp.contoso.com.
[03-02-15 12:06:44]: Running selected post-checks script.
[03-02-15 12:06:44]: No post-checks script specified or the file does not exist.
[03-02-15 12:06:44]: Finished running post-checks script.
[03-02-15 12:06:44]: Finished running all tests.
This tool is probably configured to test for certificates even if you don't need one in your configuration so this error is normal.
Your problem is your IPsec tunnels not working. I'll suggest you to enable IPsec audit mode on your client and check the error messages in the Security log in your event viewer. Last thing i just remembered, are you using an anti-virus on your client and/or
server? I've got problem with one killing all IPsec packets
Gerald
-
Edited by
Gerald Mathieu
Tuesday, February 03, 2015 11:45 AM
February 3rd, 2015 2:30pm
Hi,
If you don't use PKI, there's no need to publish a CRL because you don't have one.
Just tested the DirectAccess Troubleshooter on my lab reconfigured for Windows 8.x only without certificates.
It also reports an error on the certificate because I don't have one but my connection is working.
[03-02-15 12:06:40]: The public DNS Server (8.8.8.8) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[03-02-15 12:06:41]: Running Inside/Outside location tests.
[03-02-15 12:06:41]: NLS is https://nls.corp.contoso.com/.
[03-02-15 12:06:41]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[03-02-15 12:06:41]: NRPT contains 2 rules.
[03-02-15 12:06:41]: Found (unique) DNS server: 2001:db8:2::1
[03-02-15 12:06:41]: Send an ICMP message to check if the server is reachable.
[03-02-15 12:06:41]: DNS server 2001:db8:2::1 is online, RTT is 385 msec.
[03-02-15 12:06:41]: Running IP connectivity tests.
[03-02-15 12:06:41]: The 6to4 interface service state is default.
[03-02-15 12:06:41]: Teredo inferface status is offline.
[03-02-15 12:06:41]: The configured DirectAccess Teredo server is win8.ipv6.microsoft.com..
[03-02-15 12:06:42]: The IPHTTPS interface is operational.
[03-02-15 12:06:42]: The IPHTTPS interface status is IPHTTPS interface active.
[03-02-15 12:06:42]: IPHTTPS is used as IPv6 transition technology.
[03-02-15 12:06:42]: The configured IPHTTPS URL is
https://direct.contoso.com:443.
[03-02-15 12:06:42]: IPHTTPS has a single site configuration.
[03-02-15 12:06:42]: IPHTTPS URL endpoint is:
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Successfully connected to endpoint
https://direct.contoso.com:443.
[03-02-15 12:06:42]: Received response from corp.contoso.com, RTT is 53 msec.
[03-02-15 12:06:42]: Running Windows Firewall tests.
[03-02-15 12:06:42]: The current profile of the Windows Firewall is Public.
[03-02-15 12:06:42]: The Windows Firewall is enabled in the current profile Public.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
[03-02-15 12:06:42]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
[03-02-15 12:06:42]: Running certificate tests.
[03-02-15 12:06:42]: No usable machine certificate found.
[03-02-15 12:06:42]: Found 0 machine certificates on this client computer.
[03-02-15 12:06:42]: Running IPsec infrastructure tunnel tests.
[03-02-15 12:06:43]: Successfully connected to domain sysvol share, found 11 policies.
[03-02-15 12:06:43]: Running IPsec intranet tunnel tests.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::1, RTT is 333 msec.
[03-02-15 12:06:43]: Successfully reached 2001:db8:1:1000::2, RTT is 26 msec.
[03-02-15 12:06:44]: Successfully reached HTTP probe at
http://directaccess-WebProbeHost.corp.contoso.com.
[03-02-15 12:06:44]: Running selected post-checks script.
[03-02-15 12:06:44]: No post-checks script specified or the file does not exist.
[03-02-15 12:06:44]: Finished running post-checks script.
[03-02-15 12:06:44]: Finished running all tests.
This tool is probably configured to test for certificates even if you don't need one in your configuration so this error is normal.
Your problem is your IPsec tunnels not working. I'll suggest you to enable IPsec audit mode on your client and check the error messages in the Security log in your event viewer. Last thing i just remembered, are you using an anti-virus on your client and/or
server? I've got problem with one killing all IPsec packets
Gerald
-
Edited by
Gerald Mathieu
Tuesday, February 03, 2015 11:45 AM
February 3rd, 2015 2:30pm
I assume you meant this command:
C:\Windows\system32>netsh interface httpstunnel show interfaces
Interface IPHTTPSInterface (Group Policy) Parameters
------------------------------------------------------------
Role : client
URL :
https://directaccess.workbase.org.nz:443/IPHTTPS
Last Error Code : 0x0
Interface Status : IPHTTPS interface active
The IPHTTPS tunnel is active with an IPv6 address but no Infrastructure or User Tunnel active
Thanks for pointing out those hotfixes - it's possible one or two of those might help if they do i'll let you know
February 4th, 2015 12:03am
OK Thanks Gerald, you're right, there's no main mode or quick mode security associations showing in Windows Firewall.
I'll have to enable the audit on the local laptop though as I don't have ready access to the LAN to update the group policy. I'll let you know if what it comes back with.
I really appreciate your help a great deal it's already helped make sense of this a lot - now if I can just figure out why IPSEC is failing to work.. I have this connection going through a Cisco ASA - I would have thought that wouldn't matter since
it's all 443 traffic, but I have a horrible feeling it's trying to be clever and screwing things up for me - wouldn't be the first time..
February 4th, 2015 12:19am
OK we have a Main Mode failure though i'm not sure why - No Policy Configured?? But I can see it in the Windows Firewall!:
An IPsec main mode negotiation failed.
Local Endpoint:
Local Principal Name: -
Network Address: fd9f:3106:7e9b:1000:3:fab8:c7c8:c18f
Keying Module Port: 500
Remote Endpoint:
Principal Name: -
Network Address: fd9f:3106:7e9b:1000::1
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: bb8f28c45417eef3
Responder Cookie: 0000000000000000
February 4th, 2015 12:41am
Hi
To have a complete view enable IPSEC audit on the DirectAccess Gateway. Sometimes we have more informations on This side rather than on client-side.
February 4th, 2015 4:05am
Hi,
The first tunnel for your configuration is based on HTTPS. This is the DirectAccess entry point.
When your client has the connectivity, you receive from the server an IPv6 address.
Then, IPsec tunnels are created between the Public/Private profiles of the Windows Firewall (both server and client)
IPsec is using UDP 500.
If your HTTPS Tunnel is up, your client's firewall can contact the server's firewall but...
Last time I've seen this problem, it was because the DirectAccess server was using McAfee VSE 8.8 (Patch 3 or 4)
When VSE 8.8 is installed on a Windows Server (or Workstation), something seems to force the Windows Firewall to drop all UPD500 packets and the only way to see it is to enable the Windows Firewall logs. I reported this problem to McAfee last year and they
published a new KB that acts as a workaround for me. (https://kc.mcafee.com/corporate/index?page=content&id=KB79622)
You can try to create an additional rule on your server's firewall allowing incoming UPD500 connections to be sure that something is not messing with the server's configuration.
Gerald
-
Edited by
Gerald Mathieu
2 hours 18 minutes ago
February 4th, 2015 4:22am
Hi,
The first tunnel for your configuration is based on HTTPS. This is the DirectAccess entry point.
When your client has the connectivity, you receive from the server an IPv6 address.
Then, IPsec tunnels are created between the Public/Private profiles of the Windows Firewall (both server and client)
IPsec is using UDP 500.
If your HTTPS Tunnel is up, your client's firewall can contact the server's firewall but...
Last time I've seen this problem, it was because the DirectAccess server was using McAfee VSE 8.8 (Patch 3 or 4)
When VSE 8.8 is installed on a Windows Server (or Workstation), something seems to force the Windows Firewall to drop all UPD500 packets and the only way to see it is to enable the Windows Firewall logs. I reported this problem to McAfee last year and they
published a new KB that acts as a workaround for me. (https://kc.mcafee.com/corporate/index?page=content&id=KB79622)
You can try to create an additional rule on your server's firewall allowing incoming UPD500 connections to be sure that something is not messing with the server's configuration.
Gerald
-
Edited by
Gerald Mathieu
Wednesday, February 04, 2015 9:28 AM
February 4th, 2015 12:21pm
Hi,
The first tunnel for your configuration is based on HTTPS. This is the DirectAccess entry point.
When your client has the connectivity, you receive from the server an IPv6 address.
Then, IPsec tunnels are created between the Public/Private profiles of the Windows Firewall (both server and client)
IPsec is using UDP 500.
If your HTTPS Tunnel is up, your client's firewall can contact the server's firewall but...
Last time I've seen this problem, it was because the DirectAccess server was using McAfee VSE 8.8 (Patch 3 or 4)
When VSE 8.8 is installed on a Windows Server (or Workstation), something seems to force the Windows Firewall to drop all UPD500 packets and the only way to see it is to enable the Windows Firewall logs. I reported this problem to McAfee last year and they
published a new KB that acts as a workaround for me. (https://kc.mcafee.com/corporate/index?page=content&id=KB79622)
You can try to create an additional rule on your server's firewall allowing incoming UPD500 connections to be sure that something is not messing with the server's configuration.
Gerald
-
Edited by
Gerald Mathieu
Wednesday, February 04, 2015 9:28 AM
February 4th, 2015 12:21pm
Hi,
The first tunnel for your configuration is based on HTTPS. This is the DirectAccess entry point.
When your client has the connectivity, you receive from the server an IPv6 address.
Then, IPsec tunnels are created between the Public/Private profiles of the Windows Firewall (both server and client)
IPsec is using UDP 500.
If your HTTPS Tunnel is up, your client's firewall can contact the server's firewall but...
Last time I've seen this problem, it was because the DirectAccess server was using McAfee VSE 8.8 (Patch 3 or 4)
When VSE 8.8 is installed on a Windows Server (or Workstation), something seems to force the Windows Firewall to drop all UPD500 packets and the only way to see it is to enable the Windows Firewall logs. I reported this problem to McAfee last year and they
published a new KB that acts as a workaround for me. (https://kc.mcafee.com/corporate/index?page=content&id=KB79622)
You can try to create an additional rule on your server's firewall allowing incoming UPD500 connections to be sure that something is not messing with the server's configuration.
Gerald
-
Edited by
Gerald Mathieu
Wednesday, February 04, 2015 9:28 AM
February 4th, 2015 12:21pm
Hi BenoitS,
I've done as you suggested and I'm getting exactly the same Main Mode errors on the Direct Access Server - just the Local and Remote Endpoints are switched.
Interestingly I found this post by someone who's apparently had a lot of experience troubleshooting DA:
After a few years of working with it, I've found the following 2 things to be the most common reasons for machine-specific infrastructure tunnel problems with DirectAccess.
1: Certificate problems. The first credential used for the infrastructure tunnel is a certificate.
You'll get Policy Not Configured if the certificate is invalid. This could be an caused by an expired certificate, a subject name mismatch, incorrect certificate usage (Server auth/Client auth
via the built-in Computer template), or your published revocation list
for the root or issuing CA may be out of date.
Again we come back to what I originally suspected - we are trying to use a self-signed cert - there is no CRL published for it. My suspicion is that the same cert used for the IPHTTPS tunnel is used for the IPSEC tunnels as well and its for the IPSEC tunnels
you need the CRL. This page:
https://technet.microsoft.com/en-us/library/jj134204.aspx#ConfigCAs on installed DA has the following:
Self-signed certificate
If you use a self-signed certificate, the following are required, if they do not already exist:
- A website certificate that is used for IP-HTTPS authentication. The certificate subject should be an externally resolvable FQDN that is reachable from the Internet.
- A CRL distribution point that is reachable from a publicly resolvable FQDN.
I think I'm going to have to at least try a public SSL Cert and see what happens.
February 11th, 2015 2:02am
Hello,
You can try with a public certificate but it will only be used on the IP-HTTPS tunnel and this part of your setup is working because your HTTPS Interface is up and you have received an IPv6 address from your DirectAccess server.
Can you check your configuration in your server if you didn't active the "Use computer certificates" by mistake?
If this is not activated, your IPsec Infrastructure Tunnel will not try to authenticate the Main Mode using certificates but with Kerberos.
Can you post IPsec Main Mode errors from both client and server?
Also I think you spotted a mistake in the DirectAccess TechNet page.
A Self-signed certificate generated by the DirectAccess wizard doesn't contains the "CRL Distribution Points" field.
Gerald
-
Edited by
Gerald Mathieu
35 minutes ago
February 12th, 2015 5:29am
Hello,
You can try with a public certificate but it will only be used on the IP-HTTPS tunnel and this part of your setup is working because your HTTPS Interface is up and you have received an IPv6 address from your DirectAccess server.
Can you check your configuration in your server if you didn't active the "Use computer certificates" by mistake?
If this is not activated, your IPsec Infrastructure Tunnel will not try to authenticate the Main Mode using certificates but with Kerberos.
Can you post IPsec Main Mode errors from both client and server?
Also I think you spotted a mistake in the DirectAccess TechNet page.
A Self-signed certificate generated by the DirectAccess wizard doesn't contains the "CRL Distribution Points" field and only a Certificate Authority will create a CRL which contains revoked certificates.
Self-Signed certificate can't be revoked.
Gerald
-
Edited by
Gerald Mathieu
19 hours 28 minutes ago
February 12th, 2015 1:28pm
Hello,
You can try with a public certificate but it will only be used on the IP-HTTPS tunnel and this part of your setup is working because your HTTPS Interface is up and you have received an IPv6 address from your DirectAccess server.
Can you check your configuration in your server if you didn't active the "Use computer certificates" by mistake?
If this is not activated, your IPsec Infrastructure Tunnel will not try to authenticate the Main Mode using certificates but with Kerberos.
Can you post IPsec Main Mode errors from both client and server?
Also I think you spotted a mistake in the DirectAccess TechNet page.
A Self-signed certificate generated by the DirectAccess wizard doesn't contains the "CRL Distribution Points" field and only a Certificate Authority will create a CRL which contains revoked certificates.
Self-Signed certificate can't be revoked.
Gerald
-
Edited by
Gerald Mathieu
Thursday, February 12, 2015 4:19 PM
February 12th, 2015 1:28pm
Hello,
You can try with a public certificate but it will only be used on the IP-HTTPS tunnel and this part of your setup is working because your HTTPS Interface is up and you have received an IPv6 address from your DirectAccess server.
Can you check your configuration in your server if you didn't active the "Use computer certificates" by mistake?
If this is not activated, your IPsec Infrastructure Tunnel will not try to authenticate the Main Mode using certificates but with Kerberos.
Can you post IPsec Main Mode errors from both client and server?
Also I think you spotted a mistake in the DirectAccess TechNet page.
A Self-signed certificate generated by the DirectAccess wizard doesn't contains the "CRL Distribution Points" field and only a Certificate Authority will create a CRL which contains revoked certificates.
Self-Signed certificate can't be revoked.
Gerald
-
Edited by
Gerald Mathieu
Thursday, February 12, 2015 4:19 PM
February 12th, 2015 1:28pm
Hello,
You can try with a public certificate but it will only be used on the IP-HTTPS tunnel and this part of your setup is working because your HTTPS Interface is up and you have received an IPv6 address from your DirectAccess server.
Can you check your configuration in your server if you didn't active the "Use computer certificates" by mistake?
If this is not activated, your IPsec Infrastructure Tunnel will not try to authenticate the Main Mode using certificates but with Kerberos.
Can you post IPsec Main Mode errors from both client and server?
Also I think you spotted a mistake in the DirectAccess TechNet page.
A Self-signed certificate generated by the DirectAccess wizard doesn't contains the "CRL Distribution Points" field and only a Certificate Authority will create a CRL which contains revoked certificates.
Self-Signed certificate can't be revoked.
Gerald
-
Edited by
Gerald Mathieu
Thursday, February 12, 2015 4:19 PM
February 12th, 2015 1:28pm
Hi everyone,
I finally found out what the problem is and you won't believe it! The simplest thing in the world!
Some doofus had turned off the Windows Firewall! That's all it was!
Thanks to everyone who took the time to try and help!
Cheers
Scitt
-
Marked as answer by
Microsoft Designertech
10 hours 57 minutes ago
February 26th, 2015 7:50pm
Hi everyone,
I finally found out what the problem is and you won't believe it! The simplest thing in the world!
Some doofus had turned off the Windows Firewall! That's all it was!
Thanks to everyone who took the time to try and help!
Cheers
Scitt
-
Marked as answer by
Microsoft Designertech
Friday, February 27, 2015 12:51 AM
February 27th, 2015 12:51am
Hi everyone,
I finally found out what the problem is and you won't believe it! The simplest thing in the world!
Some doofus had turned off the Windows Firewall! That's all it was!
Thanks to everyone who took the time to try and help!
Cheers
Scitt
-
Marked as answer by
Microsoft Designertech
Friday, February 27, 2015 12:51 AM
February 27th, 2015 3:51am