none
DirectAccess (UAG SP1) connectivity problems when trying to access NAT64/DNS64 resources over teredo. RRS feed

  • Question

  • I recently configured DirectAccess with UAG SP1 and now I have an issue i can't seem to solve. DA over IPHTTPS works perfectly and i can reach all corporate internal resources, but when using teredo i can't reach any resources with a NAT64/DNS64 address (2002:WWXX:YYZZ:8001). Resources with AAAA records in DNS are reachable using teredo. I have tried all of the connection troubleshooting guides i could find, but none of them pointed to anything that worked.

    I can ping my DA server both IPv4 and IPv6 and from the DA server i can ping the IPv4 adres of the internal resource. I cannot ping and access the internal resource from my DA client. I hope anybody has an idea where I did something wrong.

    Saturday, December 17, 2011 10:16 PM

All replies

  • I've captured a network trace on the target server when I was pinging it and i noticed that my ping request arrived at the server and the reply is send back to the UAG server. The UAG server receives the ping reply but somehow it doesn't get send back to the client. Anyone any idea what the issue is and/or where i can look for more clues?
    Tuesday, December 20, 2011 9:58 PM
  • Hi Amig@. Have tou configured rules in advanced firewall for allowing ICMPv4/v6 Excho Requests?

    http://technet.microsoft.com/en-us/library/ee382272(WS.10).aspx

    Regards


    // Raúl - I love this game
    • Proposed as answer by RMoros Tuesday, January 10, 2012 2:41 PM
    • Unproposed as answer by VirtualRJ Thursday, January 12, 2012 9:38 AM
    Friday, December 23, 2011 9:26 AM
  • Thanks for the tip. Although i didn't configure the rule even after configuring it still didn't work. I was hopeful at first, because I received replies, but that was the initial stage where it would first connect over IPHTTPS. As soon as teredo kicks in I lose connection to the internal resources.
    Thursday, January 12, 2012 9:46 AM
  • Hi again. Can you check the status of the Teredo interface at the client?
    // Raúl - I love this game
    Thursday, January 12, 2012 2:32 PM
  • I hope you mean the following part. If you need any other information just let me know.

     

    ***************************************************************************
    netsh int teredo show state
    ***************************************************************************
    Microsoft Windows [versie 6.1.7601]
    Copyright (c) 2009 Microsoft Corporation. Alle rechten voorbehouden.
    
    C:\Windows\system32\LogSpace\{0DDB4098-CAE1-425A-8776-EABD2D93EFC6}>netsh int teredo show state
    Teredo-parameters
    ---------------------------------------------
    Type                             : client
    Servernaam                       : <IPv4 address DA-server> (Group Policy) 
    Vernieuwingsinterval voor clients: 30 seconden
    Clientpoort             : unspecified
    Status                   : qualified
    Type client             : teredo client
    Netwerk                 : unmanaged
    NAT                     : restricted
    NAT Speciaal gedrag   : UPNP: Nee, PortPreserving: Nee
    Lokale toewijzing           : <local IPv4 address>:57133
    Externe NAT-toewijzing    : <external IPv4 address>:49921


    • Edited by VirtualRJ Thursday, January 12, 2012 10:19 PM
    Thursday, January 12, 2012 10:19 PM
  • Yes, that is. So it seems that the Teredo interface is successfully connected. When you ping the name of an IPv4 internal server, do you get an IPv6 address for the name?


    // Raúl - I love this game
    Friday, January 13, 2012 12:47 PM
  • When i ping an IPv4 internal server (no AAAA host in DNS) it translates to:

    2002:xxyy:wwzz:8001::<hex representation of local IPv4 address>
    Result: Time-out

    When I ping an IPv4/IPv6 internal server (both A and AAAA record in DNS) it translates to:

    2002:xxyy:wwzz:8000:0:5efe:<local IPv4 address>
    Result: Ping replies

    Friday, January 13, 2012 1:23 PM
  • Were you already using IPv6 internally before using UAG DirectAccess?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, January 13, 2012 2:14 PM
    Moderator
  • At least not conciously. It appeared on the network when moving towards Windows 7 and 2008 (R2). When we installed UAG DirectAccess I configured the necessary components (e.g UAG, ISATAP).
    Friday, January 13, 2012 2:21 PM
  • Ok I think i figured out why this is happening, but I don't know why and also don't have a solution yet. Maybe someone can point me in the right direction. I checked the IPv6 routing tables from a non-functioning server against a functioning server and noticed that some routes are missing in the non functioning server.
    Non functioning server:
    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
      1    306 ::1/128                  On-link
     12    266 2002:xxyy:wwzz::/64      fe80::5efe:<IPv4 ISATAP>
     12     18 2002:xxyy:wwzz:8000::/49 On-link
     12    266 2002:xxyy:wwzz:8000::/49 fe80::5efe:<IPv4 ISATAP>
     12     18 2002:xxyy:wwzz:8000::/64 On-link
     12    266 2002:xxyy:wwzz:8000::/64 fe80::5efe:<IPv4 ISATAP>
     12    266 2002:xxyy:wwzz:8000:0:5efe:<IPv4 server>/128
                                        On-link
     12    266 2002:xxyy:wwzz:8100::/64 fe80::5efe:<IPv4 ISATAP>
     12    266 2002:xxyy:wwzz::/64      fe80::5efe:<IPv4 ISATAP>
     11    266 fe80::/64                On-link
     11    266 fe80::10b6:85b5:c243:c0d1/128
                                        On-link
      1    306 ff00::/8                 On-link
     11    266 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None
    Functioning server:
    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
     12    266 ::/0                     fe80::5efe:<IPv4 ISATAP>
      1    306 ::1/128                  On-link
     12   4106 2002::/16                fe80::5efe:<IPv4 ISATAP>
     12    266 2002:xxyy:wwzz::/64      fe80::5efe:<IPv4 ISATAP>
     12     18 2002:xxyy:wwzz:8000::/49 On-link
     12    266 2002:xxyy:wwzz:8000::/49 fe80::5efe:<IPv4 ISATAP>
     12     18 2002:xxyy:wwzz:8000::/64 On-link
     12    266 2002:xxyy:wwzz:8000::/64 fe80::5efe:<IPv4 ISATAP>
     12    266 2002:xxyy:wwzz:8000:0:5efe:<IPv4 Server>/128
                                        On-link
     12    266 2002:xxyy:wwzz:8100::/64 fe80::5efe:<IPv4 ISATAP>
     12    266 2002:xxyy:wwzz::/64      fe80::5efe:<IPv4 ISATAP>
     11    266 fe80::/64                On-link
     12    266 fe80::5efe:<IPv4 Server>/128
                                        On-link
     11    266 fe80::edf0:2a1b:f231:e34f/128
                                        On-link
      1    306 ff00::/8                 On-link
     11    266 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None



    • Edited by VirtualRJ Friday, January 13, 2012 11:18 PM
    Friday, January 13, 2012 11:17 PM
  • The IPv6 servers are using ISATAP to reply but the IPv4 servers have to reply to an IPv4 address so the routes are different. The "ping" to IPv4 servers will have the UAG's internal IPv4 address. Can you ping from UAG to the non-answering IPv4 servers? Maybe ICMP is filtered out along the path.
    // Raúl - I love this game
    Monday, January 16, 2012 4:29 PM
  • Hi VirtualRJ,

    Your routing table actually does hold the answer to the issue.

    You can see that both servers have duplicate route entries for 2002:xxyy:wwzz:8000::/49. One is on-link, and the other points to the other server's ISATAP link local address.

    This is bad, since NAT64 traffic which is inside this prefix (2002:xxyy:wwzz:8001::) - and the route should only be on-link.

    The root cause of this problem is that you have 2 DirectAccess servers, and you enabled ISATAP.

    It is unsupported to deploy more than 1 UAG DirectAccess server in an ISATAP deployment, so you should either remove one server, or remove ISATAP from the DNS and use only DNS64/NAT64.

    After you do that, restart the servers and check if the route table is fixed and if DNS64/NAT64 is now working.

    By the way, DirectAccess feature in Windows 8 will fully support the multi-site scenario. So if 2 servers are a requirement for you, you can pick up the Developer Preview and give it a go.

    Monday, January 16, 2012 5:00 PM
  • The IPv6 servers are using ISATAP to reply but the IPv4 servers have to reply to an IPv4 address so the routes are different. The "ping" to IPv4 servers will have the UAG's internal IPv4 address. Can you ping from UAG to the non-answering IPv4 servers? Maybe ICMP is filtered out along the path.
    // Raúl - I love this game

    I can ping the IPv4 from the UAG to the non-answering server.
    Monday, January 16, 2012 5:35 PM
  • Hi VirtualRJ,

    Your routing table actually does hold the answer to the issue.

    You can see that both servers have duplicate route entries for 2002:xxyy:wwzz:8000::/49. One is on-link, and the other points to the other server's ISATAP link local address.

    This is bad, since NAT64 traffic which is inside this prefix (2002:xxyy:wwzz:8001::) - and the route should only be on-link.

    The root cause of this problem is that you have 2 DirectAccess servers, and you enabled ISATAP.

    It is unsupported to deploy more than 1 UAG DirectAccess server in an ISATAP deployment, so you should either remove one server, or remove ISATAP from the DNS and use only DNS64/NAT64.

    After you do that, restart the servers and check if the route table is fixed and if DNS64/NAT64 is now working.

    By the way, DirectAccess feature in Windows 8 will fully support the multi-site scenario. So if 2 servers are a requirement for you, you can pick up the Developer Preview and give it a go.

    Thanks for your input, but I don't have 2 DA/UAG servers. The routing info provided above is from two internal servers.

    To try something I have deleted the ISATAP in DNS and restarted both the non functioning and functioning server. The routing tables cleaned up nicely (see result below), but it didn't fix it. I still cannot contact the internal servers over DNS64/NAT64 and now after disabling ISATAP also not anymore by their 2002:wwxx:yyzz:8000 addresses.

     

    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
      1    306 ::1/128                  On-link
     11    266 fe80::/64                On-link
     11    266 fe80::10b6:85b5:c243:c0d1/128
                                        On-link
      1    306 ff00::/8                 On-link
     11    266 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None

     

    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
      1    306 ::1/128                  On-link
     11    266 fe80::/64                On-link
     11    266 fe80::edf0:2a1b:f231:e34f/128
                                        On-link
      1    306 ff00::/8                 On-link
     11    266 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None

    Monday, January 16, 2012 5:46 PM
  • Oh, I see.

    So if we saw these duplicate routes on the internal servers, it must mean that the UAG DirectAccess is publishing these routes on 2 different interfaces (instead of just 1).

    I have seen this problem a few times, but I'm still not sure what is the root cause.

    To verify this, please run "netsh int ipv6 show route" on the UAG DA server, and check if you see the route 2002:xxyy:wwzz:8000::/49 on more than one ISATAP interface.

    If so, do the following steps to fix the problem:

    1.  Use "route delete" in order to delete all persistent routes on the ISATAP interfaces

    2.  On Device Manager, under View menu, select Show hidden devices. Now expand Network Adapters, and select and uninstall all ISATAP interfaces

    3.  Reactivate UAG, so it will reinstall ISATAP and recreate the routes on the correct interface. (Make sure DirectAccess is also activated, and you don't get a "no changes in DirectAccess configuration" message during activation)

    Now there should no longer be duplicate routes on the UAG DirectAccess server. This should also fix the DNS64 NAT64 issue.

    Also, you can re-register ISATAP in the DNS.

     

    Monday, January 16, 2012 7:25 PM
  • Ok i followed your steps, but it effectively has broken UAG/DA. Couldn't activate because of missing ISATAP adapters. Runned repair on UAG. Couldn't activate on 6to4 adapter. Deleted all network interfaces in device manager linked to UAG (IPHTTPS/6to4/Teredo/ISATAP) and ran another repair. Now i could activate the config and all the routing tables looked better and cleaner both on the UAG server and the internal server.

    Sadly it has broken all access to the internal network. I can now ping the servers i could ping before (2002:wwxx:yyzz:8000 on the 2008R2 servers and 2002:wwxx:yyzz:8001 on the 2003 servers) and still can not ping the 2002:wwxx:yyzz:8001 addresses of the 2008(R2) servers. But i can't access any of the servers i could before. Net view says error 53 (cannot find network path) and also other operations on the servers fail.

    So the routing tables look good and clean, but i've lost more functionality.

     

    Tuesday, January 17, 2012 1:11 PM
  • I'm sorry to hear.

    Can you share with us the new routing configuration on the UAG server (netsh int ipv6 show route).

    Can you ping resources over DA by their names or only their IP addresses?

    Tuesday, January 17, 2012 2:41 PM
  • I can ping the resources by their names. So i guess DNS/DNS64 is working.
    Output from netsh int ipv6 show route on the UAG server:
     
    Publish  Type      Met  Prefix                    Idx  Gateway/Interface Name
    -------  --------  ---  ------------------------  ---  ------------------------
    Yes      Manual    1100  ::/0                       17  2002:c058:6301::c058:6301
    No       Manual    256  ::1/128                     1  Loopback Pseudo-Interface 1
    No       Manual    8    2001::/32                  14  Teredo Tunneling Pseudo-Interface
    Yes      Manual    1000  2002::/16                  17  6TO4 Adapter
    Yes      Manual    256  2002:wwxx:yyzz::/64        17  6TO4 Adapter
    No       Manual    256  2002:wwxx:yyzz::wwxx:yyzz/128   17  6TO4 Adapter
    Yes      Manual    256  2002:wwxx:yyzz:8000::/49   19  isatap.{C2BDBF9F-E93E-4AD1-B8A6-91A58C607AD8}
    Yes      Manual    256  2002:wwxx:yyzz:8000::/64   19  isatap.{C2BDBF9F-E93E-4AD1-B8A6-91A58C607AD8}
    No       Manual    256  2002:wwxx:yyzz:8000::/128   19  isatap.{C2BDBF9F-E93E-4AD1-B8A6-91A58C607AD8}
    No       Manual    256  2002:wwxx:yyzz:8000:0:5efe:<LAN IPv4 Address>/128   19  isatap.{C2BDBF9F-E93E-4AD1-B8A6-91A58C607AD8}
    No       Manual    256  2002:wwxx:yyzz:8001::/96   19  isatap.{C2BDBF9F-E93E-4AD1-B8A6-91A58C607AD8}
    Yes      Manual    256  2002:wwxx:yyzz:8100::/64   15  IPHTTPSInterface
    No       Manual    256  2002:wwxx:yyzz:8100::/128   15  IPHTTPSInterface
    No       Manual    256  2002:wwxx:yyzz:8100:4857:fad5:8277:13d6/128   15  IPHTTPSInterface
    Yes      Manual    256  2002:wwxx:yyaa::/64        17  6TO4 Adapter
    No       Manual    256  2002:wwxx:yyaa::wwxx:yyaa/128   17  6TO4 Adapter
    No       Manual    256  fe80::/64                  11  LAN
    No       Manual    256  fe80::/64                  12  WAN
    No       Manual    256  fe80::/64                  14  Teredo Tunneling Pseudo-Interface
    No       Manual    256  fe80::/64                  15  IPHTTPSInterface
    No       Manual    256  fe80::5efe:<LAN IPv4 Address>/128   19  isatap.{C2BDBF9F-E93E-4AD1-B8A6-91A58C607AD8}
    No       Manual    256  fe80::200:5efe:<WAN1 IPv4 Address>/128   16  isatap.{798D3956-BFD7-44B0-8C39-9CD612DBA135}
    No       Manual    256  fe80::200:5efe:<WAN2 IPv4 Address>/128   16  isatap.{798D3956-BFD7-44B0-8C39-9CD612DBA135}
    No       Manual    256  fe80::d50:dd4:3a55:3251/128   12  WAN
    No       Manual    256  fe80::2cb0:4600:d006:2934/128   11  LAN
    No       Manual    256  fe80::4857:fad5:8277:13d6/128   15  IPHTTPSInterface
    No       Manual    256  fe80::8000:f227:3fa8:9bb6/128   14  Teredo Tunneling Pseudo-Interface
    No       Manual    256  ff00::/8                    1  Loopback Pseudo-Interface 1
    No       Manual    256  ff00::/8                   15  IPHTTPSInterface
    No       Manual    256  ff00::/8                   14  Teredo Tunneling Pseudo-Interface
    No       Manual    256  ff00::/8                   11  LAN
    No       Manual    256  ff00::/8                   12  WAN
     

    • Edited by VirtualRJ Tuesday, January 17, 2012 3:04 PM
    Tuesday, January 17, 2012 3:03 PM
  • The route table looks good, and IPsec seems to work.

    Perhaps connectivity doesn't work because you can't access the domain controllers to get a kerberos ticket.

    Can you check whether the domain controller has an ISATAP address or not, if not, is it still registered in the DNS with its ISATAP address?

     

    Tuesday, January 17, 2012 3:13 PM
  • The domain controllers have got an ISATAP address. And it's probably true that I can't get a kerberos ticket because I can ping the DC's, but can't access them (HTTP,Net view, etc.).
    Tuesday, January 17, 2012 3:20 PM
  • I just looked in the Web Monitor and it said that my client certificate was not provided. Maybe some other issue has turned up now. Will investigate why the certificate isn't good anymore. It certainly explains why i have no access over both Teredo and IPHTTPS.

    Tuesday, January 17, 2012 3:30 PM
  • But if there's a problem with the certificate then name resolution from the client over DA shouldn't work, as it requires IPsec as well
    Tuesday, January 17, 2012 3:32 PM
  • Ok, so that's strange.

    Checked computer certificates -> they all look OK.

    Checked Advanced Firewall Config -> Main mode only shows two listings. Both are NTLMv2. So no more kerberos.

    Tuesday, January 17, 2012 3:39 PM
  • I'd suggest to first try to make the deployment work perfectly without ISATAP.

    If end-to-end IPv6 connectivity is required (Manage-Out, additional end-to-end authentication), then you can enable ISATAP later.

    To do that, you can remove the ISATAP record from the DNS. It should take up-to 24 hours until all servers will "refresh" and remove their ISATAP addresses.

    Tuesday, January 17, 2012 3:45 PM
  • Removed ISATAP and restarted the servers. Reinstalled UAG because the symptoms matched the information in this thread (http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/thread/6c2b72a1-bda2-47fc-8f78-8d79dc1ce2ca). And now i'm back to the original situation, but without ISATAP.

    Testing i've done so far:

    Teredo

    As expected every name resolution returns the 2002:wwxx:yyzz:8001::<hex IPv4>.

    I can resolve and access every 2003R2 server.

    I can resolve but NOT access any 2008(R2) servers.

    IPHTTPS

    Everything works as expected. Everything is accessable.

    Tuesday, January 17, 2012 11:00 PM
  • Now that's strange...

    Do you have any 3rd party firewalls installed?

    Can you check TMG's alerts for anything out of the ordinary?

    Do you see the NAT'ed IPv4 packets reaching the 2008(R2) server? Are there any IPv4 replies back to the UAG server? (where is the traffic dropped)
    Wednesday, January 18, 2012 10:02 PM
  • Now that's strange...

    Do you have any 3rd party firewalls installed?

    The UAG server is directly connected to the internet.

    Can you check TMG's alerts for anything out of the ordinary?

    TMG has no special error alerts or anything else that triggers "Eureka".

    Do you see the NAT'ed IPv4 packets reaching the 2008(R2) server? Are there any IPv4 replies back to the UAG server? (where is the traffic dropped)

    I see no traffic arriving at the internal (infrastructure) server. Except for ping requests and replies, which i can relate to the client trying to contact the server, because i also see them in the TMG logging.

     

    During some other investigations why I could get Kerberos authentication, resulted in a find that one of the domain controllers had the ISATAP state enabled. When I set this to default i lost my Kerberos main mode and also any other connectivity that i had to 2003R2 servers.


    • Edited by VirtualRJ Friday, January 20, 2012 8:00 AM
    Friday, January 20, 2012 8:00 AM
  • I had this and bugged me for about a month.

    I had a GPO that setup firewall rules. included in those rules were core networking rules.

    This meant on the client they had 2 of each Core Networking rule.

    Therefore when I removed the rules out of GPO it fixed it because the clients used the right firewall rule to setup the connection and present the certificate.

    Hope this helps

    Wednesday, February 8, 2012 2:33 PM