none
Can't access shares on a DirectAccess client RRS feed

  • Question

  • I have one DirectAccess (DA) client (DAC1) whose shares cannot be accessed from computers on the corpnet or from other DA clients.  DAC1 has a public IPv4 address, but the ISP is apparently blocking 6to4 traffic, so the Teredo interface is used.  I mention this because there are other DA clients that are behind NAT routers who are using Teredo and whose shares can be accessed.

    DAC1 can access shares on the corpnet and on other DA clients.

    As far as I can tell the firewall is configured the same on DAC1 as on there other DA clients; the only obvious difference is that DAC1 is not behind a NAT router.

    Any ideas on how to make DAC1's shares accessible?

    Thanks.

    Monday, August 2, 2010 9:56 PM

Answers

  • Thanks for your reply. 

    DAC1 has a Teredo IPv6 address.  6to4 is disabled on DAC1.

    I was able to access shares on DAC1 from the corpnet by changing the scope of the Remote IP address of following inbound firewall rules for the Public profile on DAC1 from "Local subnet" to "Any IP address", as well as allowing edge traversal.

    • File and Printer Sharing (Echo Request - ICMPv6-In)
    • File and Printer Sharing (SMB-In)

    It turns out that the other DA clients whose shares could be accessed from the corpnet by default had "Any IP adress" as their Remote IP address scope, and I had manually set "Allow edge traversal".  The only reason I can think of why DAC1 has "Local subnet" is that DAC1 runs Windows 7 while the other DA clients run Server 2008 R2.

    • Marked as answer by sejong Tuesday, August 3, 2010 4:34 PM
    Tuesday, August 3, 2010 3:53 PM

All replies

  • Try to ping DAC1 from corpnet and see if it's using the teredo address or 6to4.

    If it's using the 6to4 address and the 6to4 protocol is blocked by the ISP, then this is a problem, and you should disable 6to4 on the client (netsh int 6to4 set state disabled)

    Also make sure you have a firewall rule on the client that enables inbound connections for file sharing, and that this firewall rule allows edge traversal.

    Tuesday, August 3, 2010 10:57 AM
  • Thanks for your reply. 

    DAC1 has a Teredo IPv6 address.  6to4 is disabled on DAC1.

    I was able to access shares on DAC1 from the corpnet by changing the scope of the Remote IP address of following inbound firewall rules for the Public profile on DAC1 from "Local subnet" to "Any IP address", as well as allowing edge traversal.

    • File and Printer Sharing (Echo Request - ICMPv6-In)
    • File and Printer Sharing (SMB-In)

    It turns out that the other DA clients whose shares could be accessed from the corpnet by default had "Any IP adress" as their Remote IP address scope, and I had manually set "Allow edge traversal".  The only reason I can think of why DAC1 has "Local subnet" is that DAC1 runs Windows 7 while the other DA clients run Server 2008 R2.

    • Marked as answer by sejong Tuesday, August 3, 2010 4:34 PM
    Tuesday, August 3, 2010 3:53 PM
  • Firewall rules for DA clients are different from the rules you usually have in your organization.

    They should be scoped for the public profile. and for teredo clients, they must have edge traversal enabled. (also, as a security measure, you should specify the corp IPv6 prefix as the remote endpoint, so other malicious machines on the internet won't be able to connect).

    I didn't think this was the problem in your case since you said you have other teredo clients that are working, and what's not working is 6to4.

    Anyway, Tom is going to write a blog about configuring Windows Firewall for DirectAccess clients. Is that right Tom? ;)

    Wednesday, August 4, 2010 3:02 PM
  • Good point about limiting the remote endpoint to the corp IPv6 prefix.

    I do think the problem in my case was that the remote endpoint was set to Local subnet by default.  The Teredo clients (running Server 2008 R2) that were working had the remote endpoint set to ANY by default, whereas the Teredo client DAC1 (Windows 7) that was not working had the remote endpoint set to Local subnet by default.  Of course, it was necessary to allow edge traversal on the referenced firewall rules on DAC1, but I had already done that and that alone had not solved the problem.

    Clarification - To get DirectAccess on DAC1 working at all, I had to disable 6to4, even though DAC1 has a public IPv4 address.  I think this is because the ISP is blocking 6to4 traffic.  As soon as I ran netsh interface 6to4 set state disabled, the DirectAcess connection started working (as evidenced by the DirectAcess Connectivity Assistant icon changing from red to green).

    Wednesday, August 4, 2010 3:57 PM
  • Hi Yaniv,

    Yes! Thanks for the reminder. :)

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Thursday, August 5, 2010 12:41 PM
    Moderator
  • Hi Sejong,

    This blocking 6to4 traffic is a well known problem and your solution is the only one we know of right now that corrects the problem.

    For more information on how to configure remote management in a Test Lab (which includes the scoping configuration that Yaniv talks about) check out the Test Lab Guide: UAG DirectAccess Remote Management at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=385a3144-8e84-4335-896b-a2927e4d46cd

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Thursday, August 5, 2010 12:44 PM
    Moderator