A few years ago I wrote an article on how to test IPSEC on a Fortigate using Avalanche. But the article is largely outdated and only covers Preshared Key Authentication. It so happens that I recently needed to configure a similar test, except this time the authentication mechanism had to be Digital (RSA) Certificates. So let’s get to it.
Let’s recap what we have:
- Load Generator is a Spirent Avalanche C100-S3 running version 4.75.
- DUT is a Fortigate 1500D running FortiOS 5.2.2 (I know it’s not the latest version, but it’s the one I have)
- Devices are connected through a MRV switch and a Velocity topology using 2x 10GbE fibre.
- IPSEC in Tunnel mode
- Digital Certificate Authentication
- Phase 1: IKEv1, DH-Group 14, AES-256 encryption and SHA-256 hash, Aggressive Mode
- Phase 2: AES-256 and SHA-256 no need for PFS (customer’s requirement; Avalanche supports P2 PFS just fine).
I’m going to post screenshots for most of the configuration but will comment for the relevant bits.
Most of the Phase 1 options are accessible directly on the subnet tab. In this case I’m using the second row (highlighted in yellow) but as you can see I also ran some tests using PSK authentication. Make note of the ISAKMP ID Type (KEY_ID) and value (“demo”) as we’ll need this later.
The rest of the IKEv1 configuration, where we specify the IKE mode (Aggressive in our case, we also support Main mode).
Make note of the Phase 2 options here. We’re telling Avalanche to send the current user’s IP address in it’s Initiator’s ID Type and this must match on the server side (see below). The Responder’s ID Type tells Avalanche what kind of response the gateway will answer (this can be arbitrary). This is critical because, as with everything in IPSEC, all the settings have to match 100% for anything to work.
Let’s have a look at the Fortigate GUI for a bit.
The phase 1 options are here. It matches the ones in Avalanche of course. We’ll get to the Certificate later.
Here we get the Proposal options. I kept the defaults except for 3DES (lol). It’s important that the Key Lifetime matches what’s configured in Avalanche (see below – click to zoom).
Make sure the Phase 1 and Phase 2 keys lifetime match. This is a very common configuration error in Avalanche (each device, whether it’s a load generator or an IPSEC gateway, use different default values). Note that this is the area of the GUI where we actually specify the client certificate we want to use, as well as the certificate the gateway will offer (“CA Cert” field).
The Phase 2 options on the Fortigate. The “Local” and “Remote” access are critical. They are the values corresponding to Avalanche’s “Responder’s ID Type” and “Initiator’s ID Type”, respectively.
Let me make that clear:
Avalanche Initiator’s ID Type = Fortinet’s Remote Address
Avalanche’s Responder’s ID Type = Fortinet’s Local Address.
Yes, it’s very annoying that nobody in the industry uses the same terms for the same options everywhere. That’s always going to be your challenge when testing IPSEC. But there you have it.
We are basically telling the Fortigate that clients will come from the 220.127.116.11/16 subnet, and that it should tell them that it’s on 18.104.22.168/16. Doesn’t have to be true, just has to match.
All of this was fairly quick to setup because it’s all pretty straightforward once you get the terminology down. It’s really just a lot of options. When trying to start using Certificates (I started by using PSK authentication), things began to become interesting. Mostly because I wasn’t sure how Fortinet works with regard to this so that was learning experience.
It seems the Fortigate will accept a certificate only if it’s been signed by a CA known to the device, as well as explicitly listed as accepted. There’s probably a smarter way to do this (e.g.: using the subjectName or alternativeSubjectName or something like that) but, again, I’m not a Fortinet expert and my time for investigation was limited.
I could use OpenSSL to generate all the keys but instead I used X Certificate and key management (XCA) because I couldn’t remember all the OpenSSL CLI commands to save my life. First I created a Certificate Authority (Spirent_CA):
It was then exported as a PEM file:
Note that the extension is .crt. The FGT GUI refused to import it so at first I thought it was a format problem. Turned out it was just the extension. Renaming to .pem and the certificate was accepted. Not sure if this is by design or a bug but be aware of this (alternatively, I’m pretty sure it would work better by importing from the device’s CLI).
Once imported it shows up in the GUI:
For the next step I need to generate the IPSEC clients’ certificate. I’ll do this from XCA. Right-click on your CA Certificate in the GUI, pick “New”, and you should see this:
Make sure you sign it with the CA you uploaded on the FGT. On the “Subject” tab, fill as appropriate:
Once that’s done we can upload the certificate onto the FGT. There’s a little trick to importing the certificate though. I’m not sure why but the FGT wants both the public and private key otherwise the certificate is refused later on. I’m not sure why but I couldn’t get it to work. So export both your public key (certificate) and private key from XCA in the PEM format (and change the extension from .crt to .pem).
To be 100%, this is what a public key looks like:
And the private key looks like something like this (yes, I modified it before posting a private key online, even if it’s just for a lab 🙂 :
—–BEGIN RSA PRIVATE KEY—–
—–END RSA PRIVATE KEY—–
If your keys look like this, you’re good to go. Now just make sure that in your IPSEC Tunnel Policy you configured the appropriate certificate (go set it now if you just imported the certificate).
You also need a policy to allow users to VPN in. Here’s mine below, it’s not very secure but good enough for the lab:
Now let’s run a test and see what happens!
Well, that seems to be working 🙂
On the Avalanche side we can see the Attempted vs Open tunnels:
Some throughput statistics:
And so on.
Hope this article helps, if you have any question feel free to comment or contact me offline. I won’t answer Fortinet-related questions though because I claim no expertise whatsoever in that vendor’s technology.