locked
Debugging or fixing UAG with DirectAccess with Ipv6 RRS feed

  • Question

  • Hey all, we've just finished setting up DirectAccess UAG on our network, but can't seem to get it to work... and have no idea how to figure out what is wrong - I think it may be related to DNS queries but it may just aswell be something else entirely. Making everything harder is that fact that we are using proper IPv4 and IPv6 networks all around (no NAT).

    (in my examples I'll be replacing parts of the IP addresses - I apologize for this getting long - but I believe I have to be thorough in my description here... it's complicated stuff :D)

    Internal-client network: 1.1.62.0/C - 2001:DEAD:1::/64
    Internal-server network: 1.1.80.0/C - 2001:DEAD:0:80::/64
    External-internet: 1.1.30.0/C   - 2001:DEAD:0:30::/64

    The Forefront UAG server setup

    Internal-NIC

     

    *  IPv4 1.1.62.234
    *  No default GW
    *  DNS points to DC1 at 1.1.80.241 and DC2 at 1.1.80.242

    *  IPv6 2001:DEAD:1:0:1:1:62:234
    *  No default GW
    *  DNS points to DC1 at 2001:DEAD:0:80:1:1:80:241 and DC2 at 2001:DEAD:0:80:1:1:80:242

    Static routes implemented using the internal interface number to the 1.1.80.0/C subnet which works, the UAG1 server can ping/resolve DC1 using both IPv4 and IPv6

     

    External-NIC

     

    *  IPv4 1.1.30.121
    *  IPv4 1.1.30.122
    *  Default GW: 1.1.30.1
    *  DNS points to DC1 at 1.1.80.241 and DC2 at 1.1.80.242

    *  IPv6 2001:DEAD:0:30:1:1:30:121
    *  IPv6 2001:DEAD:0:30:1:1:30:122
    *  Default GW: 2001:DEAD:0:30:1::1
    *  DNS points to DC1 at 2001:DEAD:0:80:1:1:80:241 and DC2 at 2001:DEAD:0:80:1:1:80:242

    Static routes implemented to the 2001:DEAD:0:80::/64 subnet (gateway 2001:DEAD:1::1 i.e. the internal-nic's gw) which works, the UAG1 server can ping/resolve DC1 using IPv6.

    UAG-GPO's are configured using correct certificates and properly distributed to the client.

    UAG-Server configuration is configured using the first internet facing IPv4 address 1.1.30.121. ISATAP is "non-functional" (and not in DNS) and the internal IPv6 address is 2001:DEAD:1:0:1:1:62:234

    The correct IP-HTTPS certificate is selected and for IPv6 prefixes we have:

    Organization prefixes: 2001:DEAD:1::/48 and 2001:DEAD:0:80::/64
    IPHTTPS prefixes are: 2001:DEAD:1:FEED::/64
    IPv4 only prefixes are: 2001:DEAD:1:DEAD::/96 

    ... and the correct IPsec certificat authentication is set.

    Applying this policy results in no errors, with just a warning that some subnets are missing static routes. (Internal network 2001:DEAD:1:1::-2001:DEAD:1:ffff:ffff:ffff:ffff:ffff is not routed, and not in use todays setting)

    The Client setting

    The client is ofcourse a Windows 7 SP1 x64 machine, member of the domain, and of the DA_Clients security group that we deployed the GPO's for. I've tried following the Microsoft TestLabGuide_TroubleshootUAG_DA to figure this out.

    On the corpnet

    Running netsh dnsclient show state tells me it knows it's Inside corporate network. The netsh namespace show policy displays what looks correct, using the DirectAccess (DNS Servers) of 2002:0101:1e7a::0101:1e7a (i.e. the second address of the External-NIC on the UAG server). It differs a bit from the testlab guides but this is because we have real IPv6 both inside and outside.

    netsh namespace show effectivepolicy tells me:

     

    DNS Effective Name Resolution Policy Table Settings
    
    Note: DirectAccess settings would be turned off when computer is inside corporate network
    

     

    Which is as it should be. I can also resolve and ping DC1 and APP1 (NLS server) using both IPv6 and IPv4 with no problems.

    Problems occur once I move on to the public IPv6 enabled internet outside our corpnet.

    On the IPv6 Internet

    First thing I do is ipconfig /flushdns before checking with netsh dnsclient show state and netsh namespace show effectivepolicy. The first command tells me that I am indeed Outside corporate network as it can't reach our NLS server. The latter command now tells me it's using 2002:0101:1e7a::0101:1e7a for DA DNS. Firewall settings also look ok. And netsh interface 6to4 show relay tells me it's going to use the 1.1.30.121 as it's relay (delivered by Group Policy).

    Using ipconfig I can see that the Tunnel adapter 6TO4 Adapter has DNS servers and a default gateway of 2002:0101:1e79::0101:1e79 (i.e. the first address of the External-nic).

    I was now under the impression that a ping dc1.corpnet.company.com or ping app1.corpnet.company.com would establish connection but it does not. Using the test lab guide I try figure out why I can not resolve intranet FQDNs.

    So I bring up netsh namespace show effective and find the address listed in NRPT which is 2002:0101:1e7a::0101:1e7a. The troubleshooter step-by-step says I'm supposed to ping this address and get a successful response... which I do not. So I fail at step 2, which shouldn't be a possibility.

    I tried doing a wireshark capture on the CLIENT1 machine to see what's going on, but I'm afraid my networking mojo is not quite up to the standards. What I DO see is the 6TO4 adapters IP trying to connect to the DNS server using ISAKMP without getting any replies before proceeding on to trying isatap.myisp.com which won't resolve using DNS either.

    So any ideas? Tips on where to look? 

     

    Tuesday, December 13, 2011 2:47 PM

All replies

  • Oh dear, UAG DirectAccess doesn't support using native IPv6 on the outside :(

    http://blogs.technet.com/b/tomshinder/archive/2011/03/23/uag-directaccess-and-the-ipv6-internet.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, December 13, 2011 4:19 PM
  • Hm, I may be reading that differently but I read it as it won't work if the client is on a IPv6 network only...? That is not our case, as we are still dual stack (everywhere). However, the documentation also says to NOT disable IPv6 - so with that in mind it's pretty "impossible" to not have an external interface with IPv6 in our setup.

    (This is the Higher Education and Research Internet which mostly is IPv6 everywhere now...)

    Tuesday, December 13, 2011 6:14 PM
  • Hi,

     

    Jason is right. Today, DirectAccess only rely on IPv6 transition technologies on the Internet-side. I've tested for a customer of mine, DirectAccess always required two IPv4 public addresses. Native IPv6 unicast address is not already supported. I did not tested in Windows 8 but it might be tha same for multiple reasons.

     

    Best regards.


    BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx
    Tuesday, December 13, 2011 6:36 PM
  • So I took the CLIENT pc with me home today, and just maybe our "external Internet" at work weren't external enough - or maybe it's because everything downtown is IPv6 enabled. I'm getting some different behaviour at home which is a pure IPv4 network (and different from that again from my neighbours network).

    On the home IPv4 net

    CLIENT is still confirmed to be outside the corporate network and using 6to4. I am able to ping the 6to4 default gateway of 2002:0101:1e79::0101:1e79. If I try to ping dc1.corpnet.company.com it resolves to the "proper" IPv6 address (?!!) which would be 2001:DEAD:0:80:1:1:80:241. It resolves, but does not answer the ping... looking through the wireshark capture I see traffic from the "home" 2002:: address (my home network uses official IPv4, no NAT) going to the 2002:0101:1e79::0101:1e79 and 2002:0101:1e7a::0101:1e7a addresses (using ESP and ISAKMP). I also see traffic going directly to the official IPv6 address of DC1 at 2001:DEAD:0:80:1:1:80:241 but of course no replies.

    On the home IPv4 NAT net

    CLIENT is still confirmed to be outside, but no 6to4. I guess it's using teredo at this point, and netsh int teredo show state claims it's "qualified" and that NAT is "restricted". Trying ping dc1.corpnet.company.com resolves the address properly, but gets no replies. Again looking at wireshark I see some traffic from 2001:0:... to 2001:DEAD:0:80:1:1:80:241 using Teredo of the type Direct IPv6 Connectivity Test. There's also some ESP traffic going between the client's 2001:0:... address and the UAGs external 2002:0101:1e7a::0101:1e7a address. But again no ping replies, and not netbios replies if I try a net view \\dc1. That just results in error 53.

    Edit:

    I managed to "find" the web monitor on Forefront UAG and I can "Infrastructure access" and "Intranet access" from the CLIENT popping up in the DA Monitor active sessions. It lists "blank" for certificate though, which I find odd seeing as apparently the certificate settings on the domain seem ok. (CA is signing certificates left and right, they all trust the CA, the UAG server has it's certificats and the client likewise...)

    Could this be a case of stuff on the inside not finding it's way BACK to the UAG internal network interface? How can I properly debug this? Is okay for me to install wireshark on the UAG server??

    • Edited by gojensen Tuesday, December 13, 2011 7:24 PM more info!
    Tuesday, December 13, 2011 6:45 PM
  • Hi gojensen,

    Install DCA then run Advanced Diags and provide a sanitised version of the output here.

    In the meantime, you may also want to use these to learn about troubleshooting DA:

    http://blogs.technet.com/b/tomshinder/archive/2011/04/19/ipv6-and-directaccess-troubleshooting-cheat-sheets.aspx

    http://www.microsoft.com/download/en/details.aspx?id=23453

    Cheers

    JJ

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, December 13, 2011 8:51 PM
  • Sorry, just saw your edit...yes IPv4 and IPv6 routing are often key to solving these types of issues. See a recent problem here: http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/5bf69555-c6be-4db1-9846-7a128a784765/

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, December 13, 2011 8:53 PM
  • Hey Jason, thanks for the follow ups and suggestions. It seems a bit random to me right now - maybe I messed something up - and it's getting a bit late. :) I'll look into those links and indeed the DCA tomorrow. Getting a bit stressed though as this must be up and running no later than the 21st :D

    I'll also have another chat with the router people at work about this...

    Thanks again!

     

    Tuesday, December 13, 2011 10:02 PM
  • Well, we decided to redo the setup... we're moving the UAG internal to a dedicated link/router subnet and making the appropriate IPv6 prefixes for the IPHTTPS and 6to4 connections and setting up static IPv6 routing. In the meantime though,

    I've been trying to read about this on the "Assigning IP addresses to the server interfaces" page at technet (http://technet.microsoft.com/en-us/library/dd857322.aspx) and it doesn't to cover anything with regards to the EXTERNAL interface...

    should we give it "proper" (i.e. static) IPv6 addresses aswell as IPv4 addresses,

    should it just use "dynamic addresses", 

    somehow disable IPv6 on the external interface?

    Any info appreciated :D

    I also think I messed something up yesterday, as at one point I could do nslookup -q=aaaa dc1 2002... but then it started saying Unknown error or something. So we're wiping the UAG config and reconfiguring it later this evening.

    I'm also baffled about how the clients would reach IPv4 only internal servers (it's got something to do with NAT64 and DNS64 but I'm not sure how it works, what addresses the server sees from the client and wheter or not we would need ISATAP for this functionality...)

    Any further tips and pointers are most welcome...

    Wednesday, December 14, 2011 1:23 PM
  • Hi,

    IPv6 should be enabled on the external interfaces, but don't assign addresses. You can configure IPv6 addressing on your internal interfaces.

    These guides might be useful:

    http://social.technet.microsoft.com/wiki/contents/articles/recommended-network-adapter-configuration-for-forefront-uag-servers.aspx

    http://technet.microsoft.com/en-us/library/gg502574.aspx

    I am guessing as you have dual-stack, you won't even be looking at ISATAP - probably a good thing ;)

    As you have found IPv4 and IPv6 routing is very important to the overall solution; as is the 'Internal Network' definition in UAG/TMG.

    NAT64 is just using a specific IPv6 prefix and then generates "fake" IPv6 host addresses, then translates these fake address into into IPv4 (ISATAP is not relevant here). DNS64 also provide a complimentary service to ensure IPv4 resources are returned as "fake" IPv6 addresses that NAT64 will understand. Have a read of these: http://blogs.technet.com/b/edgeaccessblog/archive/2009/08/27/deep-dive-into-directaccess-part-2.aspx and http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, December 14, 2011 2:29 PM
  • So we've got most of it working now... routing seems to have been one of the major issues aswell as local firewalls on some servers (that got me stumped a bit). My test has been from a public IPv6 network, later to night I'll test 6to4 and Teredo - need to go home for that :D

    One issue is still unresolved, and that is DNS 6to4... (i.e. reaching IPv4 only internal hosts)

    When I ping an IPv4 only host I get an IPv6 address from my range 2001:DEAD:1:DEAD::0a0a:0a0a (i.e. 10.10.10.10). However I can get no ICMP replies or i.e. http traffic through from the IPv4 only host.

    And I'm thinking maybe I've misunderstood the routing bit for this prefix...

    Our IPv6 routers are set to forward 2001:DEAD:1:DEAD to the INTERNAL interface of the UAG server... is this correct?! Or are these addresses never seen outside the UAG and it's client? From the deep dive stuff it looks like only the client know about this address which it sends to the UAG server which then goes into IPv4 mode internally.

    If so, anyway to test/debug this? (All my router guys have gone home for the day :D)

    Anyways, looking into the TMG logging on the UAG server I can see that I get an ICMPv6 Echo from the Client to the NAT64 address of the IPv4-only host. However it's denied with status "the network rules do not allow the connection requested" and no rule (just "see Result Code"). It seems to me that TMG thinks this network is also EXTERNAL? (Source EXTERNAL, Destination EXTERNAL) ...?

    Thursday, December 15, 2011 3:55 PM
  • It sounds like you've got some of your IPv4 static routes on the UAG servers wrong and/or you have not defined the "Internal Network" object correctly within UAG/TMG. Both of your UAG/TMG network adapters need to be on different networks and you then define the routing and Internal Network object accordingly. In addition to my links above, this may be worth a read too: http://blog.msedge.org.uk/2010/04/threat-management-gateway-tmg.html

    And no, for NAT64 you don't need to worry about IPv6 routing; once decapsulated at UAG, everything is then in the IPv4 domain so you just need to consider IPv4 routing at that point. The prefix is just kinda fake and only really used for clients inbound (because DA clients only ever use IPv6 to UAG).

    Be aware that for teredo to work you need to receive ICMPv6/ICMPv4 responses from your internal hosts, which are sometimes blocked by host or internal firewalls...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, December 15, 2011 4:31 PM
  • Hi again Jason,

    first I'd just like to say thank you! It's so great to have someone give advice, point one in the right directions and be willing to look into issues like this. Maybe one won't get the whole complete solution, but sometimes just talking about stuff helps :) So Thanks!

    Anyhoo... I tested this at home and Teredo tunnels work fine... 6TO4 tunnels not so much (i.e. from public IPv4 addresses). I do belive I've heard that protocol 41 (6to4) is blocked in large parts of our national network so I'll have to look into this with the security and router people tomorrow as I think maybe that's the problem. (I can ping the 2002: DNS address, but DNS queries times out, pings go unanswered etc.)

    I'm also afraid that some IPv4 traffic TO the Internal UAG interface is being blocked internally by our firewalls (we have soooo many subnets, with firewalls between them, that I loose track...) since our UAG is now on it's own little subnet instead of directly on the client network. Doing ping to IPv4 hosts only seems to never get any traffic back into the UAG. More meat for the security people :D

    So to sum up:

    Public IPv6 network - works 90%, can reach all IPv6 addresses, but no IPv4 addresses
    Private IPv6 network - unknown (don't know where I can find such a thing :D, guessing it would work?)

    Public IPv4 network - works not at all (traffic to Internal UAG interface being blocked?)
    Private IPv4 network (RFC1918) -  works 90%, can reach all IPv6 addresses, but no IPv4 addresses

    I think once I've got this working 100% I'll need to write a short document :D I know there are many that are looking at exactly the same setups that we have here now. Maybe I can something back to the community ;)

    Thursday, December 15, 2011 10:09 PM
  • No problem, I like a challenge! ;)

    Keep working at it; when you get it working, DA is a thing of beauty :)

    It would be interesting to see you document your progress and findings; it would make a good case study for others...

    Cheers

    JJ

    P.S. I tend to disable 6to4 on DA clients as it often causes more problems than it solves.


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, December 15, 2011 11:48 PM
  • Sigh :P

    I need to check something with you,

    the NAT64 and IPHTTPS prefix'es for IPv6 are supposed to be routed internally to the INTERNAL CORPNET interface right?

    Should I also route 2001::/32 (Teredo) to the INTERNAL CORPNET interface?

    Should I also route 2002::/16 (6to4) to the INTERNAL CORPNET interface?

    I'm seeing odd behaviour right now, and I think the system is using the external 6to4 "routers" it finds via the 192.88.99.1 anycast address - and I think one of those is broke (because it worked earlier today and then stopped)

    I had to resort to installing netmon on the client and UAG server to figure out what really happens. As I hinted at last time, protocol 41 is indeed blocked in large parts of the internet meaning that 6to4 probably won't work.

    I tried establishing client connection from IPv4 network to an IPv4 only host today, and now in the TMG log I see the client address 2001:DEAD:1:DEAD:4:4:XXXX:XXXX spamming unidentified traffic (Raw 44:0) to destination 2001:DEAD:0:100::1e which is a router in another part of the country. TMG/UAG says the destination address does not exist on the system and no forwarding interface exists. This I find really odd since there's a default route 00::/1 to handle stuff like this right? (The UAG server can ping that ::1e address from the command prompt but apparently doesn't know how to route it...)

    Same thing if I try to ping another Ipv4 only host... i.e.

    > ping ipv4only

    Pinging ipv4only.corp.domain.net [2001:dead:1:dead:4:4:0101:b414] with 32 bytes of data:
    Request timed out. 
    Request timed out.
    Request timed out.
    Request timed out.

    In the TMG firewall log I see 

    <client-ipv4-addr> - <UAGexternal-ipv4> - IPv6 over IPv4 Tunnel - initiated
    <client-6to4-addr> - <ipv4only-addr> - ICMPv6 Echo - initiated 
    <ipv4-nat64-addr> - <client-ipv4-addr> - Unidentified IP Traffic (Raw 44:) - denied

    So I'm getting a response from the  2001:dead:1:dead:4:4:0101:b414 address which I believed only to exist between the UAG and CLIENT addressed TO the 2002:something::something 6TO4 address of the remote client, and it's unidentified and gets dropped.

    Looking at the netmonitor, this seems to be an ICMP echo reply which doesn't get sent out again... And I've spent way too much time on this today (again :D) and I need to go home and feed my kid... :D

     

    Friday, December 16, 2011 4:07 PM
  • I tend to disable 6to4 on DA clients as it often causes more problems than it solves.

    We can do that? How? And what ramifications does it have? (And will we still be able to reach IPv4 ONLY servers on the inside?)

     

    Friday, December 16, 2011 4:08 PM
  • This is driving me crazy :) and I now have only 2 or maybe 3 days to get it to work...

    Seems to me that both 6to4 and Teredo relies on "anycast" servers "out there" to find their way home and unfortunately there seems to be a few misconfigured boxes/routers.

    If I disable 6to4, Teredo takes over... Teredo however insists on sending me to miredo.surfnet.nl which somehow just resolves the ip address and forwards it to our gateway (instead of the UAG server).

    Disabling Teredo forces IPHTTPS to take... and just as I type this ofcourse it gets active instead of disabled. So that's something atleast. IPHTTPS from my public IPv4 network works for the moment... but I understand that we should try to get the other two working - as they are faster and/or secure(?).

    And I'm still unable to reach IPv4 only servers... but I believe that to be "router" related aswell...

    I also found a post suggesting looking at the certificates on the client, specifically to look for the DA1/UAG1 certificates... however I've found no such thing on my clients (??!) (accessing https://da1:443/IPHTTPS yields no errors, only a server refusal to show me the page (403)).

    The Active Sessions of the UAG Webmonitor also claims that my infrastructures did not present a certificate... but I do have auto-enrollment enabled in the domain... (and all clients I've tested have a computer certificate installed...)

    I guess though I've been running up so many trees now that I may be seeing problems everywhere... :D


    • Edited by gojensen Friday, December 16, 2011 11:29 PM
    Friday, December 16, 2011 10:05 PM
  • So it seems that almost all my problems were router and filter related.

    I'll someday in the not too distant future summarize everything, but...

    6to4 is useless for us (protocol 41 is filtered too many places)

    We've got Teredo and IPHTTPS working fine for internal resources, still some hiccups reaching external resources that shares the same domain. 

    Wednesday, December 21, 2011 10:22 PM
  • We had similiar issues where I work with 6to4, we eventually used GPO to disable it and rely purely on teredo and IPHTTPS.

    As Jason says above, DA is a thing of beauty once it works.

    Thursday, December 22, 2011 3:25 PM
  • So it seems that almost all my problems were router and filter related.

    I'll someday in the not too distant future summarize everything, but...

    6to4 is useless for us (protocol 41 is filtered too many places)

    We've got Teredo and IPHTTPS working fine for internal resources, still some hiccups reaching external resources that shares the same domain. 


    Good news...thanks for the updating the thread...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, December 23, 2011 12:13 PM
  • We had similiar issues where I work with 6to4, we eventually used GPO to disable it and rely purely on teredo and IPHTTPS.

    As Jason says above, DA is a thing of beauty once it works.


    Yeah, I tend to disable it by default on my deployments now...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, December 23, 2011 12:13 PM