Generic and Secure as in GRE over IPsec

By Daniel Munteanu | It is interesting how old technologies are being mixed up and put to work to address new use cases. In my previous blog, I discuss IPsec and how to make sure it meets the requirements for your modern application use cases. In this new blog, I would like to go one level higher in the stack (or lower depending on how you look at it) and add that pinch of functionality and flexibility in the form of GRE over IPsec.

GRE is a tunneling technology that is of similar age as IPsec, but it has successfully passed the test of time mainly due to the simplicity and flexibility it offers.

In a nutshell, GRE can encapsulate virtually any type of traffic in an IP packet and that makes GRE the preferred tunneling option for use cases like tunneling broadcast or multicast traffic (for example in dynamic routing protocols), transmit non-routable protocols over IP networks, or more generically create a point-to-point VPN for transmitting all sort of traffic.

One demanding use case is for connecting a DDoS Mitigation vendor’s scrubbing center to the customer’s network (where the performance requirements are stringent, and the type of traffic can be quite diverse). I have also seen quite a few “proprietary use cases” where a solution/product with a distributed architecture needs to send various control information between the distributed endpoints across dispersed locations.

GRE has a lightweight implementation with a header of only 4 Bytes (without options). It is stateless by nature as it does not require any prior negotiation for the tunnel to establish nor any “state” knowledge of its peer.

While GRE offers quite a few benefits it also has certain drawbacks, one of which is the lack of data traffic confidentiality. The solution to this security concern is IPsec. GRE and IPsec complement each other nicely in that IPsec offers confidentiality, integrity and authentication while GRE offers the ability to tunnel traffic that IPsec alone cannot. As such it is of no surprise that GRE over IPsec is a popular solution.

However, combining that kind of tunneling techniques can hide unexpected behaviors and have performance unknowns. Only proper validation and testing is giving the peace of mind that newly deployed architected solution meets required criteria.

A test tool having the ability to combine these diverse encapsulation techniques as well as doing it at high scale and performance is needed to run such complex, yet mandatory, tests and accurately validate these complex deployments, solutions or even DUTs.

TEST EXAMPLE: VALIDATING THE PERFORMANCE OF A VPN GATEWAY (GREOIPSEC) 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 device (further referenced as the DUT, or device under test) that would also terminate a GRE tunnel on top of IPsec.

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

A quick diagram for such a test scenario would look like below:

GRE1

Next, we will see how this complex configuration is done in a simple and intuitive way in IxLoad as well as interpret the test results.

We will start from an already configured IxLoad IPsec test (no GRE at this point), 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.

First, let’s look at the network stack from the left-hand side.

GRE2

While we have the IPsec stack, we need to add the GRE: right-click on the IPsec level, and select Add above -> Access -> GRE:

GRE3

The last thing we need to do is to add the uppermost IP layer on top of GRE (in a similar manner) so that the final stack would look like:

GRE4

On the right-hand side, since the DUT is terminating both IPsec and GRE, there is no special stack we need – just your regular IP stack, and it is all clear-text.

In terms of objectives, we would like to simulate for this test 8000 tunnels and also 8000 endpoints running traffic:

Now, let’s run the test and look at the most relevant test statistics:

  1. Tunnel Setup Rate: this one important key performance indicator (KPI) and despite that fact that GRE is stateless, IPsec would still need to negotiate. In below screenshot we see that all IPsec sessions are initiated at a rate of 500 tunnels per second and all are successfully negotiated:
    GRE5
  2. Total Active vs. Initiated vs. Succeeded IPsec sessions: while tunnels are running traffic, it is important to monitor the DUT’s stability and that all negotiated sessions are also kept active (these metrics are on the same view in the above screenshot).
  3. Obviously, extremely important is the data plane to make sure there are no errors and the DUT is able to decrypt, decapsulate, and finally forward (and vice-versa) the user traffic. There are many related KPIs that can 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 run time 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.

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

limit
3