none
Forefront UAG 2010: "The adapter configured as external-facing is connected to a domain" ???

    Question

  • I am attempting to deploy Forefront UAG 2010 in a test environment.  The UAG server is installed on Windows Server 2008 R2 Enterprise and has two NICs... one is connected to the "corporate" LAN (with a private 10.x.y.z address) and the other is connected to the Internet (yes, with TWO consecutive "real" IP addresses).  The system is a member of a WS2008 AD domain which has its DCs and DNS servers on the "corporate" LAN.  AD, DNS, routing, etc all seem to be working correctly.

    In general, my config is mostly set up properly (intermediate testing and diagnostics look reasonable), and I have been able to successfully generate what looks to be a reasonable set of policies.  However, when I attempt to activate the configuration, the activation wizard eventually fails with this message:

              The UAG DirectAccess configuration cannot be activated.
              The adapter configured as external-facing is connected to a domain.  This interface cannot be used with UAG DirectAccess.

    I have read every UAG doc/whitepaper I can find and Googled extensively and cannot find ANY references to this error message.  I am stuck.

    The adapter is "connected to a domain"?  What does this mean?  Are we talking about an AD domain?  DNS domain?  Kerberos realm?  How does one connect an adapter to a domain?  Or, I suppose more relevantly in this case, how does one DISCONNECT an adapter from a domain?

    Any light that anyone could shed on this one would be MUCH appreciated.  Thanks!

     

    tkarp

    Tuesday, April 06, 2010 12:24 AM

Answers

  • Thanks to everyone for their feedback and help in trying to solve this one.

    This afternoon I figured out the root cause of my problems: I was trying to "cheat".  In setting up my test environment, I was being lazy and trying to use my UAG system as the default router for my LAN.  I realize that UAG clamps things down pretty tight, so I used the TMG "underneath" and added a few "normal" firewall rules to it to make it work as a standard TMG firewall router for the LAN.  Unfortunately, it looks like those changes borked the config for UAG and caused my problems.

    I reinstalled that system with TMG and configured it as a real firewall router, then added a second system with UAG that is just doing "normal" UAG stuff.  This time the UAG policies activated correctly as expected.

    Interesting side note: after seeing Mika's replies, I looked at the interfaces on my original "hybrid" UAG box... and they seemed normal, i.e. the internal NIC showed as a Domain location and the external NIC showed as Public.  But I still got the error as I wrote originally.  So somehow the activation wizard "knew" that my external NIC was "connected to a domain", but I had no visual indications, log entries, error messages, etc to indicate that there was any configuration problem.

    Lesson learned: I should've heeded the product warnings and not tried to make my UAG system a default router.  :)  Having said that, I *do* believe that the error message in question should be much more clear and should CERTAINLY be documented.  If the activation wizard was smart enough to determine that I had an illegal config, it should've said "hey stupid, you've got an illegal config".

     

    tkarp

    • Marked as answer by Tom Karpowitz Wednesday, April 07, 2010 2:40 PM
    Wednesday, April 07, 2010 5:47 AM

All replies

  • I faced this same problem some time ago in a test environment... External NIC is automatically assigned Domain Profile by NLA (Network Location Awareness) service. Solution that I deployed was to remove UAG as default gateway from domain controller. BTW, this check (in Activation Wizard) was not there in UAG beta which caused me to get rather confused since I had a fully working beta environment...

    HTH
    Mika

    Tuesday, April 06, 2010 5:37 AM
  • Hey guys,

    I don't know about the situation where you configure the UAG server as the default gateway, but I'm following up on that.

    However, just to keep it in mind, there's never a reason to make the UAG server the default gateway, since it can never be configured to enable outbound access - UAG is only for inbound access.

    Tom K - is the network the external interface connected to physically or logically (via VLAN) separate from the segment the DC is connected to?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, April 06, 2010 5:18 PM
  • Hey guys,

    Seems like this isn't an isolated problem and we're working on finding more information on why this might be happening.

    Until then, you might want to consider this article to get things going for you:

    http://technet.microsoft.com/en-us/library/ee649272(WS.10).aspx

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, April 07, 2010 12:05 AM
  • Hi Tom,

    I don't think that you can use the instructions provided by the Technet article you referred since this situation is caused by the traffic from internal domain controller being routed through the internal NIC. If packet filters were used, no NIC would be identified in domain profile by NLA.

    I had UAG as DC gateway in my test environment since it was the only gateway available due to hardware limitations of the host computer i.e. not possible to have TMG etc. as gateway.

    Mika

    Wednesday, April 07, 2010 4:30 AM
  • Thanks to everyone for their feedback and help in trying to solve this one.

    This afternoon I figured out the root cause of my problems: I was trying to "cheat".  In setting up my test environment, I was being lazy and trying to use my UAG system as the default router for my LAN.  I realize that UAG clamps things down pretty tight, so I used the TMG "underneath" and added a few "normal" firewall rules to it to make it work as a standard TMG firewall router for the LAN.  Unfortunately, it looks like those changes borked the config for UAG and caused my problems.

    I reinstalled that system with TMG and configured it as a real firewall router, then added a second system with UAG that is just doing "normal" UAG stuff.  This time the UAG policies activated correctly as expected.

    Interesting side note: after seeing Mika's replies, I looked at the interfaces on my original "hybrid" UAG box... and they seemed normal, i.e. the internal NIC showed as a Domain location and the external NIC showed as Public.  But I still got the error as I wrote originally.  So somehow the activation wizard "knew" that my external NIC was "connected to a domain", but I had no visual indications, log entries, error messages, etc to indicate that there was any configuration problem.

    Lesson learned: I should've heeded the product warnings and not tried to make my UAG system a default router.  :)  Having said that, I *do* believe that the error message in question should be much more clear and should CERTAINLY be documented.  If the activation wizard was smart enough to determine that I had an illegal config, it should've said "hey stupid, you've got an illegal config".

     

    tkarp

    • Marked as answer by Tom Karpowitz Wednesday, April 07, 2010 2:40 PM
    Wednesday, April 07, 2010 5:47 AM
  • Hi Tom,

    Thanks for the follow up!

    You make some good points here and I'll take them back to the Product Group. Configuration validation is very important for us.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, April 07, 2010 11:59 AM
  • Does this mean if I configure the TMG settings to allow external access to the UAG server, it will fail to activate the configuration?

    I have bound an additional IP address to the Internal NIC of my UAG host and bind that to a site in IIS to host my Certificate Revocation List and I intend to make that http site available internally and externally.

    Thursday, May 06, 2010 6:52 PM
  • It turns out once you activate the UAG Configuration it wipes everything out of IIS, so using the UAG server for any other web sites is futile.  I moved the web sites (and certificates) to another server and removed the additional IP addresses from the Internal NIC and now I can activate it!
    Friday, May 07, 2010 8:13 PM
  • Does this mean if I configure the TMG settings to allow external access to the UAG server, it will fail to activate the configuration?

    I have bound an additional IP address to the Internal NIC of my UAG host and bind that to a site in IIS to host my Certificate Revocation List and I intend to make that http site available internally and externally.


    Hi Mr Shannon,

    You should never configure the TMG firewall on the the UAG DA server unless CSS tells you, or you have specific scenarios that are supported by the UAG support boundaries document.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Saturday, May 08, 2010 12:45 PM
  • It turns out once you activate the UAG Configuration it wipes everything out of IIS, so using the UAG server for any other web sites is futile.  I moved the web sites (and certificates) to another server and removed the additional IP addresses from the Internal NIC and now I can activate it!


    That's correct. That's why you can't put the NLS on the UAG DA server.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Saturday, May 08, 2010 12:46 PM
  • Hello,

    I experienced the same problem as described. As statet in the following thread  http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/2632aec7-8962-48ee-9f60-fd82f0066e35 default both network adapters (internal an external) are classified "Domain Network" by the NLA. In this configuration I get the above statet error "The UAG DirectAccess configuration cannot be activated. The adapter configured as external-facing is connected to a domain.  This interface cannot be used with UAG DirectAccess."

    By simply deactivating and activating the external interface it is classified as Public Network, the UAG Wizard works and direct access works and can be used. After a reboot both interfaced are classified as Domain Network. A simple deactivate/active of the interface helps, but is no solution because the UAG isn't reboot secure.

    A parallel TMG in the DMZ shows the same behavoir, both interfaces are classified "Domain Network". The external interface hs no connection to the internal DNS and Actice Directory Servers.

    Hope somebody has some hints

    Kind regards

    Jan

    Thursday, May 20, 2010 11:52 AM
  • Hello again,

    as a further test I booted the system with a deacivated Internet Network card (pulled network cable) and the external NIC was classified as Pubic Network. (Which gives me the good feeling that the external NIC can't has no routing to the internal DNS oder AD) But why is the external NIC classified as Domain Network when the internal NIC is activated ?

    Regards

    Jan

    Thursday, May 20, 2010 1:17 PM
  • Configuring the IP addresses on the UAG NICs has a couple caveatsthat you need to be aware of.  I wrote up a quick how-to that might help.

    http://mrshannon.wordpress.com/2010/04/30/setting-ip-addresses-on-a-uag-directaccess-server/

    Highlights of the post:

     

    1. No Gateway or DNS on the external NIC
    2. Set static routes for all of your internal subnets
    Let me know if you find that helpful.

     

    • Edited by MrShannonMVP Thursday, May 20, 2010 1:58 PM typo
    Thursday, May 20, 2010 1:58 PM
  • Hi MrShannon,

    thats exact the way both systems (UAG and TMG and even the OCS Edge Server are configured) but it doesn't help. What I'm interested in ist how the NLA works and discovers if an interface is Public oder Domain network ? Perhaps via AD Sites and Subnets ? Thanks anyway.

    Kind regads

    Jan

    Thursday, May 20, 2010 2:14 PM
  • If the external interface can reach the DC, then that interface will assign itself the domain profile.

    The UAG server will do a srv based DNS query to find the name of the DC. Then if the external interface can connect to the DC, it will assume that it's on the domain. Connectivity can be over IP4 or IPv6.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, May 20, 2010 2:25 PM
  • Configuring the IP addresses on the UAG NICs has a couple caveatsthat you need to be aware of.  I wrote up a quick how-to that might help.

    http://mrshannon.wordpress.com/2010/04/30/setting-ip-addresses-on-a-uag-directaccess-server/

    Highlights of the post:

     

    1. No Gateway or DNS on the external NIC
    2. Set static routes for all of your internal subnets
    Let me know if you find that helpful.

     


    Hi Shannon,

    Great post!

    One thing though - why not use a 6to4 prefix instead of a link-local prefix?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, May 20, 2010 2:26 PM
  • Configuring the IP addresses on the UAG NICs has a couple caveatsthat you need to be aware of.  I wrote up a quick how-to that might help.

    http://mrshannon.wordpress.com/2010/04/30/setting-ip-addresses-on-a-uag-directaccess-server/

    Highlights of the post:

     

    1. No Gateway or DNS on the external NIC
    2. Set static routes for all of your internal subnets
    Let me know if you find that helpful.

     


    Thanks for the link to my blog Mr S!
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, May 20, 2010 10:27 PM
  • Hi Shannon,

    Great post!

    One thing though - why not use a 6to4 prefix instead of a link-local prefix?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team

    That's a fair question Tom.  First off, I understood how to create the link-local address and I saw it as technically the same address as the IPv4 address, so it seemed like an appropriate one to use.  Second, I thought that the 6TO4 address / prefix was something that was automatically generated on the machine and was tied to a different "virtual" 6TO4 adapter, so I figured if I set the IPv6 address on my physical nic using the 6TO2 prefix (2002:), it would/could break that functionality.

    What do you think?  Is setting an IPv6 address good, bad or just ugly?

    Friday, May 21, 2010 3:22 PM
  • Thanks for the link to my blog Mr S!
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Oh you are absolutely welcome Jason.  After I wrote mine up I found your post and it not only validated what I thought was right but pointed out that I should also remove the external DNS settings.  I have found several of your posts to be very helpful, so thank you!
    Friday, May 21, 2010 3:30 PM
  • Thanks - I have another blog that talks about defining 6to4 based native IPv6 addresses for UAG here: http://blog.msedge.org.uk/2010/05/path-to-directaccess-part-2-thinking.html

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Friday, May 21, 2010 9:58 PM
  • Hi Jan-Christian,

    Can you please check whether you have forwarding enabled on your external IPv4 interface?

    use "netsh int ipv4 show int level=verbose" to check the forwarding state.

    If forwarding is indeed enabled, try disabling it and restart the server. Let us know how this works.

     

    MrShannon, I'm not sure it's a best practice to configure a link-local IPv6 address as a static IPV6 address on a NIC. you can keep the interface searching for a DHCP/publishing router. If you don't have IPv6 on your organization it will not find a DHCP/router anyway. Furthermore, TMG blocks IPv6 until DirectAccess is configured and activated. which means, the machine will not be able to find a DHCP or receive router advertisement even if one exists.

    All IP addresses on the UAG server must be configured statically.

    Saturday, May 22, 2010 1:41 PM
  • Hi Yaniv,

    Forwarding is disabled by default, is that correct?

    Is there a UI element that might have enabled this, or does the UAG installation routine enable this?

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, May 24, 2010 6:07 PM
  • Hello Yaniv,

    indeed forwarding is enabled but disabling and restart didn't help (the external interface is set to domain network after the reboot) It seems that the enable command ist set during the TMG installation because on our TMG it is set also.

    Thanks for your advice ;-) any other ideas are welcome :-)

    Kind regards

    Jan

    Monday, May 24, 2010 7:55 PM
  • Hi,

    From my experience I learned that having forwarding enabled on the external interface causes this issue.

    Forwarding should be disabled by default on all NICs. And when activating UAG DirectAccess, forwarding is enabled on the internal interface and on the transition technology interfaces, but never on the physical external interface.

    When forwarding is enabled on the external interface, Network Location Awareness sevice tries to determine whether a domain controller is reachable by binding on each interface on the machine. and because the external interface is fowarding, it actually allows the packet to be forwarded to the internal interface, and then reaches the destination.

    It is possible that another feature configured in UAG or TMG has enabled the forwarding on the external interface. Can you please specify which features are you using on these servers apart from DirectAccess?

    Thanks

    Tuesday, May 25, 2010 1:50 PM
  • Hi Yaniv,

    Thanks! That's interesting information and will help troubleshoot these issues.

    Jan -

    Do you any other software installed on the UAG server? Backup agents, management agents, anything other than Windows Server 2008 R2 and UAG?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, May 25, 2010 2:38 PM
  • Hi,

    From my experience I learned that having forwarding enabled on the external interface causes this issue.

    Forwarding should be disabled by default on all NICs. And when activating UAG DirectAccess, forwarding is enabled on the internal interface and on the transition technology interfaces, but never on the physical external interface.

    When forwarding is enabled on the external interface, Network Location Awareness sevice tries to determine whether a domain controller is reachable by binding on each interface on the machine. and because the external interface is fowarding, it actually allows the packet to be forwarded to the internal interface, and then reaches the destination.

    It is possible that another feature configured in UAG or TMG has enabled the forwarding on the external interface. Can you please specify which features are you using on these servers apart from DirectAccess?

    Thanks


    Yaniv,

    If we disabled forwarding on the external interface using:

    netsh interface ipv6 set interface InterfaceNameOrIndex [forwarding=]enabled|disabled]

    Would that fix the problem?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, May 25, 2010 2:57 PM
  • Hi Yaniv,

    I just answered my question above - since you asked to check forwarding on the IPv4 interface :)

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, May 25, 2010 5:02 PM
  • Hi Tom,

    I guess forwarding on the external IPv6 interface can cause the same issue, but only if you have a global IPv6 address on that interface. (or when the DC/DNS server is on the same IPv6 link)

    I'm not sure that's the case for Jan, so I suggested only the IPv4 interface.

     

    Jan, can you please check whether forwarding is also enabled on the IPv6 interface? It should have the same interface index as the IPv4 interface. just use the command "netsh int ipv6 show int <InterfaceIndex>"

    Tuesday, May 25, 2010 5:27 PM
  • Hello Tom, Hello Yaniv,

    forwarding was not an issue as I solved the problem by clearing the NLA Cache in the registry ( HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache\IntranetAuth)

    I had several entries for the external interface which I deleted. That also explaines why diabling and enabling the external NIC helped.

    Thanks for your help.

    Kind regards

    Jan

    Wednesday, May 26, 2010 10:28 AM
  • Hi Jan-Christian,

    Did you delete all the entries that had the IP addresses on the external interface associated with them?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, May 27, 2010 4:05 PM
  • Hi Tim,

    yes, i delete all entries (3 or 4 due to changing resp. adding additional IP-Adresses) and this helped. But it seems that that this issue is not only an UAG issue, the same phenomon can be found on our TMG ( a separate Server in the DMZ) Here I also have multiple entries in the NLA-Cache and the external Interface is marked as "Domain Network". Maybe something for product team.

    Regards

    Jan

    Friday, May 28, 2010 9:44 AM
  • Hi Jan,

    Very good. Your post generated a lot of discussion and a blog post.

    Check this out and let me know what you think:

    http://blogs.technet.com/b/tomshinder/archive/2010/05/27/uag-directaccess-quot-the-adapter-configured-as-external-facing-is-connected-to-a-domain-quot.aspx

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, June 01, 2010 3:43 PM
  • Hi All,

    A client has been surviving this problem for some time and an enforced short notice (1 day) external IP Address range change made me look at the issue again (DA and TMG only on server).  After sucessfully changing the external IP addresses for the DA Server, another story in itself, I was monitoring the TMG whilst I brought up the TMG Firewall services manually.

    The System Rule "Allow access to directory services for authentication purposes" allowed LDAP packets from the external interface to the domain controller.  Immediately following that, the Network Location Awareness moved the Internet Connection to the dreaded "Domain Network" from a newly created and stable "Internet Network".

    It appears that this system rule allows "Local Host" to connect to LDAP, the Network Location Awareness looks to see if an interface can connect via LDAP, the "Local Host" is not configurable and seems to include all the IP addresses on the server which is why when running the default windows firewall all is OK for setting up DA but as soon as TMG is live, the NLA can see LDAP from the external interface and so moves it to the Domain Network.

    Unfortunately the TMG logs are no longer available to post this example but perhaps this info may help point the way to a permanent fix.  Apologies if this is old news.

    Thanks,

    BobK

    Wednesday, February 23, 2011 10:29 PM