none
UAG 2010 Direct Connectivity Assistant Verifier Behaviour RRS feed

  • Question

  • Hi,

    I'm hoping someone can clarify an obervation for me:

    I've setup a windows network load balancing cluster and configured a website on each server as follows:

    nls1.contoso.com -192.168.0.1
    nls2.contoso.com - 192.168.0.2

    wnlbs - nls.contoso.com - 192.168.0.3

    I'm using http://nls.contoso.com  (IIS HA website) as a network location server, which works fine.

    I've also configured a share on each server for DCA:

    \\nls1.contoso.com\dca$\verify.txt
    \\nls2.contoso.com\dca$\verify.txt

    However clients cannot resolve \\nls.contoso.com\dca$\verify.txt (pings to cluster hostname work fine). Internal resolution works fine. 

    Yet, when I create an A record and point to the cluster IP, DA clients can successfully resolve \\DNSARECORD.fqdn\dca$\verify.txt

    I'm curious why a DA client can ping the cluster hostname, but not browse directly to the cluster hostname, yet when an A record is added for the same IP, the DCA file verifier works fine?
     


    IT Support/Everything

    Wednesday, October 3, 2012 4:01 PM

Answers

  • Hi again,

    Are you using Windows Server 2008 R2 with Forefront UAG as it looks like in the topic or are the servercomponents running Windows Server 2012?

    When I look at the NRPT rules on a Windows 8 client connected to a Windows Server 2012 setup there is no exception for the NLS site.
    But on a Windows 7 client connected to a Forefront UAG setup the NLS is added as an exception.

    As a secondary layer to prevent DA clients to reach the NLS there is actually a  separate IPSec rule that Exempts the NLA by its various IP addresses (ISATAP, IPv6, NAT64 and so on).
    Due to this, ICMP traffic will be allowed since it is exempt from all IPSec rules, but normal traffic is not exempt.


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Marked as answer by Aetius2012 Thursday, October 4, 2012 11:49 AM
    Thursday, October 4, 2012 10:40 AM

All replies

  • Hi,

    This is the correct behavour.

    The NLS url is blocked in the NRPT rules so it is only reachable when the client is available on the corporate LAN.

    If you run netsh namespace show policy you will see it listed there.

     


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Wednesday, October 3, 2012 4:31 PM
    • Unproposed as answer by Jonas Blom Thursday, October 4, 2012 10:27 AM
    Wednesday, October 3, 2012 4:30 PM
  • Hi Jonas,

     In that case, when using a DA client (off the corp LAN) shouldn't pings to the nls and UNC path browsing both fail?

    Rather than just one?


    IT Support/Everything


    • Edited by Aetius2012 Thursday, October 4, 2012 8:41 AM
    Thursday, October 4, 2012 8:41 AM
  • Hi again,

    Are you using Windows Server 2008 R2 with Forefront UAG as it looks like in the topic or are the servercomponents running Windows Server 2012?

    When I look at the NRPT rules on a Windows 8 client connected to a Windows Server 2012 setup there is no exception for the NLS site.
    But on a Windows 7 client connected to a Forefront UAG setup the NLS is added as an exception.

    As a secondary layer to prevent DA clients to reach the NLS there is actually a  separate IPSec rule that Exempts the NLA by its various IP addresses (ISATAP, IPv6, NAT64 and so on).
    Due to this, ICMP traffic will be allowed since it is exempt from all IPSec rules, but normal traffic is not exempt.


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Marked as answer by Aetius2012 Thursday, October 4, 2012 11:49 AM
    Thursday, October 4, 2012 10:40 AM
  • Thanks Jonas, I'm using server 2008 R2 UAG 2010 with Windows 7 clients

    IT Support/Everything

    Thursday, October 4, 2012 11:49 AM