This will be an article written to future-me, when he needs to simulate a network with limited bandwidth and latency for the nth time and can’t easily find the exact software to do it.

This is the premise of the problem: you are developing a software (web, desktop, mobile, doesn’t matter which kind) and need to simulate a low bandwidth connection (maybe you’re testing a desktop software running through an internet VPN). Or you want to test how your webpage behaves on a high latency connection (maybe your users are using a satellite connection).

The simplest way I’ve found to do is using Wanem - the Wide Area Network emulator. It’s a simple enough software to figure out how to use, but in the interests of speeding up a bit of your time, I’ll just walk you through the steps needed to set up a few test scenarios using VirtualBox.

First of all, download the latest Wanem ISO from its official website. The latest stable version is quite old at the time of this writing (v2.2 released on 2009) but you can probably get away with using the latest beta (v3.0 beta2 released on 2014).

Create a new VirtualBox machine of type “Other Linux (32 bits)”, 512MB of RAM (should be more than enough for most tests) and no hard drive (Wanem runs completely from the live ISO). Select the ISO file as the CD, a run the VM. In a few minutes, the Wanem web interface should pop up.

Testing Between two Windows VMs

Say you have a Windows development VM and a separate Windows test VM (both local on your machine) and you want to test some network connection between them (let’s say, a database connection).

The easiest way to do this is the following:

1. Configure all three VMs to use a bridged network connection on their virtual NICs.

This is the easiest way to make sure the VMs can each connect to each other without messing around with virtual networks, NAT problems and so on.

You can use other kinds of network connections, just check the next point.

2. Make sure all VMs can ping each other.

This is the real requirement before making changes to the routing tables. This is mainly to ensure that your current setup is working and you won’t lose much time tracking down a wrongly attributed IP or a running firewall.

Both your VMs must be able to ping each other and ping the Wanem VM.

Bonus points for benchmarking your test scenario (on theoretically ideal network conditions) before performing the next steps.

Write down the IPs assigned to each VM. You can find out the IP of the Wanem VM by running a terminal on it.

3. Change the routing table on each VM such that all requests go through Wanem.

This is the magic step. Given the following existing configuration:

Run the next commands on an elevated prompt on each VM:

Notice that on each VM you must specify that the route to the other VM goes through Wanem.

4. Verify that the IP packets are going through Wanem.

The easiest way to do this is to add a delay on Wanem. Go to the Basic Mode configuration wizard on the Wanem VM, make sure the Choose Bandwidth is set to “Other” and specify a high delay (say, 1000 ms).

If the setup is correct, the round trip time (ping time) between the two VMs will be two times the delay.

Another option is to run a trace route (tracert on Windows) between the VMs, asserting that the first hop is the Wanem VM.

You can now run the tests of your software using the target bandwidth and latency, or use the more advanced network simulation config options (add jitter, packet loss and so on).

If the Wanem VM was configured to use bridged networking, than this procedure can also be used to test limited connections between physical machines on the same network, by executing step 3 on them.

Testing an Online Website

If you want to see the behavior of a website on limited connectivity, you can also Wanem by routing all your connections through it.

Let’s say you want to use a browser running on the test-vm (as above) to check the performance of the website. Do the following:

1. Modify the default gateway of the VM to point to Wanem.

There are two options for this. First one: statically specify the IP, mask and use as gateway the Wanem IP.

The second option is to modify on the fly the routing table. On an elevated command prompt:

route print
(notice the first line defining the current default gateway)
route delete 0.0.0.0 mask 0.0.0.0 10.100.0.1 
route add 0.0.0.0 mask 0.0.0.0 10.100.0.78

You can verify that this worked by using a ping or trace route, the same as in the previous case.