Measuring IPsec Dynamics on VPN Gateways

By Daniel Munteanu | IPsec is not going away anytime soon, despite many past predictions of its obsolesce. IPsec is deployed across multiple environments ranging from the traditional enterprise and mobile/carrier scenarios, and now in data centers and cloud infrastructures.

Leaving aside the market adoption and evolution of IPsec (which might be an interesting dedicated blog topic), in this blog, we’ll explore the outcomes that different environments trigger when using IPsec and the growing diversity of the technology.

While working with customers to validate IPsec in different kinds of deployments, lately there is a recurring set of requirements that are targeted at testing the dynamic nature of both the data plane path as well as the IPsec tunnel itself.

Therefore, I wanted to share some of my experience with such testing scenarios and briefly describe how to assess the capability of a VPN gateway to handle IPsec tunneling in dynamic environments.

REAL-LIFE ENVIRONMENTS ARE DYNAMIC

First, I will start with the data plane part and how to make sure that data plane traffic goes hand in hand with the IPsec tunnel establishment.

Testing the capability of a VPN gateway to handle a certain number of new IPsec tunnels per second (i.e., initialization rate) is not really complete unless the data plane traffic is synchronized with the tunnel set up so that traffic will start as soon as the IPsec tunnel is up. Obviously, there is also the other approach where you can first bring up all the IPsec tunnels and only then start the data plane traffic (in which case, while the performance figure might look good on the paper, its real-life applicability is limited).

Indeed, in real production environments (or most of them) IPsec tunnels are brought up to perform data plane traffic and not for the sake of having yet another underutilized encapsulation/tunneling/protected communication channel.

The other dynamic aspect is the fact that across the lifecycle of any VPN gateway, tunnel sessions are connecting and disconnecting on a continuous basis (in some environments more, in others less), putting additional stress on the stability of the VPN gateway device. Therefore, similar to the previous point, the question is again, how will the VPN gateway cope with such dynamic sessions across long periods of time?

A test tool having the ability to both emulate real user behavior as well as dynamic sessions is needed to run such complex, yet mandatory, tests and accurately validate the real capabilities of any device offering IPsec VPN gateway services.

TEST EXAMPLE: VALIDATING THE PERFORMANCE OF A VPN GATEWAY UNDER REAL-LIFE DYNAMIC CONDITIONS

In the below paragraphs we will use IxLoad, Ixia’s solution for testing multi-play services, application delivery platforms, and network security appliances, to test a real IPsec VPN gateway device (further referenced as the DUT, or device under tests).

IxLoad can emulate the entire environment necessary to properly test the DUT for the previously described conditions, namely:

Therefore, in the next paragraphs, we will see how these dynamic conditions are configured as well as interpret the test results.

We will start from an already configured IxLoad test, but if you do not have it configured or don’t know how to do it, don’t panic, there are plenty of canned templates to start from in the IxLoad client application under File -> New -> Templates -> IPsec folder as per the below screenshot:

IPsec1

First, let’s look at the initial dynamic requirement and make sure that traffic will start as soon as each tunnel is up. Under the NetTraffic global Settings (see below screenshot), the control plane behavior can be selected.

IPsec2

The recommended option for our requirement is the second one (Create Interface with User, or also referenced as Dynamic Control Plane), where IPsec tunnels are negotiated after the test has started at the same time that the users are created so that data plane traffic can start right away. The interfaces are torn down either in the ramp-down stage along with the users, or after the test stops (depending on if the checkbox “Teardown Interface with User” is selected or not). It is also recommended that the Tunnel Setup Rate (form Plug-in Setting) is set to the same value as the Simulated User Ramp-Up Rate (from the Timeline and Objective menu) when using Simulated Users or similar as objective.

Note: The first option (Create Interface at the Start of the Test) is basically equivalent to a Static Control Plane where all IPsec tunnels are negotiated at the beginning when the test configuration is applied to the Ixia ports (before the user plane begins) and are torn down after all user plane activity is finished.

Next, let’s see how we can configure the IPsec tunnels to tear-down after a configurable timeout and then initiate new tunnels to emulate continuous tunnel disconnect and new tunnel establishment over long time periods. Under the IPsec -> Timers tab, there is a dedicated checkbox for “Dynamic Sessions” and also a dedicated timer that is configurable under Session Timeout.

IPsec3

In the above screenshot, we basically configured two IPsec ranges:

Now that we have both of the dynamic behaviors configured, let’s look at the most relevant test statistics:

  1. Tunnel Setup Rate: this is the first important key performance indicator (KPI) that is highly impacted by a dynamic test. In the below screenshot, we can see that the DUT is capable of sustaining 30 tunnels per second while also forwarding data plane traffic:

IPsec4

Note: As a comparison, when we use static mode (where only IPsec tunnels are established first, without any data plane traffic during tunnel setup), the tunnel setup rate that the DUT can handle was over 300, which is an over 10x improvement.

  1. Total Active vs. Initiated vs. Succeeded IPsec sessions: while tunnels are torn down and other tunnels are established, it is important to monitor the DUT’s stability and ability to keep up with this dynamic environment, make sure there are no failed tunnels and the number of active tunnels is consistent across the test.

IPsec5

Note: as we can see in the above screenshot, the DUT is able to sustain an approx. 4,000 concurrent active sessions while some tunnels are torn down and other tunnels are established. The rate at which tunnels are established during the test is approximately 15 tunnels per second (because out of two ranges, only the first one was configured for such Dynamic Sessions).

Other KPIs can also be checked like the data plane transaction rates or TCP retries to have a good understanding of the data plane performance (IxLoad does offer a huge range of such statistics that can be checked at runtime or even after the test finishes for post-test analysis).

The above exercise was possible only by leveraging the extensive flexibility that IxLoad offers in emulating many real-world environments and properly assessing the DUT capabilities within these conditions. IxLoad not only offers such extensive emulation possibilities, but it is also useful when debugging various aspects of the test.

To learn more about IxLoad’s offerings for IPsec VPN testing, check out the datasheet.

limit
3