IPsec Next Stop: Cloud

By Daniel Munteanu | Since its inception, Internet Protocol Security (IPsec) has had a long journey, providing a secure network protocol suite for many real-world applications.

In previous IPsec related blogs (Measuring IPsec Dynamics on VPN Gateways and Generic and Secure as in GRE over IPsec) we discussed interesting aspects of the technology and the real problems we see in the field and propose solutions for those real-world use cases. As Cloud is becoming mainstream, the next natural step is to touch upon how IPsec is facilitating cloud migration, providing a secure network layer service. Having this technology readily available, many cloud service providers (CSPs) are innovating faster and more securely. The number of scenarios where CSPs are leveraging IPsec is very broad and it ranges from connecting entire on-premises networks to the cloud network, inter- and intra-cloud connectivity, to even providing a secure access mechanism for secure access secure edge (SASE) offerings.

While the benefits are huge, there are a host of issues that might arise that can turn into real detractors of the service being offered, if not thought of, and planned accordingly. These can start with interoperability matters (IPsec is by definition a complex technology), stability, and robustness (soak behavior) but can culminate with poor application performance and user experience, which can arise not only immediately after service launch but also well into the production stages as more and more users adopt it.

Use Case: Regional Density and Knowing IPsec VPN Concentrator Limits

Since this topic is so broad, let’s tackle one matter at a time and discuss a particular situation that is more prominently seen as adoption increases: regional density. What might happen is that as a specific cloud service (leveraging IPsec for network access of course) becomes more successful and more customers are onboarded, the pressure on some regions might abruptly increase.

An example might be a retail type of customer with thousands of connections hitting the same entry point of presence. Depending on what type of cloud infrastructure the services are relying on, this issue can take different shapes and forms. But one common very important item to be prepared for in tackling such issues is to have a proper characterization of the IPsec virtual private network (VPN) concentrator (in terms of performance and scale) as this will be the cornerstone of the network overlay. Even for clouds that have built-in horizontal scaling, such characterizations are important as it will assist in properly configuring the scaling policies.

To properly characterize the limits of the IPsec VPN concentrator, a test tool capable of emulating a large number of tunnels (thousands and even more) with the ability to measure both control plane (e.g., maximum concurrent tunnels (users) and tunnel setup rate), as well as data plane KPIs (e.g., throughput and QoE metrics), is needed.

For readers that are interested in how this can be done on Amazon Web Services (AWS), I would like to take this opportunity and share some tips and tricks on how to easily run a scale test with a large number of tunnels, on the AWS infrastructure.

How to Configure IxLoad for Large-Scale IPsec Testing on AWS

The obvious constraint that we have for this use case is the number of IP addresses that AWS provides for a certain EC2 instance. As we want to emulate thousands of IPsec tunnels initiated from a single EC2 instance (deployed as a virtual test blade – in IxLoad terms), we need to find other alternatives.

The approach to take here is to use an “Emulated Router” attached directly to the virtual network interface card (NIC) of the EC2 instance and use the IP address provided by the AWS infrastructure for the emulated router, while all the emulated IPsec clients will sit “behind” this emulated router. The IxLoad emulated client stack will look something like this:

IPsec Initiator

If we try to run traffic in this fashion, there is a missing piece: how do we make the AWS infrastructure not drop the packets using other IP addresses than those provided by AWS itself? The trick here is to disable the “Change Source/Dest. Check” option as follows:

With these options configured, we can now use the IxLoad emulated IPsec client IP addresses that are not allocated by AWS, which will allow us to scale to thousands of tunnels.

Now, remember that the “Emulated Router” IxLoad connected interface still needs to use the IP address allocated by the AWS infrastructure. To make things simpler, IxLoad does offer the possibility to automatically configure the “Emulated Router” interface with the IP address allocated by the AWS infrastructure. The easiest way to do this is enabling the “Forcefully Update Network Configuration for Cloud” option from the “Test Options” button menu from the ribbon:

IPsec Cloud 3

There are obviously more options for the IPsec/network configuration part for similar test scenarios and all of these are very well explained in the Getting Started with IxLoad in AWS guide, here (requires customer login).

This is just a simple solution on how to build a large-scale IPsec test on AWS. From here on, users can use IxLoad for tests like the previously mentioned on-premises IPsec VPN concentrator validations to measure all the important key performance indicators (KPIs). For example, have a look at this blog (last part) for some very high-level info on the most relevant test statistics.

Such exercises are possible only by leveraging the extensive flexibility that IxLoad offers in emulating many real-world environments and properly assessing the device under test (DUT) capabilities within these conditions.

I hope this blog post has been informative and provided good tips on how to get started on high-scale IPsec testing on public clouds like AWS.

To learn more about IxLoad’s offerings for IPsec VPN testing, check out the IxLoad IPsec and Network Access Test Solution data sheet.

limit
3