none
Direct Access NAT question/confusion

    質問

  • Forgive my confusion and ingnorance, but I'm hoping someone can shed some light on a Direct Access question for me.

    We are trying to deploy UAG Direct Access.  Our UAG server is not behind a firewall and has two consecutive public IP addresses.  We do not have IPv6 deployed on our private corporate network.  It is my understanding in the case that the UAG Direct Access server will do the NAT6to4 translation to allow our IPv4 servers to be available to our DA clients.  1.) Is this correct or am I completely off base?  2.) If I am correct, do we need to enable ISATAP in order to make this work?  I saw another post about the issues that ISATAP can cause and we ran into those issues on a previous attempt to deploy DA. 

    2012年2月9日 21:56

すべての返信

  • I install this exact scenario all the time. Yes it will work and no you do not need ISATAP at all to make it work. In your situation the only reason you might want to use ISATAP is if you need the ability to "manage out" to your DA client computers when they are outside the network. For example, if your internal helpdesk PCs need the ability to RDP into the DA clients when they are connected over DA, that is when you will need ISATAP.

    I recommend accomplishing your installation without any ISATAP to make sure that DA works, and then if you choose to look into ISATAP you can do so once your connectivity is established and confirmed.

    2012年2月9日 21:59
  • Thanks Jordan, that helps me think I am not going completely crazy.  We will go without the "manage out" option for now.  Does the NAT have to be configured in UAG or does it just work out of the box?  This does not seem like it should be so difficult, but has proven to be so far.
    2012年2月10日 15:55
  • There is nothing that you need to configure for NAT64/DNS64. UAG will setup everything that you need for the translations.
    2012年2月10日 20:45
  • Great, thanks.  We have everything setup, my DCA client shows that I am connected, but I am unable to access local resources.  I am connected via

    GREEN: Corporate connectivity is working correctly.
     
    15/2/2012 0:28:17 (UTC)


    Probes List
    PASS        PING: XX:eb14
    PASS        HTTP: http://test.company.com
    DTE List
    PASS        PING: xx:eb14
    PASS        PING: xx:eb13

    Tunnel adapter iphttpsinterface:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : iphttpsinterface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2002::ab3(Preferred)
       Temporary IPv6 Address. . . . . . : 2002::762b(Preferred)
       Link-local IPv6 Address . . . . . : fe80::95aa::ab3%21(Preferred)
       Default Gateway . . . . . . . . . : fe80::4560::71c6%21
       NetBIOS over Tcpip. . . . . . . . : Disabled

    C:\Windows\system32\LogSpace\{DC984393-1095-4846-905A-09960568BB6A}>netsh int teredo show state
    Teredo Parameters
    ---------------------------------------------
    Type                    : client
    Server Name             : 1.2.3.4 (Group Policy)
    Client Refresh Interval : 30 seconds
    Client Port             : unspecified
    State                   : probe (secondary server)
    Client Type             : teredo host-specific relay
    Network                 : unmanaged


    C:\Windows\system32\LogSpace\{DC984393-1095-4846-905A-09960568BB6A}>netsh int httpstunnel show interfaces

    Interface IPHTTPSInterface (Group Policy)  Parameters
    ------------------------------------------------------------
    Role                       : client
    URL                        : https://connect.company.com:443/IPHTTPS
    Last Error Code            : 0x0
    Interface Status           : IPHTTPS interface active

    C:\Windows\system32\LogSpace\{DC984393-1095-4846-905A-09960568BB6A}>netsh dns show state

    Name Resolution Policy Table Options
    --------------------------------------------------------------------

    Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                            if the name does not exist in DNS or
                                            if the DNS servers are unreachable
                                            when on a private network

    Query Resolution Behavior             : Resolve only IPv6 addresses for names

    Network Location Behavior             : Let Network ID determine when Direct
                                            Access settings are to be used

    Machine Location                      : Outside corporate network

    Direct Access Settings                : Configured and Enabled

    DNSSEC Settings                       : Not Configured

    What DNS servers will my client use when connected?  I only have DNS servers listed on my wireless interface, the IPHTTPS interface does not show anything.  And what does "resolve only IPv6 addresses for names" actually mean?  Does this mean I cannot resolve any names for servers with IPv4 addresses?

    Thanks

    Dave

    2012年2月17日 0:17
  • Appears I spoke to soon...

    RED: Corporate connectivity is not working.
    Windows is unable to contact some corporate content resources. Please contact your administrator if this problem persists.
    17/2/2012 0:20:41 (UTC)


    Probes List
    PASS        PING: 2002::eb14
    RESOLVED NAME    HTTP: http://test.company.com

    DTE List
    PASS        PING: 2002::eb14
    PASS        PING: 2002::eb13

    2012年2月17日 0:26
  • The "resolve only IPv6 addresses" is a normal setting, don't worry about that. The UAG is the DNS server being used (the DNS64 part if UAG actually). If you check the command netsh name show policy you should see the IP address being used for DNS on the DA connection.

    In the first message you posted it shows that IP-HTTPS is connected successfully, but you didn't include the same output in your second post. Can you provide the information as to whether Teredo and/or IP-HTTPS are making a connection like you did in your earlier post?

    I will say that usually if Teredo or IP-HTTPS are making a successful connection but DirectAccess is still not working, it typically means that there are no IPsec tunnels establishing themselves within the Teredo/IP-HTTPS tunnel, and the reason for that is almost always related to the machine certificate issued by your CA server. Can you confirm that you have a machine certificate issued to both the UAG server and the client machine that you are testing with?

    2012年2月17日 19:16