Application on DirectAccess clients cannot access IPv4 server outside our network RRS feed

  • Question

  • Here is the scenario I'm having issues with: DirectAccess clients have an application that needs to connect to a server outside our network, server/application that we have no controll over. That server does not accept connections from the internet, so the traffic from our DirectAccess clients for that application needs to come through our corporate network, then go out to that server. We don't have a DNS entry for that server in our DNS, but the name/IP resolves just fine from inside the network. From a DirectAccess client, the name resolves to an IPv6 address assigned by the UAG server. If I traceroute that server name from a DirectAccess client, the trace stops at the UAG server's tunnel adapter IPHHTTPSInterface IPv6 address. From the UAG server a traceroute works just fine.

    Any ideas what can I do for the application on the DirectAccess clients to connect to that server?



    • Edited by aburica Friday, March 2, 2012 3:46 PM
    Friday, March 2, 2012 3:44 PM

All replies

  • Hi

    So if i understand well you have a client-side application installed on DirectAccess enabled computers that must reach a server side by using specific IP addresses. and connection to this application are filtered by addresses.

    In this situation, you must create a DNS zone on your internal DNS and corresponding entries that point to the destination. Then you declare theses destination as exceptions in the NRPT table (from the UAG DirectAccess console). You will configure these exception to use DNS64 for resolution.

    On the client side, once GPO is applied, you should be able to resole DNS entry with IPv6 addresses. That the easy part. Now the hard one.

    If your application does not enforce IPv4 utilization, there is no problem. Otherwise :

    For TCP based applications i have this workaround :

    For UDP based applications, i have no other solution today that to use an additionnal VPN/SSL solution. Users will connect to DirectAccess and then connect the VPN/SSL to establish an IPv4 based connectivity. It is a bad workaround, but it works.

    I hope this help.

    BenoitS - Simple by Design

    Friday, March 2, 2012 4:59 PM
  • Hi BenoitS,

    Thank you for your response. Yest, this is the exact scenario. I already made the entry to the MRPT table and set it to use DNS64 for it. That's how I route the traffic for the application through the corporate network. On the DirectAccess client, a "netsh namespace show effectivepolicy" shows the entry.

    I assumed that adding a DNS zone would fix or at least would help in the resolving this issue. However, the idea of adding a new DNS zone just for this didn't go well for the "aproval" process. Out of our DirectAccess users, only 20 - 30 users are using this application.

    Is there any other way to do this name resolution to the IPv4 without creating a DNS zone for it?

    Thank you


    Friday, March 2, 2012 5:39 PM
  • Hi,

    The real problem is that your application filter access based on a set of IP addresses corresponding to your company. DirectAccess clients car try to reach the server side without going throught DirectAccess but connections would be rejected. There is no other solution than creating the DNS zone inside.

    BenoitS - Simple by Design

    Friday, March 2, 2012 8:46 PM
  • Hi,

    If the application is a webbased app you can create an entry in the NRPT that tunnels the website through a proxy server on your local network.

    It works just like a normal NRPT entry but the FQDN that you provide in the NRPT will be sent to the proxy server you define under "DirectAccessProxyName"

    After creating this entry you do not need to worry about the DA client being able to resolve the FQDN via the local network or via the DA tunnel. It will just pick up on the NRPT entry when you try to access the site and send it to the configured proxy server. Make sure that the proxy FQDN is an FQDN or domain that is listed in your NRPT to tunnel over DA.


    Saturday, March 17, 2012 9:18 AM