1

We’ve come across this question fairly often at Load Impact, so I thought I’d add it to the Stack Overflow community to make it easier to find.

Q: I have a site that is not accessible from the Internet but which is behind a firewall. I want to run a Load Impact load test on it, generating traffic from the cloud, but I want to make sure noone else can access the site while the load test is running. How do I configure my firewall so it only forwards Load Impact traffic to my site?

Ragnar
  • 1,122
  • 1
  • 9
  • 16

1 Answers1

1

As Load Impact allocates load generator instances dynamically from cloud providers such as Amazon AWS and Rackspace, you don't know what source IP addresses the load generators in your test will be using.

What you can do if you have a firewall that you need to configure to let Load Impact traffic through is one of these things:

  1. Open up your firewall to the whole range of AWS IP addresses used by the load zones where you want to run your load test from. Note that Rackspace do not disclose their IP ranges, so if you want to test using Rackspace load zones there is unfortunately no way at all to know the IP ranges that will be used by the load generators. The drawback with this method is that even if you use AWS to generate traffic, you will have to open up your firewall to a pretty huge IP range.

  2. Use HTTP headers, URL query parameters, or something else about your generated traffic to send unique data (i.e. some kind of token) that identifies the traffic as belonging to your load test, then configure your firewall to look for this data in incoming traffic. Note that this requires that your firewall has support for scanning application payload data and apply rules based on what it finds. It also requires that your firewall either terminates SSL connections or that you use unencrypted HTTP, or the firewall will not be able to inspect the traffic.

  3. Add your firewall rules immediately after starting the test, when you know what IP addresses the test is using.

Below are more detailed descriptions on how to perform each of the different alternatives

1. Opening up your firewall to all IPs potentially used in the test

Here, you need to look at what AWS load zones you are using, and then find what IP address ranges these AWS data centers host. See http://support.loadimpact.com/knowledgebase/articles/174262-what-ip-addresses-do-load-impact-use-to-generate-l for more information about IP ranges used by AWS.

2. Using HTTP headers, URL query parameters to send an identifying token

You can add custom HTTP headers to any request in your user scenario code like this:

http.request_batch({
  {"GET", "http://test.loadimpact.com/", headers={ ["X-Myheader"]="TOKEN_STRING"} }
}

You'll need to add the "headers=" parameter to every single request though.

If you're not dependent on having the simulated users in your load test pretend to be a certain user agent, you can also use the http.set_user_agent_string() function to set the "User-Agent" header for all subsequent requests. That header could then contain your token value and you would not have to modify every single HTTP request in your user scenario.

You might also use query parameters, if it doesn't interfere with the functionality of your application:

http.request_batch({
  {"GET", "http://test.loadimpact.com/?firewall_token=TOKEN_STRING" }
}

Another option could be to request content from a certain hostname that is not in the DNS, but your site would of course need to be configured to respond to requests for that hostname. This is how you do it on the Load Impact side:

-- Map a secret hostname to the IP of our server (need to do this if the hostname is not in the public DNS)
util.dns_remap('very_difficult.to.guess.hostname.com', '44.55.66.77')
-- Make all your requests go to this hostname
http.request_batch({
  {"GET", "https://very_difficult.to.guess.hostname.com" }
}

This would set the Host: header to contain the string "very_difficult.to.guess.hostname.com"

Of course, any of these solutions that relies on your firewall being able to inspect HTTP headers or similar, will not work unless your firewall terminates SSL traffic or the traffic is unencrypted.

3. Adding firewall rules after the start of the test

This may be the best method in many cases as it is fairly straightforward and should work in almost all cases plus it is reasonably secure. The drawback is that you need to reconfigure your firewall once for each load test you run. What it means is that you start the test and then find out what IPs the load generators are using, then quickly set up firewall rules that allows incoming traffic from those IPs. To facilitate this method, you might want to design your user scenarios so they do something like this:

if client.get_id() == 1 then
  log.info('Load generator IP address: ' .. client.get_load_generator_ip())
end
client.sleep(300)
...
[rest of user scenario]

This would cause each load generator to have client/VU thread #1 print out the IP address of the load generator in the "log" window on your test results page. All threads would wait 300 seconds (5 mins) before starting execution, giving you 5 minutes to update your firewall rules to let the traffic through from all IP addresses used by the generators.

Note that each client will in this case begin by sleeping 300 seconds, so the test rampup would be delayed by that long. The "Clients active" graph would be a bit misleading as it would also show clients that are still executing that initial sleep. If you want to avoid this you can skip the sleep() statement if you don't care about test results being correct the first minute or so during the test (when the VUs are going to be experiencing connection problems because the firewall is blocking them).

Ragnar
  • 1,122
  • 1
  • 9
  • 16