Sorry to flood the board with so many questions. I feel like I'm spamming you guys. I promise that after this one I'll try to go at least a week without bugging you for more assistance (and I'm still working on that card transfer thing, thanks for the help).

I've been asked by a family friend to help support his law office. He has a very rudimentary setup, with a Windows 2003 server and a few workstations. Unfortunately he tends to use the server as a workstation its self, but that's another issue.

So this attorney has bankruptcy software that he can install on the server, and all the other workstations can get client software to connect back to the server. That's fine, I'm sure I'll be able to figure that one out.

The issue is this: the attorney has two other remote offices. He wants those users to be able to use the software too. Instead of creating a huge mess and paying for more expensive licenses for the software (about $500 for each primary installation), he'd like to try to centralize it as much as possible. Sadly, I'm not very familiar with how to do that.

The only solution I could come up with was VPN. But I have no clue how to set that up. The only solution I could find, which looked like a decent one, was Hamachi, by LogMeIn. It would be a recurring $400 a year, though. On the other hand, the attorney also wanted an easy way to share files, and a VPN would make it easier.

Is there another solution I'm not thinking of? (I'm sure there is)

I happen to (as of recently) work for a company that makes really excellent and powerful VPN software, but your attorney sounds like he's looking for something super cheap, which we ain't.

Keep in mind what the purpose of a VPN is: To connect someone who's outside the firewall, to your internal network, and do it safely and securely.

Every piece of VPN software will do that, and it's even possible to set up a VPN without spending any money at all (Server 2003 has an IPSec VPN built in; it's just a pain to set up.)

A VPN doesn't solve your client/server licensing problem unless the client licenses are free. Are they?

You want to install an IPSec LAN-to-LAN VPN.

Without knowing more details about your client's networks, I can't provide much in the way of details, but Linux, FreeBSD, and OpenBSD all have mature IPSec stacks that should be able to support this.

Basically, you'd install a machine at each site, set up IPSec tunnels between them, and fiddle about with the routing a little.

If you want to spend money on a supported solution, your price-performer is probably, sadly, a SonicWall device.

Keep in mind, though, that the performance might make the remote user experience very bad. The users at his home office are likely to be running at 100Mbps at least, whereas remote users are going to be running at the lesser of the speeds of their internet connections — and don't forget that upload speeds will be relevant here (I don't know which direction is likely to have more traffic) — and it's going to be a high latency connection, too.

All good points. I'll have to check what speeds the offices are rated at.

Tony: I'll look into that IPSec VPN and whether it's more trouble than I can handle

I do believe that the client licenses are free, but frankly I have no idea. They have a few of these vertical applications that I have never heard of before, so most of my challenge in supporting these offices has been familiarizing myself with these applications and what they can/cannot offer them.

hak5 did some vpn explaining recently: http://www.hak5.org/episodes/episode-605

Once you have a VPN set up, you could park a couple remote desktop sessions in the office and the remote employees can run the application that way.

Where you park the sessions is flexible: I've seen offices with a couple older computers on a KVM switch. It was ugly, but it worked. Just needed someone to occasionally power cycle the machines if they hung.

Haven't worked with anything recently from them, but Watchguard had some really easy VPN hardware.

-jk

Linked from the Hak5 article, there is a good aggregation of links on how to set up VPNs with Windows Server:

http://technet.microsoft.com/en-us/network/bb545655.aspx

Possibly helpful to Dignan.

If remote destktop is your solution, then you can skip the VPN entirely. It's possible to arrange for accessing remote desktops directly from the internet, via several methods, some more secure than others.

I don't recommend that, though. If the client seats for the Bankruptcy software are free, then you're better off setting up the VPN.

Thanks, guys. Those Hak5 guys really seem to know their stuff. I don't usually tune in because most of it either goes over my head or isn't of interest to me. I might have to pay a little closer attention from now on I'll check it out.

Ugh.

So I went back to the attorney with this solution in place, all ready to set up his VPN. It's then that I was given further information that he hadn't seen to be relevant previously: he plans to do a lot of outsourcing. He currently has someone in the Philippines logging into his server at night (with nearly full access to his freaking server) and entering data into this bankruptcy software.

So sure, it wouldn't be tough to instruct this guy remotely on how to set up his side of the VPN, but we'd have to send him all the software needed too (there are a couple other applications he'd need).

Add to this some other fun issues:

It seems the previous tech guy has done his best to make himself pretty indispensable in the way he's set up this guy's system. First of all, it appears the attorney doesn't have a static IP. I checked his RDP settings that he uses from outside the office, and the address he's using for the server follows this format: "lastnameofattorney.previoustechguyscompany.com"

So I'm assuming that the guy before me set up a way on his web server to get around the dynamic IP issue, but I'm not sure because I haven't spoken with him. This guy set the office up with two logins to the server that they only use through RDP (there's no monitor or input devices attached to it). The previous tech guy has told them that he'll set up five other users on the server for something like $1000.


Okay, so after all that, my next thought was to simply do what JK was getting at: abandon the VPN idea and simply set up some computers that remote users could log into. It would make things a log simpler. We wouldn't have to install the client software on all these people's computers, and we might even save on the additional copies (I believe the client licenses are not free as I'd thought).

The problem with this plan is what I found after thinking of it: this attorney's office has a terrible internet connection. A speed test resulted in about 1700/550Kbps. I think he's using DSL. A VPN would have been terribly slow, let alone 2-3 remote sessions.

So, thoughts?

Remote desktop works surprisingly well on low bandwidth connections. Videos and images can be a stretch, but it does degrade pretty gracefully. It's less secure than a VPN, but it's also easier to set up. 1k sounds about right for five terminal services licenses, which is probably the Right Way to do things if you're not going with a VPN. MSFT charges about the same for an XP license as a terminal services CAL, and terminal services will probably scale better. You could get into VMWare and virtual desktops, but microsoft still wants their pound of flesh.

It sounds like the previous tech guy just set up dynamic dns using his DNS provider. Just set up an account with dyndns or other dynamic DNS provider and set the router to update it.

I'd happily go with Terminal Server, as long as the app works with it (not everything does).

I did what you're trying to do a while ago. I stumbled upon the same problems as you did: LAN-to-LAN only seems to work well when all parties are using static IP addresses.

So I did it differently. I bought a decent Draytek router (yes, here I am again with Draytek, but I'm sure there are other brands that can do this just as good). I made a DynDNS account. I fed the DynDNS account details to the Draytek router. Now I could always find the router by using the DynDNS system (<insert name here>.dyndns.org)
Then I set up the built in VPN server of the Draytek router. I could choose between 3 types of VPN: PPTP (windows' type of VPN), IPSec or L2TP. I ended up choosing PPTP which is not the safest VPN method around, but it does have one advantage: It's build standard into any Windows version since XP (and probably even further back).

Once this was implemented I could simply setup a 'Dial-up VPN connection' to the Dyndns address, entered my login and password and voila, I became part of the LAN, which allowed me to access the apps 'locally'.

This is probably also what you need. If you need more security, I would use IPSec though. The setup should be similar, just a little more time consuming since you would need to use external 'dial up VPN' software rather than the built-in one that's in Windows. (FYI, I've read that Windows 7 has now also included an IPSec client... just a thought...)

How does the Filipino access the server? Why would that not work for the other people?

Also, I recently stumbled across a free IPSec client for Windows, Linux, and BSD that supports a lot of vendor extensions: ShrewSoft VPN Client.

He accesses it by logging in with the same user account that everyone else uses at the moment. Right now, only one person at a time can use the software, because it's just on the server under one account. Whenever someone else logs in, it cuts off the currently logged in person.

Not actually technical related but are you allowed to do that? Have somebody outside of the US accessing data on US citizens without disclosure?

I don't have a clue, but I would hope this guy would know.

Right, but he's accessing the system from a remote network. Is he using a VPN? Is there a hole for RDP poked through the lawyer's firewall?

He definitely doesn't have a VPN. As for the firewall, I couldn't tell you. He's just running a Belkin wireless router (that he didn't know the login to), so I couldn't see if there was any port forwarding or anything.

*edit*
It does look like the way he's set up he has two gateways. The server is 192.168.0.1, and the router is 192.168.1.1. Problem in the future?

How is the server a gateway?

Looks more like 2 subnets. Or one very very large one (Class B). Or he's using a non-standard subnet mask, like 255.255.254.0. If the office has very few computers, say, less than 50, none of the above is appropriate. The non-standard netmask is never appropriate, but it will technically "work" until you get real equipment.

Sorry, got my terminology mixed up. And like I said, I'm new to some of this. Lectric's summary is accurate, I believe.

Huh? I'm not sure what you're getting at. Subnets need to not overlap, and every host needs to have the same netmask. There's no requirement that every network has to be a class C.

Agreed. That was the whole point of implementing CIDR back in the day.

Okay, I've given up setting up a VPN using this guy's equipment. You can't enable the VPN snap-in if you have ICS enabled on the server, which he does. I made an executive decision, and decided that I'd have to completely rework his network (which has other people who sublease office space from him), and the downtime needed to do that was not going to be satisfactory to this guy.

So I downloaded and set up LogMeIn's Hamachi service, which had me set up with a VPN in a matter of minutes. It's free for non-commercial use, so it's up to him if he wants to pay the $200 a year to keep it up.

Just thought I'd update with the situation.

*edit*
By the way, I don't suppose there's any way at all to share files in Windows across workgroups, is there?

I didn't know that LogMeIn was a VPN. I thought it was just a remote desktop solution. I'll check it out in more detail now. Either way, you've done good and solved your problem easily. Congrats!

Yes, you can share files across workgroups or even across domains. Just connect to the resource that you wanna connect to by IP address instead of by name (heck, in some cases, even doing it by name will still work, but IP address will always work).

Like so:

Start
Run
\\ser.ver.ip.adr\sharename\

Make sure they're all backslashes and not forward slashes.

It'll prompt you for credentials, make sure you supply credentials that are appropriate for the computer and/or domain and the share you're connecting *to*.

Of course you have to have a ROUTE TO the server ip address. For example, if you're on the wrong side of a firewall or a router, you won't get in without a VPN.

I checked out LogMeIn, and I see that their new hosted "Hamachi" service is in fact a real VPN. It looks extremely compelling, especially the "free for non commercial use" part. Thanks for the heads up.

It was mentioned here quite a long time ago, I assume the LogMeIn people bought it.

No problem. I'd totally forgotten about that previous empeg board thread.

I have been using LogMeIn's remote control software for family members, though they recently made it a little more difficult with the free product.

I'm really liking the simplicity of Hamachi. I think I could have eventually gotten his network set up correctly, but I think it would have taken hours, whereas I had him set up with a VPN in about 10 minutes with this thing.

And thanks for the help on shares across workgroups. The only thing I have to figure out is how Hamachi hands out IP addresses. I'm hopeful that you can give static IPs to the VPN clients.

It's possible you won't need the IP addresses, and just doing \\computername\sharename might work. Try that first. Clients and server must be connected via the Hamachi service first, of course.

Everything worked just fine, and I had his three remote users set up in about 20 minutes total.

I did have problems on one computer connecting to the shares, but I think that was a Windows networking issue that was independent of Hamachi.

Overall an excellent experience with this software. The only problem now is the aforementioned slow speeds. I have to get these two offices much faster connections...

Usually that's a name-resolution problem. And for workgroups, that's usually a WINS issue. Make sure the computer is set to do (...looks up what it's called...) "Enable NETBIOS over TCP/IP", deep in the advanced TCP settings.

Thanks for all the help so far. At the moment, I'm being driven insane by Windows networking (nothing surprising about that). This is the error I'm getting on two of the computers I'm trying to connect to shares over the VPN:


One computer is running Vista, the other XP. I've tried both with their own workgroup name and with the same as the source network. Both exhibit the same behavior: if you just type in the server address, you can see all the printers and share folders that exist on the server, but as soon as you try to open any of those folder, it hangs for an extremely long time, then comes up with the above error.

Tony, I've tried you recommendation in your last post, but Hamachi started complaining about incorrect adapter settings and couldn't connect to the server at all anymore.

*edit*
Regarding permissions, I don't think that's the issue. I'm testing this all out on a folder that gives full control to Everyone. I've been able to get other computers with similar setups to connect.

For folder sharing to work in Windows, there are at least five things that need to happen:

1. The file sharing feature must be enabled on the computer that's sharing the folder.
2. The folder being shared must have its "Sharing Permissions" set properly.
3. The folder being shared must have its NTFS disk/file permissions set properly.
4. The Windows Firewall must have the correct openings for folder sharing. (This is done for you by default when you enable the sharing feature.)
5. The "Server" service must be running on the computer that's sharing the folder. (This is default on all systems.)

There may be other things that need to be enabled. I've had situations like yours, when I still get errors like you describe even when I've met all of the above conditions. Usually, in times like that, I give up and sneakernet the files.

Thanks for the response.

Those all sound right to me, but they all seem to apply to the server computer. What confuses me is that some computers are able to access the files just fine, even though they're set up the same way (AFAICT) as the computers that are acting up.

To further confuse things, the computer I'm writing this on, one of the problem PCs, WAS able to connect to the shares and view the files for about 5 minutes earlier. But then, just a few minutes later, could not. Ugh.

Make sure you've disabled, er, whatever that protocol is that isn't TCP/IP (NetBEUI?). I don't know whether XP/Vista still have it enabled by default, but machines that have it enabled will, from the point of view of a TCP/IP-orientated sysadmin, quite literally conspire behind your back to confuse you about their name resolution.

Peter

Check your security permissions in addition to the sharing permissions. I know that for my systems to work properly I had to do a song and dance...

The computer in question: Is it on the same LAN as the server, or is it one of the VPN machines?

If the latter, I would suspect brief connectivity drops that mess up the file sharing.

You guys (starting with Tony) are totally right. It was a security permissions thing. I'd set the sharing permissions but not the security ones, which is annoying.

But the major confusion was this: when I set the VPN up initially, I had about four computers connecting to the VPN and the server, and seeing all the files I wanted them to. Between then and today, I had changed absolutely nothing, but now those computers couldn't see those files. It's like something in the computer realized "oh, hey! I forgot that I need to apply the security permissions too! Well lets stop this now, and give off an error message with little to no meaning."

It appears to be working now, but naturally I have no faith in Windows' file sharing. I never did before, though, and this experience hasn't helped.

Windows networking is shite. You can optionally remove the word "networking" from that last sentence...