Hi

I've been struggling with this problem for over two weeks and still can't figure this one out. Hope someone can help me on this, please.

I have read dozens of articles, guides, threads...and can't find an exact situation or resolution, for my problem.

Scenario:

- Multiple physicall locations with different subnets, connected. (10.13.1.0/23 ; 10.13.2.0/23; 10.14.1.0/23; 10.15.1.0/23 and so on)

- Direct Access Server configured on Windows Server 2012 on the servers subnet 10.13.254.0/23. External proxy-pass for the internal NIC of the DA Server. (Internal NIC has a default gateway configured...in some articles this is not considered a correct configuration)

- No NLS server.

Problem:

 Firstly for some clients (Windows 7, 8 and 8.1) everything works ok. They know exactly when they are inside/ouside the corporate network, when outside they connect to DA without any problem. But this only happens if the client machine is configured (added to the domain and receive the DA GPO) in a specfic subnets in this case 10.13.1.0; 10.13.2.0; 10.13.3.0. and so on. This subnets are on the same physicall location of the servers subnet.

If we configure any client (added to the domain and receive the DA GPO) on any other subnets of other physicall locations, that machine will not connect to DA (they receive the DA GPO correctly). Other symptoms are:

- Nevertheless the remote subnets are "inside" the corporate, the clients state that they are "outside corporate network" (using netsh dnsclient show state).

- The clients can't ping/access internal resources (IPV4). They can only ping the DA server by name.

- The clients establish HTTPS tunnel correctly, and without errors.

-From the internal network we can't ping those clients.

I have read a lot and still can't find a place to start...initially I thought it might be a network routing misconfiguration...but the routing guys say that everything is ok (whatever that means :) ), I have added static routes to the DA server (with no luck), and all the solutions I came across didn't really fit on my problem...basically... I'm lost!

Can someone please be kind enough to help me on this one? Much appreciated...

Sorry for the rusty English.

Cheers

Cris

Hi,

First it is correct in a dual networked DA server you should not have the default gateway on the internal nic. Only the external adapter.

I would recommend following Jason Jones blog http://blog.msedge.org.uk/2010/04/recommended-network-card-configuration_14.html even though it was written for UAG (the previous DA version) it is still relevant.

Second  I would make sure your clients on the remote internal networks can resolve your NLS server and they are able to connect to the name you have assigned via SSL (TCP443). If you are using the DA servers as the NLS then you will need to allow all clients to connect again via SSL (TCP443).

I don't know if this will help, or not. I am NOT anywhere remotely close to being expert in DirectAccess technologies.

Last year we put in place a DA server and the environment sounds somewhat similar to yours.  We have multiple internal subnets.  We needed the DA clients to be able to communicate with all of them to some degree or other.  What we did (I think?) was have the traffic to the main LAN subnet handled via the internal NIC, then any additional traffic was handled via Static Routes on that internal LAN NIC as well.

We added the routes via a 'route' command from an elevated CMD prompt on the DA server, because I am mostly useless when it comes to powershell.  These were IPv4 routes mind you.  I don't know anything about IPv6 routing.  Each static route was for an individual IP address, with a Mask of 255.255.255.255, e.g.:

route add 10.20.30.40 mask 255.255.255.255 10.10.10.1 metric 2 if 12

where:

10.20.30.40 is the IP that we want the client to get to
10.10.10.1 is the gateway on the internal NIC of the DA server
12 is the interface number of the internal NIC of the DA server

After confirming the configuration via 'route print' and the routing table looking good, we tested 'ping' from a Windows 7 DA Client and it worked PROVIDED that we pinged either a Hostname or a Fully Qualified Domain Name.  Pinging plain IPv4 addresses did NOT work, but we kind of expected that.

We found that applications which needed to use these routes to communicate with servers on one of the non-main-LAN subnets could do so provided that those apps supported IPv6 connections; those which were IPv4 only (a few old apps) could not connect.  As an example, we tested connections from Trend Micro Antivirus client running on a DirectAccess Windows 7 Client and it could talk happily to the Trend AV server on a non-main-LAN subnet.

EDIT: one more comment ... we have NOT yet configured Manage Out fully, so I cannot yet ping the DA clients from inside my main LAN or any other subnet.

• Edited by 0499FROSTY 7 hours 56 minutes ago

I don't know if this will help, or not. I am NOT anywhere remotely close to being expert in DirectAccess technologies.

Last year we put in place a DA server and the environment sounds somewhat similar to yours.  We have multiple internal subnets.  We needed the DA clients to be able to communicate with all of them to some degree or other.  What we did (I think?) was have the traffic to the main LAN subnet handled via the internal NIC, then any additional traffic was handled via Static Routes on that internal LAN NIC as well.

We added the routes via a 'route' command from an elevated CMD prompt on the DA server, because I am mostly useless when it comes to powershell.  These were IPv4 routes mind you.  I don't know anything about IPv6 routing.  Each static route was for an individual IP address, with a Mask of 255.255.255.255, e.g.:

route add 10.20.30.40 mask 255.255.255.255 10.10.10.1 metric 2 if 12

where:

10.20.30.40 is the IP that we want the client to get to
10.10.10.1 is the gateway on the internal NIC of the DA server
12 is the interface number of the internal NIC of the DA server

After confirming the configuration via 'route print' and the routing table looking good, we tested 'ping' from a Windows 7 DA Client and it worked PROVIDED that we pinged either a Hostname or a Fully Qualified Domain Name.  Pinging plain IPv4 addresses did NOT work, but we kind of expected that.

We found that applications which needed to use these routes to communicate with servers on one of the non-main-LAN subnets could do so provided that those apps supported IPv6 connections; those which were IPv4 only (a few old apps) could not connect.  As an example, we tested connections from Trend Micro Antivirus client running on a DirectAccess Windows 7 Client and it could talk happily to the Trend AV server on a non-main-LAN subnet.

EDIT: one more comment ... we have NOT yet configured Manage Out fully, so I cannot yet ping the DA clients from inside my main LAN or any other subnet.

• Edited by 0499FROSTY Monday, March 24, 2014 2:57 AM

I don't know if this will help, or not. I am NOT anywhere remotely close to being expert in DirectAccess technologies.

Last year we put in place a DA server and the environment sounds somewhat similar to yours.  We have multiple internal subnets.  We needed the DA clients to be able to communicate with all of them to some degree or other.  What we did (I think?) was have the traffic to the main LAN subnet handled via the internal NIC, then any additional traffic was handled via Static Routes on that internal LAN NIC as well.

We added the routes via a 'route' command from an elevated CMD prompt on the DA server, because I am mostly useless when it comes to powershell.  These were IPv4 routes mind you.  I don't know anything about IPv6 routing.  Each static route was for an individual IP address, with a Mask of 255.255.255.255, e.g.:

route add 10.20.30.40 mask 255.255.255.255 10.10.10.1 metric 2 if 12

where:

10.20.30.40 is the IP that we want the client to get to
10.10.10.1 is the gateway on the internal NIC of the DA server
12 is the interface number of the internal NIC of the DA server

After confirming the configuration via 'route print' and the routing table looking good, we tested 'ping' from a Windows 7 DA Client and it worked PROVIDED that we pinged either a Hostname or a Fully Qualified Domain Name.  Pinging plain IPv4 addresses did NOT work, but we kind of expected that.

We found that applications which needed to use these routes to communicate with servers on one of the non-main-LAN subnets could do so provided that those apps supported IPv6 connections; those which were IPv4 only (a few old apps) could not connect.  As an example, we tested connections from Trend Micro Antivirus client running on a DirectAccess Windows 7 Client and it could talk happily to the Trend AV server on a non-main-LAN subnet.

EDIT: one more comment ... we have NOT yet configured Manage Out fully, so I cannot yet ping the DA clients from inside my main LAN or any other subnet.

• Edited by 0499FROSTY Monday, March 24, 2014 2:57 AM

Can you reach the NLS site or server while you are in the LAN ?

First of all, if your DirectAccess server has two NICs - you definitely have a problem with the internal NIC having a default gateway. Even if it is not causing you a problem today, it could tomorrow. You absolutely need to change this.

Second, the particular problem with client computers showing "outside" when they are in fact inside indicates those clients (or more likely those subnets) don't have the ability to route to your NLS website. That is what you should check into. If you are hosting your NLS website on the DirectAccess server, you should also change that and offload it onto it's own server as a best practice.

I try not to be self-serving on the forums here, but the configurations that we are talking about here (and also the step-by-step configuration of manage-out) is all described in this book if you are ever interested: http://www.packtpub.com/microsoft-directaccess-best-practices-and-troubleshooting/book

And on the matter of your applications that only know how to talk IPv4, the company I work for has developed an agent that can resolve that and get those apps working over DirectAccess (for a lot of the apps we have encountered anyway) - here's a blog article about that if you want to check it over: http://www.ivonetworks.com/news/2013/05/ivo-networks-announces-app46-for-directaccess/