Take a look at the figures below and see if you can guess what device is in the request/response path that you don’t typically see a UAG DirectAccess deployment.
First, the ipconfig output on a DirectAccess client located behind a NAT device:
Now let’s ping DC1:
Now let’s do a tracert from CLIENT1 and DC1:
With this information you should be able to figure out what the “novel” device is in the path between CLIENT1 and DC1. If you know, then consider yourself pretty well-versed with IPv6 addressing. If you don’t know, then here’s a great opportunity to learn something new!
Now take a look at figures 4 and 5 and determine what device was removed from the path:
Think about the solutions and put your answer in the comments section. Give your reasoning. I’ll post the answer and a network diagram of the solution tomorrow.
Tom Shinder firstname.lastname@example.org Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX UAG Direct Access/Anywhere Access Group (AAG) The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
Visit the TechNet forums to discuss all your UAG DirectAccess issues http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads
Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki http://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx
Is it a 6to4 gateway/router? Due to the fact the hops between the client and DC have 6to4 prefixes and the client is assigned a 6to4 prefix.
Is that a separate ISATAP router? Usually the UAG server would be the ISATAP router, but it looks like this other router is in between them.
I would guess an IPv6 firewall is in the path; this creates the additional hop in the tracert...
You guys are doing great! I added two more figures to make the exercise a bit more interesting.
Now it looks like the UAG server isn't in the path.
No, the UAG server is in the path. But - something was removed.
This is a pretty tricky (interesting?) scenario - you'll like the explanation tomorrow :)
I would guess that you also have a native IPv6 deployment in the network where your client is, since the “2002:…” - IPv6 address is assigned to the network adapter itself and not to a 6to4 tunnel adapter.
That would also explain the IPv6 address marked as “Temporary” (Statless autoconfig?) and the Site-Local IPv6 address (fec0:..).
So I’d say that you have a native IPv6 router in-between.
The client is no longer receiving a native IPv6 address and is now using Teredo/IP-HTTPS transition technologies.
I am guessing the IPv6 firewall or router than was doing RA has been removed and we are relying on IPv4 only (hence the use of transition technolgies)...
I'll post the answer on Friday - got caught up in meetings today.