Even though many of the blogs I've read on UAG DA SP1 say that we can safely do split tunneling with DA Clients, our security group has requested that we block split-tunneling. I see that I can force-tunneling ... which uses IP-HTTPS for the tunnel while client is on internet.

The question has come up on how to disable Direct Access services so the client can use their local home network for 'local' work. And when they need to connect to the corporate network, they can re-enabe Direct Access services....which blocks split-tunnel.

You can install the DCA client and allow users to enable the Use local DNS resolution option; for a more brutal approach, you can stop the IP Helper service...

Cheers

JJ

Once you install the client you will have to configure it also. In step 1 of the DA setup you need to click on the optional Setting:Client Connectivity Assistant. Then on the Client Connectivity page of the wizard you need to check the box for "Allow users to use local name resolutions instead of sending request through corporate DNS servers"

Thanks for the quick replies gents ... So as I understand things so far, to make Direct Access work, I don't actually need the DCA client. And all my DA Clients will be configured for Direct Access once they receive the UAG DA GPOs. But for this additional manageability and to kill the tunnel as needed, this DCA client will do the trick. Do I have this right?

@Troy ... "Allowing users to use local name resolutions...." is only for when they are not DA connected?

Yes you have it correct. No you don't have to have DCA for DA to work.

Allowing users to use local name resolutions...." lets you turn DA off. It will make it so that the DCA client have a new option. You right click the icon in the system tray and it will let you use local DNS. That turns DA off.

• Edited by Troyd Sanchez Tuesday, March 13, 2012 1:07 PM

Yes you have it correct. No you don't have to have DCA for DA to work.

Allowing users to use local name resolutions...." lets you turn DA off. It will make it so that the DCA client have a new option. You right click the icon in the system tray and it will let you use local DNS. That turns DA off.

• Edited by Troyd Sanchez Tuesday, March 13, 2012 1:07 PM

Yes you have it correct. No you don't have to have DCA for DA to work.

Allowing users to use local name resolutions...." lets you turn DA off. It will make it so that the DCA client have a new option. You right click the icon in the system tray and it will let you use local DNS. That turns DA off.

• Edited by Troyd Sanchez Tuesday, March 13, 2012 1:07 PM

Yes you have it correct. No you don't have to have DCA for DA to work.

Allowing users to use local name resolutions...." lets you turn DA off. It will make it so that the DCA client have a new option. You right click the icon in the system tray and it will let you use local DNS. That turns DA off.

• Edited by Troyd Sanchez Tuesday, March 13, 2012 1:07 PM

Yes you have it correct. No you don't have to have DCA for DA to work.

Allowing users to use local name resolutions...." lets you turn DA off. It will make it so that the DCA client have a new option. You right click the icon in the system tray and it will let you use local DNS. That turns DA off.

• Edited by Troyd Sanchez Tuesday, March 13, 2012 1:07 PM

Actually, I am pretty sure that when you select the Force Tunneling option you lose the ability to provide the users with the "Prefer Local DNS Names" option. Giving them that option would defeat your purpose of enabling Force Tunneling in the first place.

Don't give up on split tunneling just yet - Split tunneling in DirectAccess doesn't mean the same thing that it used to with VPN: http://www.ivonetworks.com/news/2011/05/why-split-tunneling-with-directaccess-is-not-only-for-thrillseekers/

Jordan thanks for the additional info. Makes sense .... can't use Local DNS with force tunnel in place.

I wonder if Microsoft or any of their partners have demonstrated that ... even if the remote DA client at coffee shop got hijaked from a bridged connection within the coffee shop from another machine ... they cannot access the corporate network? Or maybe other UAG DA users out there have security shops that have put this to the test? I think demonstrating the inability to hijak the connection is the only way our security group will buy in to the possibility of split-tunneling.

Thanks for the suggestion of stopping IP Helper. Was at a customer site where offline DA clients didn't get a Gpo update after the IP addresses of the Network Access Locator servers changed during a datacenter move. DA got confused and effectively started blocking normal internal network traffic. Killing IP Helper broke DA long enough for a gpupdate /force to take effect and update the policies.

Is there a way to temporarily disable direct acces to prefer local names like in the DCA for Windows 7?

I have a problem where I need to update a DA clients group policy to get a new DC IP, but alas the client can't find the DC whether I'm stopping the IP helper service or not.

Server 2012 DA has the same option in it's wizards, inside Step 1, to allow the clients the ability to temporarily disable DA name resolution. This does in Windows 8 the same thing that the DCA option did for Windows 7 clients. When this option is enabled, you can click on the NCA and then click on "Disconnect"

If your NLS website is working properly, you shouldn't ever have to do this though. When DA clients validate the NLS website, their NRPT gets turned off automatically. Just wanted to make sure you knew that since you didn't reference NLS at all in your post.

Thanks, well, yeah it's kinda weird. I had a fully working DA setup, single nic behind firewall with kerberos proxy. Then I changed IP:s on my internal servers, including the DC. Everything internally was working but DA wouldn't connect. Checked the remote server and I had forgotten to change the DNS entry on the DA-servers nic, changed to the new IP, updated the config and everything is fine and dandy on the server side (everything is green in the dashboard and operation status).

Connected the client to the LAN to update the GPO to get the new dnsaddress, can't connect to the DC. I check "netsh dns show state" which says I'm "Outside corporate network". I try resolve som host names (not fqdn), responds with link local addresses. Try pinging fqdn, ping request could not find host. I try pinging the registered nls url, responds with the correct ipv4 address, ie dns resolved.

So I'm in the situation where nsl is working, the computer still have the NRPT active and redirects all non exempt dns resolutions to the not working ipv6 dns-server address.

Now I checked the selfsigned cert on the nls-server (same as the DA-server) which has the DA-servers external fqdn as subject (ie not the nls url), and isn't in the clients trusted root cert store. This doesn't seem correct. But since I'm using kerberos authentication instead of certificates maybe the nls cert subject/trust is not important?

And, I haven't touched the cert on the DA/NLS server so it ought to be the same cert from when everything worked.

• Edited by Molotch Tuesday, October 29, 2013 9:34 PM

Thanks, well, yeah it's kinda weird. I had a fully working DA setup, single nic behind firewall with kerberos proxy. Then I changed IP:s on my internal servers, including the DC. Everything internally was working but DA wouldn't connect. Checked the remote server and I had forgotten to change the DNS entry on the DA-servers nic, changed to the new IP, updated the config and everything is fine and dandy on the server side (everything is green in the dashboard and operation status).

Connected the client to the LAN to update the GPO to get the new dnsaddress, can't connect to the DC. I check "netsh dns show state" which says I'm "Outside corporate network". I try resolve som host names (not fqdn), responds with link local addresses. Try pinging fqdn, ping request could not find host. I try pinging the registered nls url, responds with the correct ipv4 address, ie dns resolved.

So I'm in the situation where nsl is working, the computer still have the NRPT active and redirects all non exempt dns resolutions to the not working ipv6 dns-server address.

Now I checked the selfsigned cert on the nls-server (same as the DA-server) which has the DA-servers external fqdn as subject (ie not the nls url), and isn't in the clients trusted root cert store. This doesn't seem correct. But since I'm using kerberos authentication instead of certificates maybe the nls cert subject/trust is not important?

And, I haven't touched the cert on the DA/NLS server so it ought to be the same cert from when everything worked.

• Edited by Molotch Tuesday, October 29, 2013 9:34 PM

Thanks, well, yeah it's kinda weird. I had a fully working DA setup, single nic behind firewall with kerberos proxy. Then I changed IP:s on my internal servers, including the DC. Everything internally was working but DA wouldn't connect. Checked the remote server and I had forgotten to change the DNS entry on the DA-servers nic, changed to the new IP, updated the config and everything is fine and dandy on the server side (everything is green in the dashboard and operation status).

Connected the client to the LAN to update the GPO to get the new dnsaddress, can't connect to the DC. I check "netsh dns show state" which says I'm "Outside corporate network". I try resolve som host names (not fqdn), responds with link local addresses. Try pinging fqdn, ping request could not find host. I try pinging the registered nls url, responds with the correct ipv4 address, ie dns resolved.

So I'm in the situation where nsl is working, the computer still have the NRPT active and redirects all non exempt dns resolutions to the not working ipv6 dns-server address.

Now I checked the selfsigned cert on the nls-server (same as the DA-server) which has the DA-servers external fqdn as subject (ie not the nls url), and isn't in the clients trusted root cert store. This doesn't seem correct. But since I'm using kerberos authentication instead of certificates maybe the nls cert subject/trust is not important?

And, I haven't touched the cert on the DA/NLS server so it ought to be the same cert from when everything worked.

• Edited by Molotch Tuesday, October 29, 2013 9:34 PM

Thanks, well, yeah it's kinda weird. I had a fully working DA setup, single nic behind firewall with kerberos proxy. Then I changed IP:s on my internal servers, including the DC. Everything internally was working but DA wouldn't connect. Checked the remote server and I had forgotten to change the DNS entry on the DA-servers nic, changed to the new IP, updated the config and everything is fine and dandy on the server side (everything is green in the dashboard and operation status).

Connected the client to the LAN to update the GPO to get the new dnsaddress, can't connect to the DC. I check "netsh dns show state" which says I'm "Outside corporate network". I try resolve som host names (not fqdn), responds with link local addresses. Try pinging fqdn, ping request could not find host. I try pinging the registered nls url, responds with the correct ipv4 address, ie dns resolved.

So I'm in the situation where nsl is working, the computer still have the NRPT active and redirects all non exempt dns resolutions to the not working ipv6 dns-server address.

Now I checked the selfsigned cert on the nls-server (same as the DA-server) which has the DA-servers external fqdn as subject (ie not the nls url), and isn't in the clients trusted root cert store. This doesn't seem correct. But since I'm using kerberos authentication instead of certificates maybe the nls cert subject/trust is not important?

And, I haven't touched the cert on the DA/NLS server so it ought to be the same cert from when everything worked.

• Edited by Molotch Tuesday, October 29, 2013 9:34 PM

Thanks, well, yeah it's kinda weird. I had a fully working DA setup, single nic behind firewall with kerberos proxy. Then I changed IP:s on my internal servers, including the DC. Everything internally was working but DA wouldn't connect. Checked the remote server and I had forgotten to change the DNS entry on the DA-servers nic, changed to the new IP, updated the config and everything is fine and dandy on the server side (everything is green in the dashboard and operation status).

Connected the client to the LAN to update the GPO to get the new dnsaddress, can't connect to the DC. I check "netsh dns show state" which says I'm "Outside corporate network". I try resolve som host names (not fqdn), responds with link local addresses. Try pinging fqdn, ping request could not find host. I try pinging the registered nls url, responds with the correct ipv4 address, ie dns resolved.

So I'm in the situation where nsl is working, the computer still have the NRPT active and redirects all non exempt dns resolutions to the not working ipv6 dns-server address.

Now I checked the selfsigned cert on the nls-server (same as the DA-server) which has the DA-servers external fqdn as subject (ie not the nls url), and isn't in the clients trusted root cert store. This doesn't seem correct. But since I'm using kerberos authentication instead of certificates maybe the nls cert subject/trust is not important?

And, I haven't touched the cert on the DA/NLS server so it ought to be the same cert from when everything worked.

• Edited by Molotch Tuesday, October 29, 2013 9:34 PM

I think I solved it. The other day when I rebooted my hyper-v host the DC ended up in the saved state instead of running (even though it has start action running). So when I noticed I simply started it and thought that be that.

My hypothesis is the Edge server never ran the NLA again once the DC was up and running again (atleast not after I changed the DNS settings) and the firewall was stuck in the Public profile. Which in some way shape or form blocks Kerberos authentication and fails the NLS check (ie if you use Kerberos authentication the certificate on the NLS server can be untrusted and have the wrong hostname).

Thank you for making me check the NLS endpoint.

HI, can u tell me that your Direct access client is now able to do the following tasks:

1. can able to access file server or NAS drive

2. Can able to access shared folder, after sharing it from any system of internal network

3. Can able to ping IPv4

This easiest way is the IP Helper Service. Stopping it will stop DirectAccess without playing with any other setting.

You can have a group policy that disabled it when out of corpnet by maybe checking the NLS and then enabling the service back when being able to access the NLS server (Back in the corporate network)

I'm currently working on a DA setup for POC on a domain network and implementation behind a NAT. As of now I have the DA solution working, however there are a few issues that you have to look at..

1. split tunnell vs force tunnell, force tunnell requires ipv6 inside the domain to work, in short if you have OCS 2007r2 and office 2010 for outlook it will not work. ocs requires ipv4, so update to a link server and move to office 2013.

a. the split tunnell works with the DA clients because the OCS and email are internet aware, so they do work.

Anyone have any better luck?

Hi,

OCS/Lync 2010 have the same problem. When client communication reach the OCS / Lync infrastructure, packet source appear to be different than what was recorded by the protocol. To avoid such problem, we must rely on a Edge configuration. Problem, Edge will be located on Internet so incompatible with Force Tunneling.

Situation changed with Lync 2013 as it fully support IPv6. Even if it's working, it's not recommanded because of multiple encapsulation mechanism that reduce the size of the payload. It may interfer with Audio / Video quality.

I can assure you that the DirectAccess server is doing plenty of validation. :)To establish DirectAccess connectivity the vpn client is authenticated using its Active Directory computer account (NTLM) along with its machine certificate for the first tunnel. The second tunnel is authenticated using the computer account (NTLM) along with the user account (Kerberos). As for block list functionality, you are right, there isnt any. To be fair, however, I dont recall seeing this feature on another other remote access solution either (Cisco, Checkpoint, Juniper, etc.).

VPN Client: http://www.expressvpnreviewz.com/