Answered DirectAccess Connection Failing

  • Wednesday, October 10, 2012 2:41 PM
     
     

    I see quite a few DA posts, but I cannot seem to find the answer to my question.

    I have a client that is connecting on the IPHttps protocal, but the client never goes to the connected state. I see it in the remote access client statys as connected, and I see bytes in and out, but the client itself keeps saying it is failing connecting to the probe host. I've followed the setup instructions closely and cannot find a solution.

    My firewall only forwards port 443. Do I need any additional ports?  If anyone has any suggestions, please let me know.

All Replies

  • Wednesday, October 10, 2012 2:54 PM
     
     
  • Thursday, October 11, 2012 8:53 AM
     
     

    Hi,

    Can you describe your setup in a little bit more detail?
    (1 or 2 nics? NLS hosted on the DA server? Windows7 or Windows 8 clients? Kerberos proxying or Machine certificate authentication?)

    Some tests you could start with:

    * What is the URL for your probe?
    - Can you manually connect to it

    * Can you ping any internal resources? (intranet/fileservers/domaincontrollers?)
    * Can you connect to any internal resources?
    - Browse to the intranet
    - Access fileshares
    - RDP to a server that should be reachable (like the domaincontroller)

    It is possible that it is only accessing the probe that does not work and therefore NCA/DCA claims that you do not have connectivity.


    Jonas Blom | Relevo AB | http://blog.nrpt.se

  • Thursday, October 11, 2012 12:08 PM
     
     

    1 or 2 nics?  1, behind NAT
    NLS hosted on the DA server?  Yes
    Windows7 or Windows 8 clients? Win8 (for now)
    Kerberos proxying or Machine certificate authentication? Kerberos (for now)

    Some tests you could start with:

    * What is the URL for your probe?
    - Can you manually connect to it?  The internal URL for the probe cannot be reached

    * Can you ping any internal resources? When on external network, I cannot ping. When on internal, I can.

    I cannot reach any internal resources at all when connected.

    It is possible that it is only accessing the probe that does not work and therefore NCA/DCA claims that you do not have connectivity.


  • Friday, October 12, 2012 9:55 AM
     
     

    Hi again,
    Has your client received an IPv6 address on the IPHTTPS interface?

    If possible, produce a log from NCA when your client is "connected" externally and upload it somewhere so it is possible to look at all the various settings (skydrive?)

    If it is not possible, can you post the output from netsh interface httpstunnel show interfaces


    Jonas Blom | Relevo AB | http://blog.nrpt.se

  • Friday, October 12, 2012 12:17 PM
     
     

    I had the same problem at some point, can't really remember all the things i did but thanks to Jonas Blom I managed to get it to work. One of the faults i did was not to use a resolvable public name. I tried with a public IP in the DirectAccess configuration steps in the start. Also what I did was go through my firewall settings, checked my routing(public IP port 443 to internal IP DirectAccess). 

    For IPHTTPS you only need to open port 443 in your outer firewall.

    Hope that helps!


    • Edited by OrPhe0 Friday, October 12, 2012 1:01 PM
    •  
  • Friday, October 12, 2012 12:47 PM
     
     

    I'll get the logs uploaded soon.

    Question:

    If I got to the URL of the DA server in a web browser, should I see anything? https://directaccess.mydomain.com:443/IPHTTPS or will it just sit there and spin?

  • Friday, October 12, 2012 2:56 PM
     
     

    Jonas,

    It does have an ipv6 address.

    You can find the logs here:

    http://claytontech.com/directaccess_logs.html

    Thanks for your help and please let me know if you see anything I can look at.

  • Friday, October 12, 2012 7:21 PM
     
     

    Hi again,

    Disable the Teredo interface and remove the IPv6 configuration on your wifi interface and see if that fixes your problems.

    Your client has managed to establish the IPSec tunnels so I would guess that it has something to do with that your client does not know which IPv6 interface to send traffic on.


    Jonas Blom | Relevo AB | http://blog.nrpt.se


    • Edited by Jonas Blom Friday, October 12, 2012 7:23 PM
    •  
  • Friday, October 12, 2012 8:03 PM
     
     

    Thanks for the reply Jonas.

    I applied that configuration with no luck unfortunately.

    I can see that the IPHTTPS tunnel only is getting configured.  I think my MiFi has IPv6. Could that be causing an issue?

    Do you have any other suggestions?

    Thanks for all of your help.

  • Friday, October 12, 2012 9:18 PM
     
     

    Hi,

    Yes, try to find a way to disable the IPv6 on that interface also and see if things start to work.


    Jonas Blom | Relevo AB | http://blog.nrpt.se

  • Monday, October 15, 2012 12:35 PM
     
     
    This weekend, I connected to my home network which has no ipv6. I still could not get connected.
  • Monday, October 15, 2012 1:40 PM
     
     

    Hi again,

    Did you create a log when you were connected to your home network?


    Jonas Blom | Relevo AB | http://blog.nrpt.se

  • Monday, October 15, 2012 2:51 PM
     
     

    Unfortunately, I didn't. That is something I can do tonight though.

    I also noticed there is no default gateway on the iphttps. Should that have a gateway assigned?

    • Edited by Clayton.B Monday, October 15, 2012 4:45 PM
    •  
  • Monday, October 15, 2012 5:39 PM
     
     

    Jonas,

    What is supposed to be returned on the URL to the DA server. I'm very curious.  For example...

    In the logs, the DirectAccess Server URL is https://directaccess.adom.com:443/iphttps

    If I try and open that URL directly, it just spins and never returns a success, or error, or anything. Could that be why it is saying that it's not connecting? Is that supposed to be returning a page, or success message?

  • Tuesday, October 16, 2012 7:36 AM
     
     

    Hi again,

    That is actually the correct behaviour when using DirectAccess with Windows Server 2012.

    I normally verify that the service is listening by browsing to something like
    http://da.xxx.se/test and verify that I get a 404 response that indicates that IE could reach the website but that the page was not found.

     


    Jonas Blom | Relevo AB | http://blog.nrpt.se

  • Tuesday, October 16, 2012 2:08 PM
     
     Answered

    Today, I blew away all of the config including removal of the GPs and removal of the RAS/DA roles. I did a complete reinstall from scratch. 

    I am now successfully conected with both my Win7 and Win8 clients.

    Thanks Jonas and everyone else for their assistance.

  • Tuesday, October 16, 2012 6:55 PM
     
     
    Glad to hear that you finally have a working setup :)

    Jonas Blom | Relevo AB | http://blog.nrpt.se