none
DirectAccess on native IPv6 - routing problem RRS feed

  • Question

  • Hello,

    I have deployed DirectAccess in Native IPv6 environment.

    Clients receive IPHTTPS IPv6 address from the IPv6 address space I have provided on our /48 prefix for DA Clients in DirectAccess Wizard. I can also ping IPv6 IPHTTPS gateway on DirectAccess client. But if I try to ping any other intranet IPv6 address I get Destination unreachable.

    I believe that DirectAccess doesn't work because of the routing problem which happens because of our IPv6 infrastructure. We have a single IPv6 /48 prefix so that means that on DirectAccess Server, both LAN and WAN interfaces have /64 IPv6 addresses from different /64 subnet but still both from the same /48 IPv6 subnet and I believe this confuses the routing.

    Any idea how should I diagnose the problem and how should I fix it?

    Thank you!

    Best wishes,
    Marko

    Sunday, August 1, 2010 10:44 AM

Answers

All replies

  • Hi,

    Do you mean that you have 2 different internal interfaces on your UAG DirectAccess server?

    This isn't a supported configuration. You should use 1 internal interface, and connect it to a next hop router that can be connected to both the LAN and WAN.

    Also make sure you have the proper routes on your UAG server ( a /48 prefix pointing to that next hop router), and also make sure there is a route back to DirectAccess clients from the WAN and LAN (::/0 - Native IPv6 clients, 2002::/16 - 6to4 clients, 2001::/32 teredo clients, and the prefix you selected for IP-HTTPS for the IP-HTTPS clients)

    Sunday, August 1, 2010 11:56 AM
  • Hello,

    no, I have one intranet and one internet interface on the server. I don't use UAG, just DirectAccess on Windows Server 2008 R2.

    But because organization has Native IPv6 both interfaces have IPv6 address from the same /48 subnet. So I can't just create /48 default route on DirectAccess server, because part of this subnet is actually on internet interface.

    Thank you!

    Best wishes,
    Marko

     

    Sunday, August 1, 2010 12:14 PM
  • I understand.

    Usually organizations buy a larger prefix and use one /48 subnet for internal and another for external.

    If you used UAG DirectAccess, you could specify several smaller subnets for your organization, so that it will represent only the internal IPv6 "cloud".

    However, since you're using Windows DirectAccess, you should create routes specific to the internal IPv6 cloud on the server and make them point to the internal router. As for the external interface, you should make sure there is a default IPv6 route pointing to the router on the internet side.

    You still need to make sure that the internal network has routes back to the DirectAccess clients through the DA server.

    By the way, there is a different technet forum for DirectAccess on Windows Server 2008 R2.

    This is the UAG forum

    • Proposed as answer by Marko Z Monday, August 2, 2010 3:06 PM
    Sunday, August 1, 2010 12:33 PM
  • Hello,

    Thank you for your answer. Maybe the problem is really in routing back to the DA clients. I will try to fix this. So if I understand you correctly, I need to add a static route for DA clients IPv6 address space on the internal router to point to the DA server?

    Thank you!

    Best wishes,
    Marko

    Sunday, August 1, 2010 12:37 PM
  • Exactly
    Sunday, August 1, 2010 12:48 PM
  • Hello,

    your solution did the job :)

    One more question. Is it possible to use DHCP server to assign IPv6 addresses and other DHCP options to clients? This would be great because then DA clients become Native IPv6 capable :)

    Thank you!

    Best wishes,
    Marko

    Sunday, August 1, 2010 7:56 PM
  • I do not recommend using DHCPv6. IPv6 has its own addressing protocol, and DHCP is not required at all.

    To create IPv6 addresses on your organization, you should configure IPv6 routers to advertise an IPv6 prefix to the hosts on their link.

    However, not this nor DHCP will give you native IPv6 for DA clients. The DA clients are on the internet, and because of this, they can't access your internal IPv6 routers or DHCP. To access the internal network, they already need IPv6 (for DirectAccess).

    Monday, August 2, 2010 8:11 AM
  • Hello,

    your solution did the job :)

    One more question. Is it possible to use DHCP server to assign IPv6 addresses and other DHCP options to clients? This would be great because then DA clients become Native IPv6 capable :)

    Thank you!

    Best wishes,
    Marko


    Hi Marko,

    As Yaniv pointed out, the IPv6 address assigned to the DirectAccess clients will be done automatically without using DHCP.

    What DHCP options would you like to deliver to your DirectAccess clients?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, August 2, 2010 2:59 PM
    Moderator
  • Hello,

    Yes, I agree that router advertisement is there for serving IPv6 addresses, but the problem is with DNS servers and other DHCP options. And for this thing DHCP is still the best way. I have tried accessing external IPv6 internet resources on DA clients after I have deployed DirectAccess in Native environment and clients and after adding default IPv6 route to use our internal network plus manually entering IPv6 DNS server names, clients were able to connect to IPv6 world without any problem. I would now just like to add DHCP server to server DA clients if it is possible so that I don't need to manually configure DNS servers and static route on clients. Also, if there would be DHCP server for DA clients it would be easier to detect which clients are connected and what IP address do they have.

    But if it is not possible no problem, all I needed to do was to implement DA, this is just a bonus configuration :)

    Thank you!

    Best wishes,
    Marko

    Monday, August 2, 2010 3:06 PM
  • Hi Marko,

    Ah, OK, I see what you mean.

    The UAG DA server is going to define what DNS servers the DirectAccess clients use. This is part of the NRPT configuration. If you're not using DNS64, you can configure the NRPT to assign other DNS servers that aren't the DNS64 proxy on the UAG DirectAccess server. So that part will give you control over the DNS servers used to resolve names for hosts accessed over the DirectAccess tunnels.

    The DirectAccess client will use the DNS server configured on the client's NIC for resources that aren't included in the NRPT.

    RE: the route - the DirectAccess clients are going to use the UAG DirectAccess as their router and relay, so the routing table entries on the UAG DA server should be enough, right?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, August 2, 2010 3:17 PM
    Moderator
  • Hello,

    I have problems with DA again. We had to redeploy the solution and now we have finally get it to work (at least we thought so). No I can ping DC server from DA client and vise-versa. If i use tracert I see that packets are routed over the tunnel.

    But the problem is that nslookup doesn't respond, also if I want to connect to network shares on DC server, I don't have access. It look like that only ping traffic gest routed over the tunnel everything else doesn't (we have checked this with running wireshark on DA Server - nslookup doesn't create traffic on DA server, ping does).

    Any idea why this is happening?

    Thank you!

    Best wishes,
    Marko

    Tuesday, September 28, 2010 8:01 PM
  • From memory, you cannot use nslookup from a DA client as it is not NRPT aware...

    Ping is also a bad troubleshooting tool for DA as ICMPv6 is exempt from the tunnels and hence proves little in terms of tunnel establishment: http://blogs.technet.com/b/tomshinder/archive/2010/07/14/considerations-when-using-ping-to-troubleshoot-directaccess-connectivity-issues.aspx

    I would suggest you walk through Tom's guide for troubleshooting as it has some good examples: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=d2e460c8-b4bf-4fda-9f86-ecc4b7add5d1

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, September 28, 2010 11:09 PM
    Moderator
  • Hi Jason,

    Thanks! Indeed - it's the "ping works but nothing else" issue that gets a lot of people confused. Ping only confirms that the IPv6 transition technologies are working correctly - but doesn't tell anything about the health of the IPsec tunnels.

    You can use nslookup, but you have to use it a bit differently. As you said, see the Test Lab Guides for great information in this area.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Wednesday, September 29, 2010 3:16 PM
    Moderator
  • It may be a load balance issue. It balances automatically but needs a proper prefix to accomplish it.

    Prefix requirements—Remote Access enables load balancing of both SSL-based traffic and DirectAccess traffic. To load balance all IPv6 based DirectAccess traffic, Remote Access must examine the IPv4 tunneling for all transition technologies. Because IP-HTTPS traffic is encrypted, examining the content of the IPv4 tunnel is not possible. To enable IP-HTTPS traffic to be load balanced, you must allocate a wide enough IPv6 prefix so that a different IPv6 /64 prefix can be assigned to every cluster member. You can configure a maximum of 32 servers in a load balanced cluster; therefore, you must specify a /59 prefix. This prefix must be routable to the internal IPv6 address of the Remote Access cluster, and is configured in the Remote Access Server Setup wizard.

    https://technet.microsoft.com/en-us/library/jj134166(v=ws.11).aspx#3.2 Plan IP-HTTPS


    Keith Hatfield

    Saturday, August 5, 2017 7:42 PM