Changes in IPsec license handling in version 11.xx

Frequently Asked Questions
Post Reply
Peter
Posts: 648
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

Changes in IPsec license handling in version 11.xx

Post by Peter » 21 Sep 2015, 14:16

This FAQ applies to:
  • cOS Core version 11.00.00 and up.
Question:

I upgraded to version 11.xx and one of my tunnels got disabled, why?

Answer:

Before version 11.00.00 the VPN license check towards IPsec tunnels matched IKE SA's (Security Association). This means that you could have one tunnel with a large amount of networks defined using e.g. a group and this would still only count as if one license parameter was used.

In version 11.00.00 and up the VPN license check towards IPsec tunnels now matches the amount of tunnels, or amount of IKE SA's or amount of IPsec SA's.

Depending on how the tunnel(s) are configured there is a chance that you will get near the license limit. A few examples:

Scenario-1:
5 tunnels configured, one network defined as local and remote network on all of them.
License parameters used : 5

Scenario-2:
5 tunnels configured, one network defined as local and remote network on all of them. None of the tunnels are established/active.
License parameters used : 5

Scenario-3:
1 tunnel configured, 5 networks configured as local and one network configured as remote.
License parameters used : 5

Scenario-4:
1 tunnel configured, 5 networks configured as local and 5 networks configured as remote.
License parameters used : 25

Scenario-5:
1 tunnel configured as a roadwarrior server, one network defined as local and one remote network (all-nets).
Llicense parameters used : one per connected client.

Freeing up tunnels in the license

In case you run into a scenario where the license has hit the limit, one fairly easy way to lower the amount of tunnels used in the license is to combine networks into larger segments. So instead of using several /24 networks in a range you use one big /16. Then there will be fewer negotiations and IPsec SA's needed.

A very common way to configure tunnels with many networks is to define them as "all-nets". You still control with routing and rules what should be allowed to/from the tunnel(s). As long as rules and routing are correctly configured the security impact will be kept at a minimum. This also has the advantage that there will be fewer tunnel re-keys and less change of network "hiccup" when these operations are performed.

Post Reply