My question is in my answer to someone else's question. I am just trying to create a reliable secure connection between a Windows Server 2008 system and the clients who access it. What we had working perfectly for years on Windows Server 2003 and Window Server 2008 R1 completely stopped with R2. I am working under the assumption this is related to the use of SMB protocols but I am not certain. Fortunately, nothing they access requires much security but even if it did, the same username/password requirements as well as the fact that these users must be listed on the server seems to prevent any unauthorized access.
Still, I am more comfortable with using a VPN and I am perplexed as to why something that used to be a "done deal" with windows is now going to require the use of additional hardware to provide a working interface for the VPN to connect to. What happened to the normal RRAS setups with Windows Server 2008R2?
As currently configured, the users 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 Windows Server 2008 R2. It appears to work somewhat like they describe the new Direct Access but without the dual NICs 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 and the server is Windows Server 2008 R2 Standard Edition. If anyone else has a similar setup I would like to know how I can make this one better.
For bonus points I wish someone could explain to me why, on some users' laptops in some locations, the drive mapping MUST be done as \\servername\shared folder. But in other locations on the same laptop the mapping must be done \\IP address\shared folder.
In both cases it is the same laptop connecting to the same server and the same folder.
Additionally, even the locations that will NOT map to the IP, if I try to create a VPN, the VPN must connect to the IP. It never accepts the server's hostname.
This has to be in some way related to the router or ISP because it is location specific. If they take their laptop across the street, it goes back to working correctly with only the IP.
We do not have a WINS server and the server name is only kept within the server itself. Any way to reconcile this down to using just the IP would be welcome as the places where the mapping uses the server name are few and far between but still enough to cause problems.
Clarifications in response to @EvanAnderson:
I do not have a problem with using a VPN. I meant to make that clear from the start that I would rather be doing so if I could get them to work. My problems are that the VPNs will no longer work reliably with Windows Server 2008 R2. And I am sure it is my lack of knowledge that is at the root of the problem. If I had known beforehand the changes that had been made between Windows Server 2008 and 2008 R2 (which I had assumed just included the latest Service Packs for 2008) I would never have done this. When we ordered the new system I would have insisted on either R1 or done the install myself because R2 is where the "bottom fell out".
-
The
VPNissues are in almost every case related to people using "cellular routers" commonly called MiFi units. In places where there are stillVPNproblems with hardwired routers, it is true that I have tracked many of the issues back to blocked ports, etc. However, I am stuck in any event, because the MiFi units do not have the ability to control the port blocks (or if they do they won't share them with me, I've tried) or Hotel/Motel/Condo/etc units where once again, I have little or no control over what is allowed to pass through. -
In one specific instance I spent a whole day at a large apartment complex where two different users could not connect. It turned out that this complex buys their Internet access in "bulk" and resells it. I don't know enough details to help but I believe either the concentrators or other amplifiers used to get a large number of users into a small piece of bandwidth while each user still has "their own" cable modem, is in some way causing the problem. But no one will "take credit" even though it all worked fine until this R2 upgrade.
You are quite correct in that the setup I have working is "worse" than terrible but it at least got everyone back online long enough for me to have time to research the other possible solutions. So far, my best bet still seems to be that I should dump Windows Server 2008 R2 and reload R1. Unfortunately this has the inherent risk of "breaking" something that is currently "working" even though it is not right, so I am trying to see if I can "ease into" a correct fix without removing Windows Server R2.
That was what I had hoped to find here. Someone who could tell me first why Windows Server 2008 R2 failed, and what I could do to make it work. I am still leaning toward the SMB vs NFS file structure. I wish I still had a working Windows Server 2008 R1 system so I could check to see what protocol was used. Unfortunately, that was sitting here when they handed me the controls and orders to "keep it running 24/7/365 no matter what"
One other point is the VPN setup. On Windows Server 2008 R1 under security, we used to have checked both CHAP and CHAP-V2. On Windows Server 2008 R2 only CHAP-V2 works; if CHAP is even checked at all, the VPN won't connect. We are also limited to PTPT only, IKE and others wont connect at all and this may be normal. But the cellular MiFi units, older routers, and the places where they try to cram too many people into as small a footprint as possible, these are where the problems all came up.
If this in any way helps to explain why the problems with connecting happened at all maybe I could find a way to fix it in Windows Server 2008 R2. Any help or knowledge passed along is gratefully accepted! Even if that advice is to just go back to Windows Server 2008 R1 and not fight with it.
Best Answer
It sounds like you're accessing SMB file shares on a standalone (non-Domain member) Windows Server machine over the Internet w/o using a VPN. This is a very odd configuration and not one that I'd recommend to anyone. I'm not sure I understand your reasoning behind not wanting to use a VPN.
You are going to find that various ISPs, wireless hotspot providers, etc, block NetBIOS over TCP and SMB over TCP (TCP ports 139 and 445, respectively) as a matter of policy. Setting security aside, using a VPN allows you to have arbitrary communication between your servers and clients w/o worrying about network providers filtering your traffic. This, alone, should be reason enough to be using a VPN.
Name resolution via NetBIOS broadcast (unqualified names) isn't going to work at all over the Internet. DNS name resolution will work (fully qualified name or unqualified name if you've hard-set the DNS suffix on the client) if the server computer's name resolves in DNS. Specifying the server's name as its IP address in the UNC should always work anywhere that NetBIOS over TCP and/or SMB over TCP aren't blocked.
If you're going to use a VPN on Windows and want unqualified names to resolve you'll either need to use WINS or configure the clients to qualify names based on the domain name of the server computer. I feel like part of your reluctance to using a VPN might have to do with spotty name resolution. Putting up a WINS server would go a long way toward making name resolution via a VPN work better.
Your architecture here is really, really bizarre and not at all a "best practice". If your users can't handle using a VPN then you might want to consider using IPSEC (albeit, in your non-domain environment you're going to have to hand-configure a lot of things to make that work).