Share via

UAG DirectAccess–Guess the Device in the Request/Response Path

  • Article

imageTake 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:

image

Figure 1

Now let’s ping DC1:

image

Figure 2

Now let’s do a tracert from CLIENT1 and DC1:

image

Figure 3

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!

UPDATE!

Now take a look at figures 4 and 5 and determine what device was removed from the path:

image

Figure 4

image

Figure 5

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.

Have fun!

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): https://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder

Visit the TechNet forums to discuss all your UAG DirectAccess issues https://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/threads

Stay up-to-date with “just in time” UAG DirectAccess information on the TechNet wiki https://social.technet.microsoft.com/wiki/tags/DirectAccess/default.aspx

Comments

  • Anonymous
    January 01, 2003
    You guys are doing great! I added two more figures to make the exercise a bit more interesting. Thanks! Tom

  • Anonymous
    January 01, 2003
    @Ken - 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 :) Thanks! Tom

  • Anonymous
    January 01, 2003
    Hey guys, I'll post the answer on Friday - got caught up in meetings today. Thanks! Tom

  • Anonymous
    January 11, 2011
    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.

  • Anonymous
    January 11, 2011
    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.

  • Anonymous
    January 11, 2011
    I would guess an IPv6 firewall is in the path; this creates the additional hop in the tracert...

  • Anonymous
    January 11, 2011
    Now it looks like the UAG server isn't in the path.

  • Anonymous
    January 11, 2011
    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.

  • Anonymous
    January 11, 2011
    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)...