FortiGate IPSEC VPN testing with Avalanche

Spirent recently launched the Spirent Test Center C1 small form-factor appliance, and I just received mine. I decided it would be a nice little machine to test the FortiGate 40C  UTM (also a small form-factor device) I just bought for demo purposes. With both the C1 and the FortiGate 40C, I have two tiny boxes that have the exact same features as the bigger ones we usually test.

This leads me to the topic of this entry: IPSEC testing. This technology is coming back strongly lately, mostly because of new LTE deployments. That seemed liked a good test case to have fun with. I will show how to configure both the FortiGate and the Avalanche to do an IPSEC Concurrent Tunnels Capacity test. Note that the blurred IP addresses are so because I try to obfuscate our corporate network details as much as possible 🙂

LAN Topology

The LAN subnet is 192.168.100.0/24. The gateway is .1, and I have a web server on .10. That’s pretty much all there is to it. Here’s the server-side association:

Server Associations

WAN Topology

The clients will come from the WAN, which is setup on the DUT as 192.168.128.0/24. Since I want to run an IPSEC concurrency test, I need a lot more addresses than what’s available on a /24 – this is because you can only have one IPSEC tunnel per IP address.

I will therefore use a Virtual Router, on the WAN side, and have my clients use a range in the 10.10.0.0/16 network. The VR IP address is 192.168.128.1, with a default route to 192.168.128.2 (the DUT IP on that network).

Client subnets – I use the highlighted one

Note that there is no Default Gateway set for the clients. This is because when using Virtual Routers, Avalanche will use the routes from the VR, not from the subnets.

Under Client/Ports, this is how the Virtual Router is configured:

The client-side Virtual Router

This is how the DUT is configured with regards to subnets:

FortiGate interfaces configuration

We also need to add a route to the clients’ subnet, so the DUT knows about that subnet. It’s set under Router/Static Routes:

FortiGate static routes – 0.0.0.0 goes to wan2 which is the admin port. We only need 10.10.0.0/16 for this test.

(You will notice I use ‘wan2’ as the management interface, so the default route goes there)

Now that we clearly see the network topology, onto IPSEC!

Configuring IPSEC

This is the Phase 1 configuration on the FortiGate. I will need to match it on the Avalanche.

The FortiGate IPSEC configuration

This is an easy configuration with many options disabled, but it serves its purpose. Let’s match it on Avalanche. For this we need to check the “IPSec” box under Client/Subnets. On the subnet, check “Enable IPSec”, and set the following options:

  • Check “Remote Access”
  • Vendor ID: Is ignored in before 4.10. This is used to customize the Vendor ID later on.
  • Remote Gateway: 192.168.128.2 in my case (the DUT’s WAN IP)
  • IKE Version: 1
  • DH-Group: I could choose 1 or 5 since both are enabled on the DUT.
  • Hash: SHA-1
  • Encryption: AES-CBC-128
  • Authentication: Preshared Key
  • XAuth: No XAuth
  • Preshared key: Value set on the DUT (“spirent” in my case)
  • ISAKMP ID is not used here

Then at the bottom half of the screen, we have more options. Under “IPSecIKEv1” I need to set the IKE Mode to “Aggressive” and leave the rest as default. Let’s now review the Phase 2 on the DUT:

To match this we need to go to the “IPSec” tab now. Leave all the options to default except:

  • Persistent Tunnel: If this box is checked, it tells the Avalanche not to tear-down the tunnel even if the SimUser that used it is dead. I’ll keep this checked since my test case is a concurrency test.
  • Hash: SHA-1
  • Encryption: ESP-AES-128
  • PFS (Perfect Forward Secrecy) : Disabled above, so this needs to be set to “None”

Finishing the Avalanche Configuration

I have absolutely no idea how many tunnels the FortiGate can handle. But I know the C1 can do 5,000 tunnels in that configuration, so this will be my goal. To match this, I just need to create a Load Profile with a “Sim Users” specification. I will use a Ramp Up of 300 seconds (that’s 17 tunnels per second!) and a steady phase of 120 seconds.

This means that the very first SimUser to be born will have to stay alive around 420 seconds. I need to make sure this will happen, and for this we usually use a Think Time (Client/Profile/HTTP User). I will set it to 50. What a think time does is force the SimUsers to wait (50 seconds in that case) between two actions (HTTP GETs in my case). I will create an Action List of 10 GETs, so it will take 500 seconds to go through it.

You don’t have to do this, since with the Persistent Tunnel option the tunnel will stay up even if the user has completed its action list. But I like to make sure all users do requests on a regular basis to make sure the DUT can keep forwarding traffic while handling the tunnels.

At the end, this is what the client association look like:

Final client assocations

Now, just need to run the test! Looks like the DUT likes what it’s seeing 🙂

And the Avalanche stats seem to agree!

Advertisements

About acastaner

I'm the EMEA Technical Lead for Application & Security at Spirent. I specialize in layer 4-7 technologies, Cloud, Programming and CyberSecurity.
This entry was posted in General and tagged , , , . Bookmark the permalink.

2 Responses to FortiGate IPSEC VPN testing with Avalanche

  1. Matthew Garskey says:

    Did you ever try to get a gateway-to-gateway VPN up between the Avalanache and the FGT? I too was able to get the client-to-gateway up and going, but with the gateway-to-gateway I did not see any traffic hit the FGT.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s