Let DA clients access resources on the external DMZ subnet through UAG DA? RRS feed

  • Question

  • So, we basically got UAG DA to work using Teredo and IPHTTPS.

    UAG is connected to the "outside" at our DMZ and most servers are on the inside HOME network.

    The problem is... SOME "semi-public" servers are connected to the same subnet as the UAG external interface (the DMZ). This causes... problems.

    From what I can see traffic arrives at the UAGDA server, it then tries to send this to the "external" webserver on it's local external network... but it uses a 6to4 source address (the 2002:...) and tries to communicate using ISAKMP with the servers. Of course, our LDAP and WEB servers don't like/understand this and we get no proper response from them.

    I can't route this traffic through the internal interface to our router (since it's "on-link") so is there anything I can do in TMG/UAG to make it understand this?

    My solution so far has been to make a new DMZ zone and move the UAG there, but this is a proper waste of IPv4 network addresses and subnetting. (Basically a pain we'd like to avoid).

    Any tips appreciated...

    Tuesday, December 20, 2011 10:12 PM

All replies

  • Hi,


    The first condition to use DirectAccess tunnels is to resolve an internal DNS name. If you configure external interfaces with a public DNS name that is not covered by the NRPT, you can be sure that you will not use DirectAccess tunnels to reach these ressources. 

    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Wednesday, December 21, 2011 7:58 AM
  • Uhm, so... we need two domain names?

    From what I've read of the DA docs and your comment, you'd want us to use internal.domain.net for everything on the "inside" and "just" domain.net for stuff on the outside?

    Thing is (we have a big network) ... we have both internal and external resources that share the domain.net domain name. The NRPT has excludes for UAG1.domain.net and covers both internal.domain.net and domain.net.

    However I don't think DNS/NRPT is the issue here. Consider this case:

    All networks have IPv6 but for simplicity sake I'll only list IPv4 networks here... External "internet" side of our network:

    uses / C (let's call this A)
    has UAG1 ( and
    has WWW1 ( 

    Internal side of our network:

    uses / C (let's call this B)
    has all kinds of windows servers. 

    So we have this situation:

    DAclient -> internet -> router -> Network A -> UAG server -> Network B

    So the DAclient can access everything on the internt OK. It can also access everything on the internal Network B just fine. It can not however access stuff on Network A like the WWW1 server all the time. Funny thing, sometimes it works, sometimes it don't...!


    Wednesday, December 21, 2011 10:50 PM
  • Hi,

    BenoitS is right, and this is just a NRPT configuration issue.

    Since DirectAccess clients can't reach IPv4 resources ( in your example), they have to translate servers on network A to IPv6 addresses using DNS64. If the DNS name for these servers is not found in NRPT, then clients will not attempt to translate the address to IPv6 using DNS64, and will instead send a DNS query for that name to the public DNS servers on the internet.

    I'm assuming these servers are reachable from the public internet and you do not need to be connected to the corporate network in order to reach them. is that correct?

    So in order to configure NRPT to exempt these servers, you have to create exemptions entries in NRPT. You can do this even if you don't have separate domain suffixes for external and internal. Read about split brain DNS configuration here:


    Once this is fixed, the DirectAccess client will try to reach these servers using their public IPv4/IPv6 addresses, instead of their internal addresses; so you also need to make sure that the public IPv6 addresses are not included in the Corporate IPv6 prefix you configured in DirectAccess, otherwise the traffic will be tunneled using IPsec to the DirectAccess server.

    Tuesday, December 27, 2011 11:12 PM