none
File Share Access over VPN

    Question

  • I have Win2008 R2 file server setup with a file share that needs to be access over a VPN from a client's home. I have a Watchguard X750e firewall appliance that is setup to allow VPN connections to our network. The VPN connections on our client machines are setup to connect to our firewalls external interface (Static IP) and also has our LAN's DNS server set manually.

    Our clients can connect just fine to the network through the firewall, they can also ping the file server, and RDP into it. But they cannot access the file share. I have used both the regular UNC path and the full domain name of the file server in UNC format (i.e.- \\filesrv.domainname.com\file share) with the same results. Nothing.

    I am currently using Win7 and Vista on client machines that our trying to connect. I used to connect this way just fine using Win2003 and XP clients. I am not sure if its a client problem or a server side issue. I am leaning towards server side, although XP client test should make this clear hopefully.

    I have disabled the firewall on the file server to see if that was blocking incoming connections and that did not help.

    Any ideas???

    Dennis Robare
    MCSA
    Friday, January 22, 2010 3:34 PM

Answers

  • Hi Dennies,

    The following ports are associated with file sharing and server message block (SMB) communications:
    • Microsoft file sharing SMB: User Datagram Protocol (UDP) ports from 135 through 139 and Transmission Control Protocol (TCP) ports from 135 through 139.
    • Direct-hosted SMB traffic without a network basic input/output system (NetBIOS): port 445 (TCP and UDP)

    Please check on the Watchguard firewall to ensure the above pots are not blocked.

    Hope it helps.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by DenRobare Tuesday, January 26, 2010 4:01 PM
    Tuesday, January 26, 2010 6:33 AM

All replies

  • Try connecting with syntax

    net use * \\SrvIPAddress\Share where you specify the IP address rather than the name

    If that works, your problem is name resolution not happening

    DIlip
    www.msftmvp.com and VHD tools at www.VMUtil.com
    Friday, January 22, 2010 8:50 PM
    Moderator
  • I think I tried that way but will try again. I am connecting by RDP using DNS name, so I dont think the problem lies there. I will let you know what this results in.
    Friday, January 22, 2010 9:03 PM
  • Hello Dennis,

    Would you please also check if there installed with any Anti-Virus application on the file server?

    According to our experience, it is reported that some anti-virus applications, such as Symantec Endpoint Protection, may affect the file sharing function. In this case, the Symantec Endpoint Protection software may be the key point of the issue on file server

     

    I found there is a fix available from Symantec website. You may check if the version of the antivirus is correct, and you may download and install this fix on the problematic server to see if it is helpful for you.

     

    Please visit the following Symantec Web site:

     

    Windows Servers stop accepting network connections with Symantec Endpoint Protection 11.0 installed

    http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007102613484948

     

    Windows Server 2008 network shares become unresponsive with Symantec Endpoint Protection 11 or Symantec Anti-Virus 10.2 client installed and Auto-Protect enabled

    http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/acb1ac0cabfc43278825746c006bc61a?OpenDocument

     

    Network shares become unresponsive on Windows Server 2008 32-bit with Symantec Endpoint Protection 11 Auto-Protect enabled

    http://service1.symantec.com/support/ent-security.nsf/docid/2008061812370848?Open&seg=ent

     

    If the issue still exists after the fix is applied, I would like to suggest you disable or uninstall the antivirus and then monitor if the issue will re-occur.

    Hope it helps.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    Monday, January 25, 2010 6:27 AM
  • No Symantec on the file server. DNS is working, I can ping the file server by name and/or IP address. I can RDP into the file server by either. When trying to connect to the share, niether the UNC path is dns name or UNC with IP address work.

    Could there be something on the Watchguard firewall blocking traffic on a specific file sharing port? It allows DNS, and RDP traffic, but maybe a different port is needed for file sharing?

    Thanks,

    Dennis Robare
    Monday, January 25, 2010 2:27 PM
  • No luck. DNS is working.
    Monday, January 25, 2010 2:27 PM
  • Hi Dennies,

    The following ports are associated with file sharing and server message block (SMB) communications:
    • Microsoft file sharing SMB: User Datagram Protocol (UDP) ports from 135 through 139 and Transmission Control Protocol (TCP) ports from 135 through 139.
    • Direct-hosted SMB traffic without a network basic input/output system (NetBIOS): port 445 (TCP and UDP)

    Please check on the Watchguard firewall to ensure the above pots are not blocked.

    Hope it helps.


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by DenRobare Tuesday, January 26, 2010 4:01 PM
    Tuesday, January 26, 2010 6:33 AM
  • Hey David,

    Thanks, went back to the Watchguard to check the policies and noticed that there were no policies setup for Mobile VPN connections. For some reason I thought that the Watchguard software auto setup these policies, which it does for the BOVPN. I created a policy for my dial in IP addresses and sure enough, connected right up after allowing traffic through.

    Thanks,

    Dennis
    Tuesday, January 26, 2010 4:03 PM
  • Hi Dennis,

    Glad to hear that you have resolved the issue with my help.

    If you have any other question, please welcome to the TechNet forum again. Thanks.
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, January 27, 2010 2:03 AM