Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have set up a Windows SBS 2003 domain (LAN) and a stand-alone Windows 2008 Server (web server) at another location (workgroup). I established PPTP VPN connection (SBS dials web server) over which users from LAN should be able to access web server. On web server I enabled TCP/IPv4 and File and Printer sharing protocol. It has a few external addresses (one of them is default) AND one local address (192.x.x.x) assigned to network adapter. Firewall allows port 445 for file sharing.

There's the problem - I can not enable web server file shares to be visible to LAN users and ONLY to LAN users:

  1. From SBS I can access webserver but I cannot access webserver from LAN workstations (XP, Vista). I have had same configuration - I have just replaced old (web server) Windows 2003 server with 2008 so SBS settings are the same (static route, DNS etc.). How can I enable file sharing on web server for LAN workstations?
  2. Now I have opened File and printer sharing to the internet which is of course totaly unsecure. I tried to secure the tunnel so I moved RAS (VPN) connection (Network Center) on web server to "Private" profile and moved firewall port 445 to "Private" profile but suddenly file sharing does not work and I cannot telnet webserver on port 445. How can I secure file sharing so I do not have to open it to the internet?
share|improve this question

4 Answers 4

While it's possible to do what you're trying to do strictly with RRAS and the Windows Firewall, it's going to be a fairly complex configuration, and will not be secure if not properly configured. You may find that operating system patches impact the functionality, as well. I don't know that I'd be very trusting that this, once setup, would continue to work properly in the face of patches.

To my mind, you would spend a lot less time on this if you invested in a hardware firewall / VPN appliance to sit in front of the remote web server computer to terminate a VPN there. If you're able to do that, you'll end up with a solution that I would expect to be a lot more robust.

share|improve this answer
    
I had no experience setting up a VPN, yet I was able to set up RRAS on Windows Server and establish a working VPN with file shares over the Internet with Windows 7 with just a few hours of tinkering. I ensured all firewall exceptions referencing port 445 are either disabled (such as Terminal Services Licensing, which leaves port 445 wide open to the internet) or scoped to allow only traffic from my local subnet and VPN client address pool, as defined in RRAS. As long as only people with user accounts are allowed to log in to the VPN, then that should be quite secure. –  Triynko Sep 27 '12 at 17:19
    
The only real problem I encountered, was that Windows 7 seems to get the routing tables wrong if I use a split tunnel by disabling the "Use default gateway on remote network" option on the client connection, so my normal internet traffic isn't sent over the VPN. The problem is that it was then failing to route any traffic through the VPN gatway, but that's easily fixed by running a "route add" command with the right destination address and gateway. I just think people are making this out to be more difficult than it actually is. –  Triynko Sep 27 '12 at 17:23

I may not have an answer but maybe I have a working model of one. I did this with no real changes to anything and it probably is as insecure as you can get. But I have tried to access it from various systems over the internet and i cannot connect without the proper authentication.

I always get prompted for a user name and password. All users in the system are setup as normal users, not admins. The few problems I have hit have always tracked back to ports being blocked. access is through //ipaddress/sharedfolder where the folder has to be shared to the user who accesses it. So far this seems to inherit permissions properly and no one can get to anything they shouldn't.

the same setup using a VPN also worked but was a lot more trouble and provided no more security since the users all insist that the gateway be open at their end to allow them access to the internet and outlook through their local ISP. so it was only a >V"semi-private"N< to start with

If someone has a better setup, I would love to know how to do it. This was a sheer desperation attempt to resolve issues that came up after upgrading to server 2008 R2. It appears to work somewhat like they describe the new Direct Access but without the dual NIC’s and the active domain controllers. I am worse than a "novice" so I can only tell you that after a week of "bleeding eyes" I finally got the server and the clients to "talk". But it was WITH a vpn.

Another week of various trial and error before I realized one day that I wasn't even using the vpn yet I still had access. The results are steady connects from anywhere with no vpn. The remote systems connect to the Server as soon as they are turned on and connect to the Internet.

Occasionally (about every 2 weeks) a user gets prompted to enter their network password which is fine by me as that ensures that the system is still in the hands of the owner. From the server looking outward it seems as if they are connected via a local network.

I can see them and they can see the server which is all I was after. I do not have "offline files" enabled so this isn’t it either.

The clients are all windows 7, the server is a server 2008R2 Std. If anyone else has a similar setup I would like to know how I can make this one better.

share|improve this answer

I'm with Evan on this one. Use routers that can act as VPN endpoints. I like Drayteks, though these days all but entry level routers will do VPNs. Using a hardware VPN makes the routing very straightforward.

JR

share|improve this answer

I just did this with everything built into Windows Server. Absolutely no need for hardware VPNs or expensive 3rd party software at all. I did this all with a single NIC on my web server.

Once you set up the VPN in Routing and Remote access and get your client connected, there are two main steps you need to take to ensure the files can be accessed.

First, your firewall exception, which allows access on port 445 (file sharing), should be on your public network, but the SCOPE should be set to either local subnet or better yet, to a range of static addresses assigned to your VPN in routing and remote access settings. Clients connecting to your VPN will have those pre-defined addresses, and so your firewall exception's scope can be set to only allow those through.

If all traffic is routed over your VPN, that may be enough, bur if you're like me and use split tunneling, so Internet traffic routes normallly and only stuff targetted to your VPN goes through the tunnel, then you may need to also make sure that when you type in a domain name or IP address in Windows explorer to access the file share... that the traffic for that address is actually going through the VPN. I found, at least on Windows 7 clients, that it gets the routes wrong by default. To fix it, I had to delete the bad route, and add the correct one. To do this, open an elevated command propmpt and take a look at the output of a "route print" command. There, you'll be able to see a list of interfaces, and IPv4 routes, including various gateways. If you VPN server's (webserver with fileshares) IP address is represented as [VPN.IP] and it's gateway is represented as [VPN.GATEWAY]. Then you just run "route delete [VPN.IP]" and then run "route add [VPN.IP] mask 255.255.255.255 [VPN.GATEWAY] IF [VPN_INTERFACE_#]". The VPN_INTERFACE_# can be obtained from the list of interfaces you saw in "route print". In any case, this directs all traffic targetted at "[VPN.IP]" through the VPN's gateway on the VPN's interface.

share|improve this answer
    
BTW, please note that I also noticed Terminal Services Licensing has an exception in the firewall that leaves port 445 wide open to the internet, so please sort your firewall by PORT and check the scope of everything that opens port 445. It's a major security hole IMO. –  Triynko Sep 25 '12 at 22:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.