Site-to-site VPN standards

Something a little different from my usual content for you today. Site-to-site VPN's and more specifically IPSEC tunnels. Chances are you have a few around your business but are they secure? If you set them up 5 years ago and forgot about them the chances are, they are not.

This information is correct at the time of publishing but this stuff changes. If you take anything away from this let it be that. You really need to be reviewing VPN configuration a couple of times a year... At least.


The VPN endpoints should:

  • Be included in a firewall review policy -  You should be reviewing all your firewall config every 3 months to ensure people are keeping to the standards you set in your firewall ACL policies. Its a good idea to review VPN configs at this time too.
  • Be on the most recent, "mature" firmware. - its good pratice to avoid firmware that is too new in favour of a slightly older "mature" version. This shouldn't be older than a verson or 2. Fortinet handily tell you which is mature.
  • Be covered by an appropriate support contract. - I cant stress this enough. If you don't have a contract you aren't getting patches and updates.


The following standards should be applied when building IPSEC tunnels:

  • Use IKEv2 - IKEv2 is the most secure version of the IKE protocol. Older hardware may need to still use IKEv1. Replace this kit ASAP.
  • Use strong encryption – at least 128bit but higher if possible.
  • Use a Diffie-Hellman group of 14 or higher - Anything lower than 14 is no longer considered secure.
  • Use a certificate if possible - yes its much harder to manage but it is more secure.

If you cant use a certificate use a certificate:

  • Use a unique pre-shared key (PSK) for each VPN tunnel - Do not use the same PSK for multiple tunnels.
  • Ensure it is strong - At least 32 characters long and must include a mix of uppercase and lowercase letters, numbers, and symbols. It is recommended to user a random password generator.


Finally the following ciphers are not secure and should be avoided wherever possible:

  • RC4 - has been shown to be vulnerable to several attacks, including the BEAST attack.
  • 3DES - can be broken by brute force attacks, and it is no longer considered secure for most applications.
  • DES - is obsolete. It has been broken by brute force attacks; it is no longer considered secure for any application.