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.
Best Answer
That is not so complicated, but you will need a router (or switch with router capability) to do so, just for basic connectivity tests.
Just setup 5 LAN's on the router, one for each subnet and configure the router on each subnet to behave as if it is the WAN/VPN router for the site.
Then hook everything up.
Of course you will have only 1 router-hop where in the real setup there will be many, but for the connection logic of the VM's that won't make any difference. You can test all your VM's and/or applications in this way.
You can't really test the VPN's themselves, unless you have a bunch of VPN capable routers at your disposal. Even then your setup will look nothing like the real thing. I wouldn't bother with that.
Simulating slow/bad latency on a WAN link can be done through a Linux box as mxrx already mentioned in his answer.
This will also act as the router so you may want to setup a VLAN capable switch to provide the 5 subnets as VLAN's + 1 additional trunk-port onto which you configure the router-PC as a router on a stick. No expensive hardware-router required.
If you are not interested in doing simulated WAN performance tests you can take this approach too, using pfSense as a software router.