Daniel Munteanu
Technical Product Manager
Blog

Are your IPsec Tunnels Misbehaving?

October 31, 2018 by Daniel Munteanu

In one of my previous blog posts, I was emphasizing the fact that IPsec is not going away anytime soon and, based on customer engagements, it is quite the opposite—we are seeing it deployed in many diverse environments.

Now, we have yet another confirmation of the important role IPsec is playing throughout many networks. In the Sandvine 2018 Global Internet Phenomena Report, IPsec has ranked the number 10 traffic type in upstream traffic share in the Americas. Quite impressive, given the giants it is compared against like media streaming and the ubiquitous torrent services.

As such, I thought it appropriate to give IPsec some exposure and pay some homage to the international Internet day celebrated earlier this week (on 29th of October)!

In this blog, I plan to tackle one topic that can take your IPsec testing at the next level: how to make sure each IPsec tunnel handled by a real VPN Gateway is in good shape and meeting your specific requirements.

When testing IPsec implementations or architectures, there can be small glitches that are not visible if looking at the big picture alone. According to the specific implementation details, some applications might have very stringent requirements in terms of latencies, failed rekeys, packet drops, decryption errors, etc. for all IPsec tunnels.

To discuss how to validate that your specific requirements are met by all IPsec tunnels, we’ll need to drill down with detailed statistics to the maximum granularity level - on a per-tunnel basis.

Test Example: Have You Noticed that IPsec Tunnel Misbehaving? 

As with our previous IPsec-related blogs (check the one on IPsec Dynamics here and the one on how to decrypt IPsec traffic here), in the next paragraphs we will use Ixia’s IxLoad test tool to bring up the IPsec tunnels connected to a real VPN Gateway device and then check the health of all IPsec tunnels for specific criteria.

We will start by looking at what the prerequisites are to have access to detailed per-tunnels statistics for an already configured test. With the risk of being redundant, I will take this opportunity to re-emphasize that if you need help getting started with an IPsec test configuration, there are plenty of canned templates to start from in the IxLoad client application under File -> New -> Templates -> IPsec folder.

One thing to enable before running such an IPsec test is the “Enabled ESP per tunnel stats” checkbox under the Network Group Settings tab at the IPsec stack layer:

1

Now, we are pretty much ready to deep dive into what is happening at each tunnel level.

One easy way to get access to the per-tunnel statistics is to right-click on each IPsec stat name (once the test has started), and choose “DrillDown Per Tunnel” from the menu:

2

 

Once the above operation is performed, a new view is automatically created with the default IPsec Per Tunnel statistics:

3

While this is pretty cool, and it provides detailed per-tunnel stats, the next challenge is how to efficiently look for specific errors or abnormal conditions as per certain requirements mostly imposed by the production deployment environment.

We can take, for example, the situation where we want to validate a mission-critical industrial control system (ICS) deployment where we want to make sure that each IPsec tunnel will successfully rekey every time and there is no IPsec tunnel with failed rekeys. 

Since looking through all IPsec tunnels for such error conditions is not feasible, we can leverage another unique function—apply custom filters on the above per-tunnel view.

On the upper left corner, when clicking on the Filter/Sort button, we can enable the Filter by statistics section and configure our desired customer filter:

4

Let’s configure the filter as per our previous requirement, and choose Phase2 Failed Rekeys as our statistic, “Is greater than” as the operand and 0 as the value against which it is being applied:

5

Once we click on OK, the IPsec Per Tunnel view will get correspondingly filtered and it will only display those entries satisfying the condition: 

6

In this particular example, there were no failed Phase2 Rekeys.

Obviously, this procedure can be applied for many other statistics to easily pinpoint which IPsec tunnels are not within the acceptable requirements we are defining.

I hope this blog post has helped you understand how to take IPsec testing one step further and perform pre-deployment validation tests so you are confident that the production requirements are thoroughly met. If you need more information, you can find technical details and step-by-step instructions for implementing these rules in your test by consulting the IxLoad User Guide (requires customer login).