Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I work for a small insurance company that only has 2 offices. Right now, if something goes wrong in another office, it's just a short road trip. But...
This company is expanding, and will have 4-5 more offices across the US by year's end. My boss thinks the proper solution would be having all of the offices on a VPN for internet access, with the server hosted remotely. My concern is that I wouldn't be able to push out needed software/OS updates with a VPN since it's not an always on connection. His concern is that he doesn't want to have to have anything in-house, like a firewall or a network connection for all of the satellite offices to depend on.

Keep in mind, both myself and my boss have about as much networking experience as Paula Abdul. What would be the optimal setup in

share|improve this question

Generally speaking the strategies to connect remote offices (known as Wide Area Networking, or WAN) to a central office break down along the lines of dedicated versus non-dedicated connections. The lines are actually a little blurry because it's unlikely that your company would ever actually run the wires to the remote offices yourselves so, in reality, you're always relying on transit over someone else's network for remote connectivity. The degree to which that connectivity is dedicated to your use, though, can vary.

Traditional WAN connectivity has been done over "leased lines". These are data circuits provided by telecom companies that appear, for your purposes, to be dedicated point-to-point connections between your offices. (In reality, your data is typically multiplexed along with other data and transmitted via higher capacity circuits inside the telco's network.) These circuits are usually fairly reliable and typically are covered by a Service Level Agreement (SLA) describing how downtime will be handled and what level of service is being purchased (bandwidth, latency, uptime, etc). These circuits are also, traditionally, fairly expensive as compared to other methods of remote connectivity. This type of connectivity is strictly point-to-point data and no Internet connectivity is typically provided. Many providers offer the option of "managing" the device that connects your remote office to the telco network (known was Customer Premise Equipment, or CPE) such that the WAN connection can be considered "turn-key".

On the far end of the spectrum Virtual Private Networks (VPNs) allow for creating "virtual" networks across the Internet. You could, in theory, obtain Internet service from any ISP for each remote office and, because any Internet endpoint can communicate with any other Internet endpoint, use VPN hardware devices or software to create a virtual network over the Internet. Costs can be very good, however you end up with no guarantee of service reliability, bandwidth, latency, etc. The SLAs you might have with each individual ISP involved won't, typically, make any difference with respect to the overall service level achieved by the VPN because it's unlikely that you'll have SLAs with every network operator over which the VPN traverses. Each office, in a VPN scenario, ends up having Internet connectivity as a side-effect of having a connection to the Internet to support the VPN. You may opt, however, to run user Internet access through a central hub anyway to provide filtering or logging. A VPN can be "always on", however reliability isn't guaranteed.

In the middle of this spectrum are offerings like Multi-Protocol Label Switching (MPLS) (and, in prior years, Frame Relay) which provides the appearance of dedicated connectivity while, in actually, operating more like a VPN running over the MPLS provider's own network (commonly referred to as a "cloud"). Pricing is closer to that of traditional WAN connectivity for MPLS offerings, but the SLAs are typically much closer to those of traditional WAN connectivity as well. Many MPLS offerings come bundled with Internet access at each remote site but, as with VPN solutions, you may opt to aggregate user Internet requests centrally. Many MPLS providers offer the option to "manage" the CPE in the remote office, freeing you from any responsibility of maintaining that equipment.

In some geographic areas you can obtain very high speed WAN connectivity through services like metro-Ethernet. Typically these services take on characteristics of traditional WAN and VPN/MPLS-style connections. The SLAs can vary wildly based on the provider or the price-point chosen.

The specific answer for your company is going to depend on your bandwidth, latency, reliability, budget, and future growth/application needs. There is no "one size fits all" solution. I'd recommend getting quotations from a number of different vendors and asking a lot of questions. I'd be wary of long-term contracts unless you're sure that the solution you're choosing is suitable for your business throughout the duration of the contract.

You might want to consider getting a consultant involved to use "WAN simulator" hardware or software to simulate various types of WAN connections over which you can test your existing software applications. Knowing that your software is going to work over various types of WAN connections is something I'd consider critical prior to choosing a type of connection. You will spend a little money up-front but you can have piece of mind that your eventual WAN connectivity choice will be suitable for the business.

share|improve this answer

His concern is that he doesn't want to have to have anything in-house, like a firewall or a network connection for all of the satellite offices to depend on.

Well, you are going to have to have SOMETHING for some sort of network connectivity. Depending on the size of the offices i would suggest something like the ASA5505 if they are smaller <10 people. Or larger models for more people. Then your best bet is to setup a point to point vpn between all the offices.

You'll have a piece of equipment you are going to have to depend on to get internet access, so why not make it something you can setup a P2P vpn on?

share|improve this answer
Don't forget that you can throw money at providers to "manage" your CPE. (I think it's a waste of money in a lot of situations, personally, but the option is there.) – Evan Anderson Mar 1 '11 at 16:30
Right, but he doesn't want to have a server in house. He wants to use something like to host the VPN server. That just means less job security for me :) – werm Mar 1 '11 at 17:43
@werm the whole point is you don't have a vpn server, you use your router/firewall/nat devices as vpn endpoints. – Zypher Mar 1 '11 at 18:14
I see. That'll give me a reason to say "Check out the cost savings I implemented!" Sorry I'm being dense. They hired me as a web developer. I just became the default IT guy... – werm Mar 1 '11 at 21:36

It sounds like you need to research the difference between Site-to-Site VPN and just running the VPN client. With a site-to-site they'll be just like on your network and any startup actions (GP initiated installs, etc) will work, albeit they'll run slower over the WAN. You should look at if your bandwidth in your central office is sufficient for this first. For remote offices site-to-site is best. Buy compatible routers that have VPN features.

I don't understand your boss's requirements. If you guys are doing any kind of file sharing with the main office then they'll need to be dependent on the central office. A hybrid approach is a small file server at each local with network mappings to your central office. Its faster and they still would have access to the central office. Of course you need to backup this server to something, like a local NAS or tape drive.

Lastly, you don't need 'always on' VPN to push anything out. This entirely depends on what you're using to push out updates. There are a lot of ways to do this, many of which don't require always on. Depending on the size of your updates you might want to store these on the remote file server and write your script to install from there instead of everyone downloading via the WAN.

share|improve this answer

I look after several clients with far-spread offices remotely-connected by site-to-site IPSec tunnels in a hub/spoke topology -- each spoke (remote office) can connect to resources at the hub (HQ), but not each other. Each location has an Internet connection (T1s and ADSL), a small, inexpensive firewall/router appliance that maintains the IPSec tunnel and provides the office with Internet access.

Since each remote location's needs are minimal, a Terminal Server suits their needs well, and as such, we do split tunneling primarily. i.e. the only traffic that's routed over the VPN tunnel is to the Terminal Server cluster that's physically located at the HQ office, everything else goes out through the Internet directly. This works quite well: the firewall rules are tight enough that the only traffic permitted at the HQ location are directly related to the Terminal Server (where they do most of their work), which means that I'm not worrying about bandwidth at HQ being consumed by a torrent client somewhere or viruses spreading via file shares. Some others may point out that proper end-user policies/enforcement etc. would eliminate these risks at the source, but in our case these remote offices operate with some autonomy, and the manpower/resources just aren't there to provide regular/daily monitoring or service calls.

However, this scenario I've described may not work well for you: you may have applications, processes, and policies that are more tightly-coupled to the main office and require/expect "LAN-like" network conditions. For that, you may need to look into more robust WAN services/service levels such as those suggested by Evan.

share|improve this answer

VPN is really for external users to connect to the internal network. For the converse situation, remote desktop and services like could be viable. They are simple and free.

I use And if you are going to be in my case where many of the sales pesonnel carry desktops all over the world, then VPN is not going to cut it. In the long run, still took over the VPN infrastruture we have.

As a side story, we managed to recover a lost laptop via because the unsuspecting theif left it connected to the internet.

share|improve this answer

Your Answer


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

Not the answer you're looking for? Browse other questions tagged or ask your own question.