UAG DirectAccess: Force Tunneling for a Specific Hostname RRS feed

  • Question

  • There is probably a simple fix for this, but I just cant come up with it.

    What I did was create a hostname on the internal DNS server that points to an external IP address. What I want to do is force tunneling for that hostname so that any traffic from a DA client to the hostname goes out to the internet via the DA tunnels. Right now I have that hostname set in the NRPT to use DNS64 for resolution, but all that does is display an IPv6 address for that hostname to the client, and it does not resolve.

    Any suggestions?

    Saturday, December 31, 2011 9:44 AM

All replies

  • Hi and happy new year.


    You need to create an entrance in the NRPT for your host and reference your UAG DirectAccess IPv6, just like you will found ti by using NETSH.EXE NAMESPACE SHOW POLICY.


    Best regards.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Sunday, January 1, 2012 8:41 PM
  • Happy new year to you too!


    Anyway, that's what I did. Let me explain a little further what I am trying to accomplish:

    I added a zone to the DNS server on my domain controller, lets just call it xyz.com, and in that zone, i added a subdomain. Let's just call that sub.xyz.com. That A record points to an external IPv4 address that resolves correctly when I browse it on the domain controller.

    What i did was go back into the UAG DA configuration wizard under the Infastructure Servers and added *.xyz.com to the NRPT table with DNS resolving as DNS64. What this accomplished was correctly translate that external IPv4 address to an internal IPv6 address over the DA tunnel, but I am not able to browse the host over the DA connection like I am able to over the regular external IPv4 address.

    This may seem a little convoluted, but on the same network as the UAG server is a VPN tunnel that securely connects to an outside network. Applications that the DA clients need to use every day connect to the host sub.xyz.com and will only work if the traffic meant for that host goes out over that secure VPN tunnel.

    I hope that makes sense


    Thanks so much for your response!

    Sunday, January 1, 2012 9:10 PM
  • Hi,


    If you disable DirectAccess avec the DirectAccess Connectivity Assistant, this should work. Because you add the Subdomain in the NRPT, DNS64/NAT64 respond with an IPv6 address. Just create additional entries in the NRPT for each destination you mush reach in IPv4 (corporate web site, ...).


    Happy new year.

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Monday, January 2, 2012 10:07 AM
  • This is an interesting scenario. If I understand it correctly you do not need a way to disable this traffic from going through the DA tunnels but rather need a way for this traffic to flow through the DA tunnels and then from there through a VPN tunnel that is connected from the corporate network, correct?

    While I have never tried this exact scenario, the way you have it setup sounds correct. The problem may very well be routing related. Let's walk through it. When your DA client tries to contact server1.xyz.com it gets an IPv6 address back from DNS64 because you have added it to the NRPT and to your internal DNS, and the DA client sends its traffic to this IPv6 address. These packets are received by the DA server, and then tries to send them on to server1.xyz.com using the IPv4 address that you have configured in your internal DNS. At this point, what happens? Does the DA server have the ability to route successfully to the IPv4 address of server1? Let's say server1.xyz.com is - if the DA server does not have a route that tells it specifically how to get to, it will throw it at the Default Gateway which will send those packets back out the External NIC of the DA server. I assume the external NIC does not have the capability to flow traffic over this VPN tunnel, I would imaging you probably have to send traffic through the DA server's Internal NIC to get to the VPN tunnel?

    So, if there is not a route telling the DA server to send the VPN IP addresses through the internal NIC, that could explain it (or it could be something else altogether) :)

    Also keep in mind that when adding routes to the DA/UAG server, you not only add the route to the routing table but also re-run the Network Interfaces wizard inside UAG to mark that VPN network as part of your "trusted" Internal network.


    Tuesday, January 3, 2012 2:05 AM
  • Hi,

    Since you registered the external IPv4 addresses in your corp DNS, you need to use DNS64 and NAT64 in order to reach these servers from your DA client.

    NAT64 in TMG is configured by default to allow translated traffic to the internal interface.

    When force tunneling is enabled in the UAG DA wizard, it configures TMG to allow NAT64 on the external interface as well. (there are 2 settings for this, 1 is a system policy rule and the other is a NAT configuration)

    Changing those settings manually is of course, not officially supported.

    But I guess you can go ahead and give it a shot :)

    Just note that after activation your changes may be overwritten
    Tuesday, January 3, 2012 9:29 PM
  • By the way, a better way to implement this would be to add these hostnames to NRPT but with an internal proxy server.

    This can be done by manipulating the GPO Export script in the section that adds the NRPT entries.

    Tuesday, January 3, 2012 9:32 PM
  • Thanks so much for all your replies, you are really helping me to nail this down!

    Right now, they are operating by having a dedicated 2003 server that is only connected to a hardware firewall that is generating the VPN connection to the outside network. The outside network is secure and the only way for the clients to access it is via this one hardware firewall. The clients connect via a Windows configured VPN connection over PPTP to the RRAS service on that dedicated server. Configuring the VPN connection to use the RRAS server's DNS address allows the applications to work over that VPN connection. I am trying to replace that process above using DA. So, right now, the path of the packet is:

    Client computer --> PPTP VPN to RRAS server --> Hardware firewall --> VPN tunnel to outside network

    So, my understanding is that the path the packets have to take from the DA client to the VPN tunnel to work correctly is:

    DA client --> UAG server --> Domain controller/DNS server (on the same local LAN and subnet as the UAG server) --> Hardware firewall --> VPN tunnel to outside network

    After doing some consideration after reading your replies, I saw that while I was testing the connection, I had not set up the static routes to go through the domain controller, so it was going out over the default gateway and was being blocked by TMG. So, if I create a static route from UAG server to the domain controller, then from the domain controller to the hardware firewall, it should work, right?

    Wednesday, January 4, 2012 3:58 AM
  • Whenever you add a route to a UAG box you need to do two things. First is add the actual route into the routing table (usually with command prompt) and the second is re-run the Network Interfaces wizard that is available from inside the Admin menu of UAG. The second screen of the Network Interfaces wizard is where you define the scope of your Internal network, basically you are telling UAG what range of IP addresses you "trust" as your Internal network. You need to add the scope of the new route here. When you finish off this wizard, it injects those new addresses into the "Internal Network" definition of TMG which then allows it to be trusted and routable.

    However, in your case because the DC is on the same segment as the UAG server, it should have on-link routing capabilities already. Can you communicate to the DC from the UAG server and DirectAccess clients already? If so, then you do not need to add a route for the DC. However, you may have to add a route for the subnet and IP ranges of this VPN connection that you are flowing to if the UAG server does not know how to route there.

    Wednesday, January 4, 2012 11:45 AM