This recommended read focuses on the best practices for planning and configuring a site-to-site policy-based IPsec VPN. It can be applied generally and  isn’t limited to the Sophos Firewall.

Configurations

1. Configure only one VPN gateway as initiator

One VPN gateway must be configured as a VPN initiator and the other as a VPN responder.

To configure a VPN connection as a responder on the Sophos Firewall, set "Gateway Type" to "Respond Only."

When a VPN connection is configured as a responder, the Sophos Firewall doesn't send out VPN connection requests but responds to them.

Which VPN gateway must be configured as a VPN responder?

• The Sophos Firewall must be configured as a VPN responder, and the third-party VPN gateway must be configured as a VPN initiator.
• A VPN gateway with more "respond only" VPN connections should be configured as a VPN responder.
• If both VPN gateways have the same number of "respond only" VPN connections, the VPN gateway with more VPN connections must be configured as a VPN responder.

2. Use the RSA key

RSA key

• is easy to implement
• is difficult to be cracked
• works well with multiple "respond only" VPN connections, compared to pre-shared key 

Limitation of pre-shared key

Use pre-shared key only when peered VPN gateway doesn't support RSA key.

On Sophos Firewall, the pre-shared key doesn't work well for the following setup 

• Multiple "respond only" VPN connections are configured, and
• they’re configured with a pre-shared key and
• they’re configured with the same remote gateway IP addresses, such as "*".

3. Configure VPN ID

Configuring a VPN ID for each VPN connection is recommended to prevent mismatches on connection requests.

In the example below, the Sophos Firewall is configured with local VPN ID "Sophos" (type: DNS) and remote VPN ID "UTM" (type: DNS)

Therefore, the remote gateway must be configured with local VPN ID "UTM" (type: DNS) and remote VPN ID "Sophos" (type: DNS)

Note: By default, the Remote ID is set to the remote gateway address when it’s a specific IP address, even if the Remote ID type  isn’t configured. Manually configuring the VPN ID can avoid the confusion caused by the default behavior.

4. Sophos Firewall doesn't automatically summarize VPN subnets

The Sophos Firewall doesn't automatically summarize VPN subnets, while some VPN gateways summarize VPN subnets.

It is recommended to determine if and how the 3rd party VPN gateway summarizes the VPN subnet.

For example,

• Sophos Firewall is configured with
  • local subnet: 192.168.20.0/25, 192.168.20.128/25
  • remote subnet: 192.168.30.0/24
• remote VPN gateway is configured with
  • local subnet: 192.168.30.0/24
  • remote subnet: 192.168.20.0/24

Sophos Firewall will create 2 IPsec SA

• 192.168.20.0/25 --- 192.168.30.0/24, and
• 192.168.20.128/25 --- 192.168.30.0/24, as below.

While, some VPN gateway might summarize 192.168.30.0/24 into 192.168.0.0/16, and create only 1 IPsec SA of 192.168.0.0/16 --- 192.168.10.0/24.

Sophos Firewall accepts IPsec SA of split remote VPN subnets. For example,

• Sophos Firewall is configured with
  • local subnet: 192.168.30.0/24
  • remote subnet: 192.168.20.0/24
• remote VPN gateway is configured with
  • local subnet: 192.168.20.0/25, 192.168.20.128/25
  • remote subnet: 192.168.30.0/24

The VPN can be established, and 2 IPsec SA will be created

• 192.168.20.0/25 --- 192.168.30.0/24, and
• 192.168.20.128/25 --- 192.168.30.0/24, as below

5. Summarize local/remote VPN subnets to improve stability and capacity

It’s recommended that local/remote VPN subnets be summarized to improve stability and capacity.

Note: When local/remote VPN subnets are manually summarized, the "Create firewall rule" needs to be disabled in the VPN connection.

For an IPsec VPN connection with three local subnets and three remote subnets,

9 IPsec SA is generated, and the firewall needs to maintain 9 IPsec SAs.

If we summarize local and remote VPN subnets, as below

The firewall needs to maintain only 1 IPsec SAs.

Then, in the firewall rule, specify local VPN subnets can be accessed by remote VPN subnets.

6. The Sophos Firewall doesn’t support FQDN host in local/remote VPN networks.

The Sophos Firewall doesn’t support FQDN hosts in local/remote VPN networks.

Configure the IPsec policy.

1. The IKE version must be matched on both VPN gateways, and IKEv2 is recommended

On the Sophos Firewall, an IPsec policy can be configured as IKEv2 or IKEv1.

IKEv2 is recommended. One advantage is that it simplifies re-keying and makes the VPN connection more stable during re-keying compared to IKEv1.

Note: The Sophos Firewall doesn't support IKEv2 and IKEv1 in the same IPsec policy.

Workaround to use IKEv1 IPsec policy in a "Respond only" VPN connection

Sometimes, Sophos Firewall needs to be configured as a VPN responder with IKEv1. However, on Sophos Firewall, the IKEv1 IPsec policy can't be used by a "Respond only" VPN connection by default.

Here is the workaround:

1. Create an IPsec policy for a "Respond only" VPN connection, and set "Key exchange" to "IKEv2".
2. Assign the IPsec policy to the "Respond only" VPN connection.
   In the screenshot below, "IKEv2_responder" is an IKEv2 IPsec policy.
   
   
   
   
3. Edit the IPsec policy and change "Key exchange" to "IKEv1".
   
4. Enable the "Respond only" VPN connection.
   
   

It isn’t recommended to use IKEv1. The workaround is only needed if the Sophos Firewall has to be configured as a VPN responder and the remote VPN gateway only supports IKEv1.

Note:

• The Sophos Firewall doesn't allow modified built-in IPsec policies, so we need to duplicate a built-in IPsec policy, edit it, and then assign it to a VPN connection.

2. Enable re-key and DPD only on the VPN initiator 

It’s recommended to enable re-key and DPD only on a VPN initiator and disable them on a VPN responder.

To disable re-key, edit the IPsec policy and uncheck "Allow Re-keying".

To disable DPD (dead peer detection), edit the IPsec policy, and uncheck "dead peer detection."

3. Phase 1 and phase 2 re-key shouldn't happen at the same time

On any VPN gateway, phase 1 SA (a.k.a IKE SA) and phase 2 SA (a.k.a IPsec / CHILD SA) should not be re-keyed simultaneously. Otherwise, the VPN will be disconnected on every phase 1 re-key.

Phase 1 and phase 2 will be re-keyed simultaneously if phase 1 key life can be divisible by phase 2 key life; for example, phase 1 key life is 43200 seconds, and phase 2 key life is 3600 seconds. (43200 / 3600 = 12).

There is no need to worry about it on the Sophos Firewall, as it provides the option of "Re-key margin," and the default setting of phase 1 key life is fine.

4. Rekey shouldn't happen at the same time on peered VPN gateway

If re-keying is enabled on peered VPN gateways,

• Both VPN gateways can't have the same phase 1 key life. Otherwise, they’ll re-key phase 1 simultaneously, and the IPsec VPN might be disconnected.
• Both VPN gateways can't have the same phase 2 key life. Otherwise, they’ll re-key phase 2 simultaneously, and the IPsec VPN might be disconnected.

Additionally, the same rekey values on the initiator and responder cause rekey collisions, which would cause multiple issues like

• Duplicate SAs—The SAs get duplicated due to the collisions, which puts more load on the IPsec control plane and causes uneven rekeying events.
• This causes issues with the XFRM gateway for RBVPN connections.
• Traffic issues – IPsec traffic drops
  

No need to worry about it if only one VPN gateway has re-key enabled.

5. Settings don't need to be matched

The following settings in the IPsec policy don't need to be matched on peered VPN gateways.

• number of Key negotiation tries
• Re-key connection
• Phase 1 key life
• phase 2 key life
• Dead Peer Detection

All other settings in the IPsec policy must be matched.

How to achieve high VPN speed

Kindly refer to Sophos Firewall: Troubleshooting Guide - How to achieve high VPN speed.

Configuration guides for a specific scenario

Sophos Community provides detailed guides on how to configure different site-to-site policy-based VPNs.

They can be easily found by searching with keywords in Sophos Community.

For example, for IPsec VPN between Sophos Firewall and Azure, search for "Sophos Firewall IPsec VPN azure how to."

Common issue

The outbound VPN traffic not forwarded into the IPsec VPN tunnel

Occasionally, we might face the issue that the local VPN host can't ping the remote VPN host due to outbound VPN traffic not being forwarded into the IPsec VPN tunnel (ipsec0). Instead, it was forwarded out on WAN Port2, as below

If the SD-WAN policy route is configured, and the Destination network is set to "Any" as below

Here is the solution:

- make sure "VPN routes" are preferred over "SD-WAN policy route.s"

To check route precedence, run the following command in Sophos Firewall SSH terminal > Device Console:
system route_precedence show

To change route precedence, run the Device Console command
system route_precedence set

To make SD-WAN policy routes to be the least preferred, run the Device Console command
system route_precedence set vpn static sdwan_policyroute

- another solution is to use the IP host group "internet IPv4" as the Destination network in the SD-WAN policy route

Note: If Sophos Firewall was freshly installed from v18.5 IOS, there is a default IP host group, "Internet IPv4," which covers all Internet IPv4 addresses.

For Sophos Firewall upgraded from v18.0 or earlier version, we must manually create the IP host group "internet IPv4", as per KBA Sophos Firewall: Auto-create an object for IPv4 internet addresses group.

Once the routing issue is fixed, here is the expected packet capture that the ICMP ping was forwarded into the IPsec VPN tunnel (ipsec0)

---

Revamped RR
[edited by: Erick Jan at 4:46 AM (GMT -8) on 6 Dec 2024]