Using "all-nets" as source/destination network in IPsec tunnels

Last modified on 17 Jun, 2021. Revision 18
Up to date for
cOS Core 13.00.10
Supported since
cOS Core 8.xx
Status OK
Peter Nilsson

Using all-nets / as the source or destination network

The base scenario

Let us first look at a basic IPsec scenario. A Lan2Lan IPsec tunnel between two firewalls and a client and server who want to communicate.

This scenario is fairly straight-forward, the IPsec tunnel configuration for the Local and Remote network would look something like this:


Local Network =
Remote Network =


Local Network =
Remote Network =

For this scenario we only need one Route on each side and two IP policies if we want to allow connections to be initiated by either side. The route and IP rule set entries needed on Firewall-A it would look something like this:

Route IPsec_To_Firewall-B
Allow Lan Lannet IPsec_To_Firewall-B Service=YourService
Allow IPsec_To_Firewall-B Lan Lannet Service=YourService

Next, we set up the equivalent route and rules on Firewall-B. The verifications needed to make sure the correct traffic/networks are allowed to communicate are:

  1. Verify that the the network/IP's that want to communicate between A to B or from B to A is part of the local and remote network.
  2. Verify that traffic is correctly routed on the IPsec tunnel interfaces for the defined remote network.
  3. Verify that the IP policies allow the communication to/from the tunnel according to the requirements set out by the administrator.

Multiple networks on both sides

Lets say we expand the above scenario, we now have one IPsec tunnel but 4 networks behind each Firewall.

The above will mean that, depending on which networks that want to communicate, we may end up with a total of 16 IPsec tunnel negotiations (17 if we also count IKE). One for each possible network combination (4x4). In the example above, the network wants to talk to all 10.10.xx.xx networks. This alone would generate 4 IPsec SA (Security Association) tunnel negotiations, one for each network combination.

The network configuration on each firewall will then look like this:


Local Network =,,,
Remote Network =,,,


Local Network =,,,
Remote Network =,,,

This means that each network combination will need to negotiate their own IPsec SA in order for all network combinations to work.

When to use all-nets as the local and/or remote network

IPsec is complex. There will always be some, less obvious scenario that works badly due to the countless factors involved in IPsec tunnel creation and the data transfers between the two tunnel endpoints. Potential problems could include timing, latency, PPS, BPS, packet losses, vendor differences, compatibility, bugs, load balancing, scanning systems, anti-virus, man-in-the-middle attacks and the list goes on. A way to try limit the chance or even solve a problem when a tunnel works badly is to limit the amount of negotiations done between the tunnel endpoints. The less negotiations, the less chance of a timing related issue. Tunnel re-keying can, in many cases, be the cause of problems when Endpoint-A deletes the old SA but Endpoint-B does not or vice-versa. Then, either side believes the tunnel is up when it is not and this could cause network interruptions which could be difficult to narrow down. Under optimal conditions this should never happen, but when most tunnels are going over the Internet, it’s hard to predict what could interrupt traffic.

A way to limit the amount of negotiations and re-keys would be to have all networks go over a single IPsec SA negotiation instead of multiple. This is achieved by configuring the side with multiple networks to use “all-nets” ( as it’s local and/or remote network. Since all-nets consists of all available networks there would be no need to negotiate more than one IPsec SA.

A general principle for when all-nets should be used

A general principle that can be followed is that if you have more than 3 networks in either the local or remote network on an IPsec tunnel, use all-nets instead. If one side only has one network then there is no point in using all-nets for both the Local and Remote network tunnel definition unless there are plans to extend the tunnel with more networks in the future. Then it might be an idea to use all-nets anyway (see pros and cons below).

Pros and cons



The two pitfalls (Static route and source IP)

Using all-nets as either local or remote network has two pitfalls that the administrator must be aware of as it could, in the worst case, cause Internet access to be lost after configuration deployment.

Using all-nets as local network

The item to be aware of here is the source IP the firewall itself will use when sending traffic into the tunnel. Normally when a local network is defined the firewall can use a local IP that matches an interface that the local network belongs to. But when using all-nets the firewall will be unable to determine which source IP it should use as sender.

A few examples of when the Firewall would need this IP:

The solution to the problem would be to manually configure an IP address on the IPsec tunnel, as shown below.

Using all-nets as the Remote Network

This one is the most “dangerous” usages sinces it could, in the worst case, cause your Internet access to be disrupted. The reason for this is due to the default option that automatically adds a route in the designated routing table towards the remote network. And if the Remote Network is set as “all-nets”, it would add an all-nets route pointing to the IPsec interface.

In the worst case, your routing table might look like this:

Type    Interface    Network   Gateway Metric
Route Wan all-nets ISP_GW 100
Route IPsec_Tunnel all-nets 90

And since the IPsec tunnel has a lower routing metric than the interface route, it would cause all Internet traffic to be sent into the IPsec tunnel itself. However, there are scenarios where this could be the desired outcome.

The solution to this problem is to either remove the checkbox for the auto-route creation (1) or to increase the metric (2) to be higher than the normal interface route. It is strongly recommended to remove the static route and manually configure the networks/routes that should be used to/from the IPsec tunnel. An administrator most likely would want to only route a few select networks into the IPsec tunnel anyway.

Using Auto-Establish and a Tunnel Monitor

A Tunnel Monitor has a limitation that it can only monitor one IP address. This means that only one network needs to be considered as down for the the tunnel to be reestablished. The advantage of using a Tunnel Monitor on an all-nets tunnel is that the all-nets SA is then restarted which effectively means the entire IPsec interface is too. This means that a Tunnel Monitor works much better when using all-nets as the network.

Auto-Establish, however, is a feature whose purpose is to try keep all IPsec network combinations up at all times. The problem is that it is frequently active (once every second) and could, in many situations, generate more problems than it solves. If we consider the example above without using all-nets, it would mean that Auto-Establish would try to keep all 16 network combinations up all the time and if one or more is failing (for example, due to a configuration fault on the remote endpoint) it would bombard the remote endpoint every second with a negotiation that constantly fails. It is therefore recommended to turn off this option on ALL IPsec tunnels whenever possible.

Related articles

Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
IPsec license usage calculation
14 Apr, 2021 core license ipsec
Does IPsecBeforeRules trigger before Access rules?
8 Sep, 2020 core ipsec rules access
The meaning of the "Default_Access_Rule" log entry
25 Jan, 2021 brokenlink core arp log routing
Freeing up more memory in the Firewall
18 Feb, 2021 core connections ipsec memory
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink