none
Configuration of Direct Access 2012

    Question

  • Good morning.

    I have tried to set up Direct Access from what I see is pretty much a 30-40 minute job, but has turned out to be something of a pain. Having followed the video on youtube for Windows Server 2012 with Basic PKI configuration and Windows 7 clients. I have set up a working DA server with no issues and all green ticks.

    Here's a run down.

    • I have a DC (2012) with the CA already installed.
    • I have a virtual DA (2012) set up with the advanced settings.
    • I have a a TMG 2010 server as the firewall with a Non-Web Publishing rule designed to forward HTTPS requests to the DA on the internal network.

    The set up went as planned and I followed the instruction to set up the PKI and all computers have picked up a computer Certificate for the CA so that the internal root is validated.

    The Certificates that I chose for the DA server were as follows;

    DirectAccess-NLS.mydomain.local

    remote.my-external-domain-name.co.uk

    both published from my internal CA so that the root of the certificates were valid.

    I have a Third party wildcard cert ( *.my-external-domain-name.co.uk ) for TMG to allow other connection such as VPN and web access.

    DA Config:

    Step 1: Remote Clients

    I set up the DA server as per the video, set the DirectAccessClient group, and in the Network Connectivity Assistant The resource was filled in with the http://diectaccess-WebProbeHost URL.

    Step 2: Remote Access Server

    The Network Topology was set to Behind an edge device (with single network adapter), and then is says to type in the 'PUBLIC NAME' used by clients to connect to the Remove Access Server. Here I typed in the external DNS name remote.my-external-domain-name.co.uk.

    Network Adapters had the one ethernet and an IPv6 address. The Select Certificate sued to authenticate IP-HTTPS connections has the CN=remote.my-external-domain-name.co.uk.

    Authentication is set to AD and I used the root certificate of the CA for use computer certificates. I also Enabled windows 7 client computers to connect via DirectAccess.

    Step 3: Infrastructure Servers

    Network Location Sevrer had the NLS is deployed on this server with the DirectAccess-NLS cert.

    DNS had the internal domain and the DirectAccess-NLS. the Internal domain was pointing to the IPv4 address of the DA. I read that I need to put the external name suffix of remote.my-external-domain-name.co.uk entry in and pointed that to the internal DA IPv4 address also.

    DNS Suffix List was set automatically and I also added my external domain name just in case.

    Managerment was straight forward and I pointed to our System Centre 2012 R2 server.

    Upon clicking finish and applying the GPO policies everything went according to plan. All green ticks. I did a GPupdate on the client I was testing and the GPO policies came through.

    Now the issue I have is that on the internal network I get the Last Error 0x80190190 unable to connect to server. Now I am sure that this should say active as it is inside the network. I get the same error out side. When I check the DA server for netsh int https sh int  it returns the value that client authentication = NONE. I set it up to use computer certificates and even is I uncheck that it does not change. 

    It there a straight forward thing I missed or is it to do with publishing in TMG. Internally the direct access client will not connect as it will find the NLS in the internal DNS as I have the host record for both the server FQDN and the DirectAccess-NLS potining to the IPv4 address. I also have the external remote.my-external-domain-name.co.uk entry in the internal DNS to point to the internal IPv4.

    I have opened the ports for 443, 62000 on the DA for the IIS inbound and outbound. 

    I have a windows 8 client but need to test it as Windows 8 is supposed to work just like that.

    What am I doing wrong here?? Any ideas would be much appreciated. 

    Wednesday, April 02, 2014 7:10 AM

Answers

  • Hey, sorry for the delay. I do think that TMG is causing your problems with the clients not being able to connect.

    First though we should make sure that the DA config is correctly. In Step 2, you want to specify the wildcard cert to be used for IP-HTTPS, and you want to specify your internal root CA on the Authentication page. In Step 3, this table is basically like a HOSTS file for the DA client machines. It is telling them what namespaces need to flow inside the DA tunnels, and which namespaces to flow outside of the DA tunnels. So your internal .local suffix should be included, and typically your public suffix would not be included (would simply not be in the list) - if you have it setup so that your public suffix is included in this table, then those namespaces will try to flow inside the DA tunnels. If you are including your public DNS name for the DirectAccess connection itself, this is going to create a catch-22 because it is trying to make it's initial connection to the public name inside DA tunnels which do not yet exist. Since you have a .local inside, I would start by dumbing down this list in Step 3, include ONLY *.mydomain.local in that list, and make sure there is an exclusion set for the name of your NLS website. If you need to add some *.mydomain.co.uk names, add them individually later, after confirming that you can get connected in the first place.

    You said something about TMG may be blocking port 443. The job that TMG does in this case should be really simple, it it just taking traffic from outside and NATing it through to the "public" IP of the DirectAccess server. If the NAT is not working, or if you are trying to share TMG's public IP with multiple services running 443 traffic, that could cause problems. Just a one-to-one NAT that allows TCP 443 should be what you need. If this continues to be a problem, try placing the DirectAccess server in parallel to TMG. Give the DA server a real public IP address so that you know TMG isn't in the middle and messing things up, and see how far you get in that scenario. That is the most common way that I do installs, though that is when using our locked down security appliances that are prepared to run on the edge.

    • Marked as answer by SJB Tech Friday, April 25, 2014 6:01 AM
    Thursday, April 17, 2014 2:13 PM
  • If your internal network is not configured for IPv6, then you need NAT64 and DNS64.

    Usually this will be enabled by default if no configured IPv6 address is detected, you can verify this in the Remote Access Management Console / Configuration / Step 2 / Network Adapapters. It should say "Transition technologies are enabled for IPv4 support".

    You are ok for your external name and certifcate.

    How are you accessing internal resources? Do note that you cannot use IP addresses for internal resources as those requests will be sent outside the tunnel. You must use names that can be resolved in the internal DNS. Try using internal fqdn's.

    Your internal domain should be listed in Step 3 / DNS with a IPv6 address that points to your (internal) NIC (ipconfig /all). This address is configured automatically when configuring DA.


    Hth, Anders Janson Enfo Zipper

    • Marked as answer by SJB Tech Friday, April 25, 2014 6:01 AM
    Thursday, April 24, 2014 8:00 AM
  • Thank you for this Jordan.

    I have now got it working. The next step is to make sure my applications are all using Names rather than IP addresses.

    I have basically setup the system as per my original thread that follows, NOT in BOLD.

    I have tried to set up Direct Access from what I see is pretty much a 30-40 minute job, but has turned out to be something of a pain. Having followed the video on youtube for Windows Server 2012 with Basic PKI configuration and Windows 7 clients. I have set up a working DA server with no issues and all green ticks.

    Here's a run down.

    • I have a DC (2012) with the CA already installed.
    • I have a virtual DA (2012) set up with the advanced settings.
    • I have a a TMG 2010 server as the firewall with a Non-Web Publishing rule designed to forward HTTPS requests to the DA on the internal network.

    The set up went as planned and I followed the instruction to set up the PKI and all computers have picked up a computer Certificate for the CA so that the internal root is validated.

    The Certificates that I chose for the DA server were as follows;

    DirectAccess-NLS.mydomain.local

    remote.my-external-domain-name.co.uk

    both published from my internal CA so that the root of the certificates were valid.

    I have a Third party wildcard cert ( *.my-external-domain-name.co.uk ) for TMG to allow other connection such as VPN and web access.

    DA Config:

    Step 1: Remote Clients

    I set up the DA server as per the video, set the DirectAccessClient group, and in the Network Connectivity Assistant The resource was filled in with the http://diectaccess-WebProbeHost URL.

    Step 2: Remote Access Server

    The Network Topology was set to Behind an edge device (with single network adapter), and then is says to type in the 'PUBLIC NAME' used by clients to connect to the Remove Access Server. Here I typed in the external DNS name remote.my-external-domain-name.co.uk.

    Network Adapters had the one ethernet and an IPv6 address. The Select Certificate sued to authenticate IP-HTTPS connections has the CN=remote.my-external-domain-name.co.uk.

    Authentication is set to AD and I used the root certificate of the CA for use computer certificates. I also Enabled windows 7 client computers to connect via DirectAccess.

    Step 3: Infrastructure Servers

    Network Location Sevrer had the NLS is deployed on this server with the DirectAccess-NLS cert.

    DNS had the internal domain and the DirectAccess-NLS. the Internal domain was pointing to the IPv4 address of the DA. I read that I need to put the external name suffix of remote.my-external-domain-name.co.uk entry in and pointed that to the internal DA IPv4 address also.

    DNS Suffix List was set automatically and I also added my external domain name just in case.

    Managerment was straight forward and I pointed to our System Centre 2012 R2 server.

    Upon clicking finish and applying the GPO policies everything went according to plan. All green ticks. I did a GPupdate on the client I was testing and the GPO policies came through.

    I have set up TMG as per the isa.org forum  

    http://www.isaserver.org/articles-tutorials/general/implementing-windows-server-2012-directaccess-behind-forefront-tmg-part2.html .

    @ Jordan - I ensured that I had a separate external IP address for the requests from the clients to TMG as I publish websites internally.

    I used a third party wildcard cert for the IP-HTTPS connect part in DA Config Step 2.

    All the rest of the DA set up was pretty much out of the box as stated above. 



    • Marked as answer by SJB Tech Friday, April 25, 2014 5:57 AM
    • Edited by SJB Tech Friday, April 25, 2014 5:59 AM
    Friday, April 25, 2014 5:57 AM

All replies

  • There are a few things that I would suggest:

    1. The biggest problem that I see is inside the NRPT. (The DNS screen in Step 3) You do NOT need to include your public "remote.my-external-domain-name.co.uk" - that will break DirectAccess. In fact, in some cases what you need to do is create a specific exclusion for that name, but only in cases where you are using split-brain DNS. If your internal DNS suffix is different than your public, and it appears that it is based on your info, then the only two records you need in here are the ones auto-created by the wizard for your suffix inclusion and the NLS exclusion.

    2. At some point I definitely recommend moving the NLS website onto it's own server, but that can be a job for a later time.

    3. I recommend using a copy of your wildcard cert on the DirectAccess server itself as the IP-HTTPS certificate, not one from your internal CA server. When you choose to use your own internal certs as public-facing certs, that means you also have to public things about your PKI to the web, like the CRL. This is not a straight-forward task and even seased PKI guys struggle with making this work properly. Since you already have a wildcard, install it on the DirectAccess server and re-run through Step 2 of the wizards to choose that certificate on your IP addressing screen, where it asks you for the IP-HTTPS certificate.

    Friday, April 04, 2014 1:36 PM
  • Thank you for this.
    I removed the GPOs and the config from the DA to start it up again with the requirements that you set out in points 1 and 3. This did seem a more logical approach to the fact I have an mydomain.co.uk and a mydomain.local . 
    However, upon changing the settings I found that I was getting a last error of 0x2afc.
    I changed the Remote access server settings (STEP 2) to have remote.mydomain.co.uk and used the wildcard cert. I was not too sure about the ROOT certificate, whether to use my internal CA or the ROOT of the wildcard. I did try both.
    For step 3 (Infrastructure servers) I changed the mydomain.local to mydomain.co.uk. I got the following when I ran the NETSH INT HTTPS SH INT;

    Role : client
    URL : https://remote.mydomain.co.uk:443/IPHTTPS
    Last Error Code : 0×0
    Interface Status : IPHTTPS interface is active.

    this was when I was connected to  INSIDE the Corporation.
    I then found a link to TMG set up and followed that, again I had nothing. I believe that I have an issue resolving remote.mydomain.co.uk on the client as I have not specified it in the exceptions list. Upon doing this I can then PING remote.mydomain.co.uk on the client from home. However, TMG may be blocking port 443 and I do have connections on that port for other published WEB servers. 
    Is that going to cause an issue? I tried moving the rule to the top and I can still access all published servers.

    Outside I get the following when running NETSH INT HTTPS SH INT;
    Role : client
    URL : https://remote.mydomain.co.uk:443/IPHTTPS
    Last Error Code : 0x2afc
    Interface Status : failed to connect to the IPHTTPS server. Waiting to reconnect

    or 
    Role : client
    URL : https://remote.mydomain.co.uk:443/IPHTTPS
    Last Error Code : 0x80190190
    Interface Status : failed to connect to the IPHTTPS server. Waiting to reconnect

    I get the first returned if the client cannot resolve remote.mydomain.co.uk. I get the second when it can. Do you think this may be a TMG issue?

    These are the articles I used to try and trouble shoot since I posted this. 

    http://www.isaserver.org/articles-tutorials/general/implementing-windows-server-2012-directaccess-behind-forefront-tmg-part1.html

    http://directaccessguide.com/2013/08/21/getting-ip-https-error-code-0x2afc/

    Both of which make sense, but I just cannot get through. TMG is set as NAT not route as this stops internal web access to external. 

    Also should the config;

    Role : client
    URL : https://remote.mydomain.co.uk:443/IPHTTPS
    Last Error Code : 0×0
    Interface Status : IPHTTPS interface is active. 

    say DEACTIVATED not ACTIVE when INSIDE the corporation?

    and;

    should the server be saying Cilent Authentication = NONE when  I have PKI set up for Win 7 clients?

    Interface IPHTTPSInterface Parameters
    ------------------------------------------------------------
    Role                       : server
    URL                       : https://remote.mydomain.co.uk:443/IPHTTPS
    Client authentication mode : none
    Last Error Code           : 0x0
    Interface Status           : IPHTTPS interface active

    • Edited by SJB Tech Wednesday, April 09, 2014 11:11 AM
    Wednesday, April 09, 2014 6:27 AM
  • Hi,

    I have checked in TMG and I am getting this on the rule that is applied for Direct Access through TMG

    Description: The server publishing rule Direct Access, which maps 172.16.110.5:443:TCP to 213.160.108.194:443 for the protocol HTTPS Server, was unable to bind a socket for the server. The server publishing rule cannot be applied.
    The failure is due to error: You were not connected because a duplicate name exists on the network. If joining a domain, go to System in Control Panel to change the computer name and try again. If joining a workgroup, choose another workgroup name.

    I have no other server with that and never have had. I did check that the TMG has DNS entries for RAS on various IPs. Is this maybe causing an issue?

    Wednesday, April 09, 2014 4:04 PM
  • Hey, sorry for the delay. I do think that TMG is causing your problems with the clients not being able to connect.

    First though we should make sure that the DA config is correctly. In Step 2, you want to specify the wildcard cert to be used for IP-HTTPS, and you want to specify your internal root CA on the Authentication page. In Step 3, this table is basically like a HOSTS file for the DA client machines. It is telling them what namespaces need to flow inside the DA tunnels, and which namespaces to flow outside of the DA tunnels. So your internal .local suffix should be included, and typically your public suffix would not be included (would simply not be in the list) - if you have it setup so that your public suffix is included in this table, then those namespaces will try to flow inside the DA tunnels. If you are including your public DNS name for the DirectAccess connection itself, this is going to create a catch-22 because it is trying to make it's initial connection to the public name inside DA tunnels which do not yet exist. Since you have a .local inside, I would start by dumbing down this list in Step 3, include ONLY *.mydomain.local in that list, and make sure there is an exclusion set for the name of your NLS website. If you need to add some *.mydomain.co.uk names, add them individually later, after confirming that you can get connected in the first place.

    You said something about TMG may be blocking port 443. The job that TMG does in this case should be really simple, it it just taking traffic from outside and NATing it through to the "public" IP of the DirectAccess server. If the NAT is not working, or if you are trying to share TMG's public IP with multiple services running 443 traffic, that could cause problems. Just a one-to-one NAT that allows TCP 443 should be what you need. If this continues to be a problem, try placing the DirectAccess server in parallel to TMG. Give the DA server a real public IP address so that you know TMG isn't in the middle and messing things up, and see how far you get in that scenario. That is the most common way that I do installs, though that is when using our locked down security appliances that are prepared to run on the edge.

    • Marked as answer by SJB Tech Friday, April 25, 2014 6:01 AM
    Thursday, April 17, 2014 2:13 PM
  • Thank you.

    Having looked at TMG more closely I believe is is this causing the issue. Yes we do have multiple sites being published and I do have other external IP addresses. I may see if I can get around setting up another External IP on the external NIC and then set up a separate listener to route the 443 traffic. It would mean that I will need 443 pointed to both external IP address from my ISP.

    I'll let you know if this works. 

    Thank you again.

    Tuesday, April 22, 2014 12:21 PM
  • @Jordan,

    I have changed the table in the DA server to reflect the internal name and the NLS name (STEP 3). I have also ensured that I have another external IP address that has been set up and I have applied this to the external NIC of the TMG with its appropriate subnet.

    I changed the DA rule to look at the HTTPS server protocol from this new external IP address and I had our ISP point the host record for remote to this address also. There is no conflict on TMG and when I connect the client with an external IP address it now says the following.

    NETSH INT HTTPS SH INT;

    Role : client
    URL : https://remote.mydomain.co.uk:443/IPHTTPS
    Last Error Code : 0×0
    Interface Status : IPHTTPS interface is active.

    This looks good but I cannot see a connection on the DA server. I am going to take the laptop home and try from there to see if it might be the IP address that I am giving it. 

    do I need a network set to route traffic from external to the DA in TMG? just a thought.

    Tom.


    • Edited by SJB Tech Wednesday, April 23, 2014 12:32 PM
    Wednesday, April 23, 2014 12:31 PM
  • Right,

    I did some more work last night and it is clear that the tunnel has been made. I have the IPHTTPS TUNNELL IPV6 address when I run IPCONFIG. I can also ping the endpoint IPV6 address of the DA server. However, I cannot access anything on the network.

    Is this because I am using the route https://remote.mydomain.co.uk/IPHTTPS (external domain name) and not an internal one? I have used my third party wildcard cert and this apparently works. Is there an issue with the DNS64? I have read that this needs to be enabled. I'm not sure if I need this on the DC.

    regards,

    Tom.

    Thursday, April 24, 2014 6:24 AM
  • If your internal network is not configured for IPv6, then you need NAT64 and DNS64.

    Usually this will be enabled by default if no configured IPv6 address is detected, you can verify this in the Remote Access Management Console / Configuration / Step 2 / Network Adapapters. It should say "Transition technologies are enabled for IPv4 support".

    You are ok for your external name and certifcate.

    How are you accessing internal resources? Do note that you cannot use IP addresses for internal resources as those requests will be sent outside the tunnel. You must use names that can be resolved in the internal DNS. Try using internal fqdn's.

    Your internal domain should be listed in Step 3 / DNS with a IPv6 address that points to your (internal) NIC (ipconfig /all). This address is configured automatically when configuring DA.


    Hth, Anders Janson Enfo Zipper

    • Marked as answer by SJB Tech Friday, April 25, 2014 6:01 AM
    Thursday, April 24, 2014 8:00 AM
  • Thank you for this Jordan.

    I have now got it working. The next step is to make sure my applications are all using Names rather than IP addresses.

    I have basically setup the system as per my original thread that follows, NOT in BOLD.

    I have tried to set up Direct Access from what I see is pretty much a 30-40 minute job, but has turned out to be something of a pain. Having followed the video on youtube for Windows Server 2012 with Basic PKI configuration and Windows 7 clients. I have set up a working DA server with no issues and all green ticks.

    Here's a run down.

    • I have a DC (2012) with the CA already installed.
    • I have a virtual DA (2012) set up with the advanced settings.
    • I have a a TMG 2010 server as the firewall with a Non-Web Publishing rule designed to forward HTTPS requests to the DA on the internal network.

    The set up went as planned and I followed the instruction to set up the PKI and all computers have picked up a computer Certificate for the CA so that the internal root is validated.

    The Certificates that I chose for the DA server were as follows;

    DirectAccess-NLS.mydomain.local

    remote.my-external-domain-name.co.uk

    both published from my internal CA so that the root of the certificates were valid.

    I have a Third party wildcard cert ( *.my-external-domain-name.co.uk ) for TMG to allow other connection such as VPN and web access.

    DA Config:

    Step 1: Remote Clients

    I set up the DA server as per the video, set the DirectAccessClient group, and in the Network Connectivity Assistant The resource was filled in with the http://diectaccess-WebProbeHost URL.

    Step 2: Remote Access Server

    The Network Topology was set to Behind an edge device (with single network adapter), and then is says to type in the 'PUBLIC NAME' used by clients to connect to the Remove Access Server. Here I typed in the external DNS name remote.my-external-domain-name.co.uk.

    Network Adapters had the one ethernet and an IPv6 address. The Select Certificate sued to authenticate IP-HTTPS connections has the CN=remote.my-external-domain-name.co.uk.

    Authentication is set to AD and I used the root certificate of the CA for use computer certificates. I also Enabled windows 7 client computers to connect via DirectAccess.

    Step 3: Infrastructure Servers

    Network Location Sevrer had the NLS is deployed on this server with the DirectAccess-NLS cert.

    DNS had the internal domain and the DirectAccess-NLS. the Internal domain was pointing to the IPv4 address of the DA. I read that I need to put the external name suffix of remote.my-external-domain-name.co.uk entry in and pointed that to the internal DA IPv4 address also.

    DNS Suffix List was set automatically and I also added my external domain name just in case.

    Managerment was straight forward and I pointed to our System Centre 2012 R2 server.

    Upon clicking finish and applying the GPO policies everything went according to plan. All green ticks. I did a GPupdate on the client I was testing and the GPO policies came through.

    I have set up TMG as per the isa.org forum  

    http://www.isaserver.org/articles-tutorials/general/implementing-windows-server-2012-directaccess-behind-forefront-tmg-part2.html .

    @ Jordan - I ensured that I had a separate external IP address for the requests from the clients to TMG as I publish websites internally.

    I used a third party wildcard cert for the IP-HTTPS connect part in DA Config Step 2.

    All the rest of the DA set up was pretty much out of the box as stated above. 



    • Marked as answer by SJB Tech Friday, April 25, 2014 5:57 AM
    • Edited by SJB Tech Friday, April 25, 2014 5:59 AM
    Friday, April 25, 2014 5:57 AM
  • Very glad to hear you got it working! Thanks for the update!

    Just one note about your last post for anyone reading this in the future - if it is working for you, then I suppose you can leave it alone, but inside the DNS screen of Step 3 in the wizards, which is where you configure the NRPT, I think you have an entry there that shouldn't be. Your public DNS name for IP-HTTPS (remote.my-external-domain-name.co.uk) should NOT be included, or rather it should not point to your internal DA IPv4 address. In most configurations when your internal DNS is different than your external DNS, you don't need to add any entries in this list at all for your external namespace. 

    If you add remote.my-external-domain-name.co.uk into the NRPT and tell it to resolve that name to the DA server, then it will try to push this name inside the DirectAccess tunnels. This is not the behavior you want. You want that remote.my-external-domain-name.co.uk name to resolve over the user's regular internet connection, so you either don't want it to be included in the NRPT at all, or you want it to be set in there as an Exclusion (with no DNS server information to the right of it) - this way you ensure that your initial tunnel-building traffic that is flowing to that name does not try to flow inside a tunnel that does not yet exist. Is that clear as mud? :)

    Monday, April 28, 2014 2:23 PM