none
Getting started with UAG-DA - problem with internal client reaching servers! RRS feed

  • Question

  • So this sounds a bit odd, but I'm following the testlab guides for testing out Forefront UAG/DA SP1 and I've run into an unusal problem which I can't find a proper solution to.

    DC1 can ping APP1, UAG1 (and a 3rd server I have on the network) using the IPv6 ISATAP addresses just fine. And so can the other servers. I've deployed the ICMP firewall GPO to all machines in the domain. (All servers are 2008R2).

    However, CLIENT1 (A Windows 7 Enterprise machine) can not. If I do a ping to either DC1 or APP1 it resolves the addresses correctly, but it can get no ICMP reply. (I've verified the firewall "hole" is opened on the client). When I try to ping UAG1 I get the real IPv6 address instead of the ISATAP address. Basically I'm not getting anywhere on my testing :D

    The CLIENT does have connectivity with the DC1 and APP1 (NLS) server, I can browse files from shares and view the IIS content, but can't ping. Doing IPCONFIG /ALL on the CLIENT I see that I do not get proper IPv6 addresses on the ISATAP adapter (only a link-local preferred address).

    Doing the netsh namespace show effectivepolicy tells me I'm on the internal net and it won't show me the table (but netsh namespace show policy tells me a lot of stuff). Running certutil -store my shows my computers enrolled certificate and stuff seems to be in order...

    There may very well be something simple standing in my way, but at this point I'm unable to see it.

    Any Clues on where to proceed?

     

    Thursday, August 18, 2011 2:46 PM

Answers

  • UAG definitely works with IPv6 inside the network. However, having IPv6 inside does definitely change the installation path, and following the TLGs is probably not your best bet. Having IPv6 inside does not affect 6to4, Teredo or IP-HTTPS because those technologies all deal with the traffic outside of your corporate network, tunneling the DirectAccess IPv6 traffic over the IPv4 Internet. However, ISATAP is basically just doing the same job inside your network, enabling the tunneling of IPv6 packets over an IPv4 Corporate network. Since you have an IPv6 corporate network anyway, you do not need ISATAP at all.

    I would start over with your UAG config, take ISATAP back out of DNS, and remove the new DNS IPv6 addresses that were registered by ISATAP (the ones that end with the IPv4 address). Then start by taking a look here for planning your design with an IPv6 intranet: http://technet.microsoft.com/en-us/library/ee406201.aspx

    Good luck!

    • Marked as answer by Erez Benari Friday, August 26, 2011 10:28 PM
    Saturday, August 20, 2011 1:55 AM

All replies

  • So just to clarify, your CLIENT is actually connected to the corporate network at this moment, correct? It sounds from your description like that is true, but ultimately you are trying to test DA so I wanted to make sure we're troubleshooting the correct network connection :)

    Assuming that you are connected to the corporate network and you are not getting an ISATAP address, I would start troubleshooting ISATAP first. Can you "ping isatap" from a command prompt on CLIENT and get a response?

    Also, I'm not sure what you mean by the "real IPv6 address" on the UAG1. If following the TLGs, you are setting up an internal IPv4 network, not an IPv6 network...right?

    Thursday, August 18, 2011 7:19 PM
  • So just to clarify, your CLIENT is actually connected to the corporate network at this moment, correct? It sounds from your description like that is true, but ultimately you are trying to test DA so I wanted to make sure we're troubleshooting the correct network connection :)

    I may be trying a bit too much all at one time these days, and my problem may be more "network" than "UAG" but since UAG is what I'm aiming for I figure all the experts are here. The CLIENT is on my "corporate" lab network, i.e. the same LAN as the servers (DC1, APP1, UAG1 and so on).

    Assuming that you are connected to the corporate network and you are not getting an ISATAP address, I would start troubleshooting ISATAP first. Can you "ping isatap" from a command prompt on CLIENT and get a response?

    I got as far with the TLGs that I was supposed to start testing the CLIENT. That means that NLS, ISATAP and all servers were properly registered in DNS (running on DC1) and that all servers could ping each other both on IPv4 and IPv6 global and local addresses...

    Also, I'm not sure what you mean by the "real IPv6 address" on the UAG1. If following the TLGs, you are setting up an internal IPv4 network, not an IPv6 network...right?

    Maybe I'm not understanding IPv6 properly :) But since our corporate network actually IS IPv6 enabled that means all routers and switches are configured to designate "proper" addresses. Thus, all my servers have 2 or 3 IPv6 addresses... "proper" ones under Scope:Global and "local" ones under Scope:Local. (Some have presented privcay extension addresses aswell, but I think that's mostly clients). These addresses changed during the configuration of ISATAP (atleast the ones DNS resolved changed) to be like [ipv6blob]:[ipv4address] (which I'm supposing was OKAY, atleast for the server part). I'm going to have to go in tomorrow and clean up some and try to redo this. Maybe I'll get smarter by then... I'm not sure this made much sense but I just had to reach out (I was very frustrated :D) Maybe... UAG doesn't work with "proper" IPv6 networks? Shouldn't it make stuff easier? (No need to tunnel 6to4 etc.?)
    Friday, August 19, 2011 7:59 PM
  • UAG definitely works with IPv6 inside the network. However, having IPv6 inside does definitely change the installation path, and following the TLGs is probably not your best bet. Having IPv6 inside does not affect 6to4, Teredo or IP-HTTPS because those technologies all deal with the traffic outside of your corporate network, tunneling the DirectAccess IPv6 traffic over the IPv4 Internet. However, ISATAP is basically just doing the same job inside your network, enabling the tunneling of IPv6 packets over an IPv4 Corporate network. Since you have an IPv6 corporate network anyway, you do not need ISATAP at all.

    I would start over with your UAG config, take ISATAP back out of DNS, and remove the new DNS IPv6 addresses that were registered by ISATAP (the ones that end with the IPv4 address). Then start by taking a look here for planning your design with an IPv6 intranet: http://technet.microsoft.com/en-us/library/ee406201.aspx

    Good luck!

    • Marked as answer by Erez Benari Friday, August 26, 2011 10:28 PM
    Saturday, August 20, 2011 1:55 AM
  • So it seems I don't need ISATAP then... it also seems I was totally confused. Have read up on my IPv6 skills now and rolled back all servers. So far, everything seems OKAY and everyone can ping everyone both using IPv4 and IPv6.

    At this point in time I don't even want to wager what was wrong previously... I'll proceed with UAG installation now :)

    Tuesday, August 23, 2011 2:46 PM
  • Just to update: it worked...

    I did run into a problem with the external interface being classified as internal (not sure why) but managed to work around it.

    Friday, September 30, 2011 10:38 AM
  • Do you mean the External NIC was being assigned the Domain profile in Windows Firewall? That typically happens when the External NIC has some form of routing back into your internal network, and therefore to a domain controller. If that is the case I would check over your firewall settings and make sure there's not a route allowing that to happen.
    Friday, September 30, 2011 12:52 PM
  • Yup that's what I meant. However, the only routing "back into the internal network" was the DNS port on the Domain Controller... maybe that was enough?

    Last time I tried I had to make firewall rules and "trick" it into cooperating, this time I only deleted the "network cache" (in registry) and rebooted. It's very likely this just got stuck from OS installation... or something.

    Monday, October 3, 2011 7:11 AM