locked
UAG DirectAccess and Linux based Bind DNS RRS feed

  • Question

  • I would like to deploy a UAG DirectAccess solution.  I am in an ugly position were I am forced to use a BIND DNS which is configured to forwards SRV requests to our windows DNS server.  With that said, has anyone been sucessful with setting up DirectAccess with Bind DNS or is it even possible?  Can this solution be done without dynamic registration of A records?  Thanks in advance for your input and insight. 

    BJ


    • Edited by bjhoudini Sunday, July 22, 2012 6:09 AM typo
    Sunday, July 22, 2012 6:05 AM

Answers

  • Hi,

    I have used BIND as a relay server without any problems.
    The case most similar to your setup is a setup where internal AAAA records had to be blocked to force NAT64/DNS64. The only downside of that setup was that I had to block all AAAA records in the BIND setup and therefore couldn't get dynamic registration of the clients hostname when connecting over DirectAccess.

    Couldn't understand your last question/comment, do you want dynamic registration in the internal DNS for DirectAccess clients or not?
    Either way should work fine, all depends on how the DNS servers are setup.

    What you do to get it setup is simply configure the UAG servers to use the *NIX machine as their DNS server...
    (If you want to see the syntax for filtering the AAAA records in BIND, I did a short summary of that setup at http://blog.nrpt.se/forcing-nat64dns64-directaccess-clients/ )

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Sunday, July 22, 2012 9:16 AM
    • Marked as answer by bjhoudini Monday, July 23, 2012 2:04 PM
    Sunday, July 22, 2012 7:27 AM
  • Hi again,

    There's a big difference between 6to4 and NAT64/DNS64.
    The first one is a tunneling technique that the client can use to connect to the corporate network.
    The second combination is how clients can access IPv4-only resources within the corporate network.

    You won't have to do anything regarding these things, the DNS64 service will automatically convert internal IPv4 addresses internally to IPv6 addresses externally that the client will send to the corporate network and which will then be NAT'ed to look like they come from the internal IPV4 address of the UAG server.

    If the clients don't register their hostname and IPv6 address in the internal DNS you won't be able to perform certain functions.. but for your example, SCCM and packet distribution will work when it is client initiated.
    You will not be able to centrally force a pushout of a program though, since SCCM tries to connect to the client name..

    Another note, for SCCM (or any other system) to be able to connect to the clients, it needs to have some kind of IPv6 address (ISATAP, Native)..

    So it is of course best to have the clients register their names in the internal DNS but most of the things will still work.. there might be a delay when you send out a package to a client but often this is not a top priority and will often take a long time anyway since they're probably on a relatively slow link.

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Marked as answer by bjhoudini Monday, July 23, 2012 2:05 PM
    Sunday, July 22, 2012 9:16 AM
  • No problem, glad to be able to help.

    Sadly you cannot assign static IPv6 addresses to DirectAccess clients, the addresses differ between different Tunneling techniques and the last 64 bits are automatically generated.

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Marked as answer by bjhoudini Monday, July 23, 2012 2:05 PM
    Monday, July 23, 2012 9:56 AM

All replies

  • Hi,

    I have used BIND as a relay server without any problems.
    The case most similar to your setup is a setup where internal AAAA records had to be blocked to force NAT64/DNS64. The only downside of that setup was that I had to block all AAAA records in the BIND setup and therefore couldn't get dynamic registration of the clients hostname when connecting over DirectAccess.

    Couldn't understand your last question/comment, do you want dynamic registration in the internal DNS for DirectAccess clients or not?
    Either way should work fine, all depends on how the DNS servers are setup.

    What you do to get it setup is simply configure the UAG servers to use the *NIX machine as their DNS server...
    (If you want to see the syntax for filtering the AAAA records in BIND, I did a short summary of that setup at http://blog.nrpt.se/forcing-nat64dns64-directaccess-clients/ )

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Sunday, July 22, 2012 9:16 AM
    • Marked as answer by bjhoudini Monday, July 23, 2012 2:04 PM
    Sunday, July 22, 2012 7:27 AM
  • Jonas,

    Thank you for your answers and the link! Your input was very helpful.

    With regard to forcing 6to4, do you have to allocate an IP range within DNS that the UAG server would assign to a DA client, I guess much like the configuration you would employ for ISA or TMG in the case of VPN.

    With this solution in place will I be able to initiate communication from the internal network to the DA client? Another way to ask this question is dynamic registration of the client host name necessary for internal network to DA client communication?  As and example, I would like to use SCCM to push packages to a DA client.

    Thanks again

    Sunday, July 22, 2012 8:51 AM
  • Hi again,

    There's a big difference between 6to4 and NAT64/DNS64.
    The first one is a tunneling technique that the client can use to connect to the corporate network.
    The second combination is how clients can access IPv4-only resources within the corporate network.

    You won't have to do anything regarding these things, the DNS64 service will automatically convert internal IPv4 addresses internally to IPv6 addresses externally that the client will send to the corporate network and which will then be NAT'ed to look like they come from the internal IPV4 address of the UAG server.

    If the clients don't register their hostname and IPv6 address in the internal DNS you won't be able to perform certain functions.. but for your example, SCCM and packet distribution will work when it is client initiated.
    You will not be able to centrally force a pushout of a program though, since SCCM tries to connect to the client name..

    Another note, for SCCM (or any other system) to be able to connect to the clients, it needs to have some kind of IPv6 address (ISATAP, Native)..

    So it is of course best to have the clients register their names in the internal DNS but most of the things will still work.. there might be a delay when you send out a package to a client but often this is not a top priority and will often take a long time anyway since they're probably on a relatively slow link.

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Marked as answer by bjhoudini Monday, July 23, 2012 2:05 PM
    Sunday, July 22, 2012 9:16 AM
  • Thanks again Jonas.

    I do have a silly follow up question, I am just not yet familiar with IPv6 and how this protocol works within UAG.  Would it be conceivable to manually create an AAAA record within DNS in lieu of DDNS?  I as because I am not sure if ISATAP/Native/etc IPv6 IPs are statically or dynamically created within the juggernaut of UAG DirectAccess networking.   If this is possible, which IPv6 address would be necessary for the DA Client and the UAG server?

    Thanks again. 

    Monday, July 23, 2012 7:38 AM
  • No problem, glad to be able to help.

    Sadly you cannot assign static IPv6 addresses to DirectAccess clients, the addresses differ between different Tunneling techniques and the last 64 bits are automatically generated.

    Best wishes,
    Jonas Blom


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Marked as answer by bjhoudini Monday, July 23, 2012 2:05 PM
    Monday, July 23, 2012 9:56 AM
  • Thank you Jonas.  You have been very helpful.  I really appreciate your time. 
    Monday, July 23, 2012 2:07 PM