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


  • Only one IKE and IPsec SA needs to be negotiated.
  • Adding or removing networks allowed to/from the IPsec interface is simply a matter of modifying the rules and routing. No change to the tunnel itself is needed.
  • A Tunnel Monitor can be used to restart the entire tunnel.
  • If multiple networks are used, the tunnel monitor can only trigger and tear down one IPsec SA (basically one network combination).
  • Only one IPsec SA re-key is needed. High DH groups can cause "hiccups" depending on the CPU power of the system. So instead of, for example, 16 re-keys every 3600 seconds, we have only one.


  • Need to be aware of the two pitfalls when configuring all-nets (see below)
  • Any new network is allowed to/from the IPsec tunnel. If any routing or IP rule set mistakes are made, there will be no "allowed networks" check done on the IPsec tunnel itself. The verification check-list mentioned previously would then look like this:
    • Verify that the the network/IP's that want to communicate between A to B or from B are A is part of the local and remote network.
      • And to clarify the above point, this means that this check is basically not performed as all networks are allowed inside the IPsec tunnel.
    • Verify that traffic is correctly routed on the IPsec tunnel interfaces for the defined remote network.
    • Verify that the IP policy's allow the communication to/from the tunnel according the requirements set out by the administrator.
  • Less IPsec SA re-keys. Since there is only one SA negotiated the security would be considered less as an attacker would then only need to break the encryption of one IPsec SA if they want to access all network segments.
    • A way to mitigate this slightly would be to set a lower lifetime on the IPsec SA (the default is 1 hour / 3600 seconds) in order to make it re-key more often.

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:

  • When sending a ping into the tunnel from the firewall itself using the CLI (e.g. "Ping -verbose"). The IP sender would then be and that would not work that well.
  • When sending logs generated from the firewall itself towards a log receiver located behind an IPsec tunnel. The IP sender would then again be
  • When NAT'ing traffic into the IPsec interface and the default "use interface address" option is used on the allowing IP Policy. Then the IP sender would again be
  • When activating a Tunnel Monitor, the source IP of the monitor would be and that would never generate a reply from the target monitoring host.

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

Configuring L2TP/IPsec Server using PSK
11 Jan, 2023 ipsec core vpn
Setup of a Layer-3 bridge over IPsec in cOS Core
12 Apr, 2023 core proxyarp arp ipsec routing
cOS Core IKEv2 split tunneling with Windows and local user database.
28 Mar, 2023 ikev2 windows vpn routing splittunneling
Configuring public certificates in NetWall firewalls
18 Mar, 2024 core certificate oneconnect ipsec vpn
cOS Core L2TP server setup with Windows Server CA certificates
21 Feb, 2023 ipsec certificate windows ca core
Problem with auto-created Core routes
22 Mar, 2021 core ipsec routing
Certificate update in InControl global domain on certificate that is used on firewall(s)
18 Mar, 2024 core incontrol certificate oneconnect ipsec vpn
Setting up OSPF with IPsec in cOS Core
16 Apr, 2024 core routing ospf ipsec
Using /31 network masks in cOS Core (RFC-3021)
1 Jun, 2022 core routing management
cOS Core IPsec IKEv1 "No_Proposal_Chosen" error in 14.00.10
4 Aug, 2023 core ipsec troubleshoot ike
IPsec license usage calculation
14 Apr, 2021 core license ipsec
Does IPsecBeforeRules trigger before Access rules?
8 Sep, 2020 core ipsec rules access
Split tunneling in cOS Core with Windows L2TP/IPsec clients
29 Mar, 2023 ipsec core windows vpn l2tp
Troubleshooting IPsec tunnels (IKEv1)
7 Dec, 2022 ipsec ike troubleshoot core
cOS Core IKEv2 tunnel setup with certificates for iOS clients
5 Apr, 2023 core nps ipsec radius legacy
The meaning of the Default_Access_Rule log entry
7 Nov, 2022 core arp log routing
Troubleshooting cOS Core rules/routes with ping simulation
17 Mar, 2023 core routing rules ping icmp cli
Freeing up more memory in the Firewall
23 Aug, 2022 core connections ipsec memory
Is Statless (FwdFast) faster than a normal IP policy?
27 Jan, 2021 core stateless routing brokenlink
Route failover with IPsec tunnels in cOS Core
13 Feb, 2023 ipsec core routing failover
Public network transparency using cOS Core Proxy ARP instead of subnetting
18 Apr, 2023 core routing transparentmode proxyarp