Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Sophos Firewall: Best practice for site-to-site policy-based IPsec VPN

Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.


Table of Contents

Overview

This article focuses on the best practices to plan and configure a site-to-site policy-based IPsec VPN. It can be applied in general and is not limited to the Sophos Firewall.

Configure the VPN connection

1. Configure only one VPN gateway as initiator

It is recommended to configure one VPN gateway as a VPN initiator and the other as a VPN responder.

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

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

Which VPN gateway should be configured as a VPN responder?

  • The Sophos Firewall should be configured as a VPN responder and the 3rd party VPN gateway should 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 connection should be configured as a VPN responder.

2. Use 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, pre-shared key doesn't work well for the following setup 

  • multiple "respond only" VPN connections are configured, and
  • they are configured with pre-shared key, and
  • they are configured with same remote gateway IP addresses, such as "*"

3. Configure VPN ID

It is recommended to configure a VPN ID for each VPN connection, to prevent mismatch on connection request.

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 should be configured with local VPN ID "utm" (type: DNS), and remote VPN ID "Sophos" (type: DNS)

Note: by default, Remote ID is set to remote gateway address when it is a specific IP address, even if Remote ID type is not configured. Manually configuring VPN ID can avoid the confusion caused by the default behaviour.

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 find out 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 is recommended to summarize local/remote VPN subnets, to improve stability and capacity.

Note: "Create firewall rule" needs to be disable in VPN connection when local/remote VPN subnets are manually summarized.

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

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

If we summarize local and remote VPN subnet, as below

Firewall needs to maintain only 1 IPsec SAs.

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

6. FQDN host in local/remote VPN network is not supported by the Sophos Firewall.

FQDN host in local/remote VPN network is not supported by the Sophos Firewall.

Configure the IPsec policy

1. 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 recommedned. One advantage is it simplifies re-key, and make VPN connection more stable during re-key, 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

Sometime, Sophos Firewall needs to be configured as VPN responder with IKEv1. However, on Sophos Firewall, IKEv1 IPsec policy cannot be used by a "Respond only" VPN connection, by default.

Here is 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 is not 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 built-in IPsec policies to be modified 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 VPN initiator 

It is 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 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 at the same time, otherwise, the VPN will be disconnected on every phase 1 re-key.

Phase 1 and phase 2 will be re-keyed at the same time, 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).

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

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

If re-keying is enabled on peered VPN gateways,

  • both VPN gateways cannot have same phase 1 key life. Otherwise, they will re-key phase 1 at same time, and IPsec VPN might be disconnected.
  • both VPN gateways cannot have same phase 2 key life. Otherwise, they will re-key phase 2 at same time, and IPsec VPN might be disconnected.

Additionally, 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 uneven rekeying events..
  • Cause xfrm gateway down issues 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 IPsec policy must be matched.

How to achieve high VPN speed

Please refer to article Sophos Firewall: Troubleshooting Guide - How to achieve high VPN speed

Configuration guides for a specific scenario

Sophos Community provides detailed guides 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 bewteen Sophos Firewall and Azure, just search for "Sophos Firewall ipsec vpn azure how to"

Common issue

outbound VPN traffic not forwarded into IPsec VPN tunnel

Occasinoally, we might face the issue that local VPN host cannot ping remote VPN host due to outbound VPN traffic not forwarded into IPsec VPN tunnel (ipsec0), instead, it was forwarded out on WAN Port2, as below

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

Here is the solution:

- make sure "VPN routes" is preferred over "SD-WAN policy routes"

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

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

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

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

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

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 expected packet capture that ICMP ping was forwarded into IPsec VPN tunnel (ipsec0)

Edition History

2022-10-25, minor updated to section "How to achieve high VPN speed"

2022-05-31, added section "Common issues"

2021-09-03, minor update to section "Some information about SMB transfer speed"

2021-05-25,

  • updated with section "Use RSA key"
  • updated screenshots

2021-05-20, 

  • updated section "IKE version must be matched on both VPN gateways, and IKEv2 is recommended"
  • simplified section "Configuration guides for a specific scenario"

2021-05-17, 

  • added section "summarize local/remote VPN subnets, to improve stability and capacity"
  • re-formatted the article
  • added links for Sophos Firewall v18 in section "Configuration guides for a specific scenario"

2021-02-15,

2020-08-25, modified the format and wordings -dominicremigio

2020-08-19, first version

______________________________________________________________________________________________________________________________________



Added TAG
[edited by: Erick Jan at 3:48 AM (GMT -7) on 28 Oct 2024]
Parents Reply Children
  • To establish a tunnel, it does not need to match. But there could be "issues" with the life quality of a tunnel. For example, if the life time of a key does not match, the tunnel could be killed after some time, as the peer could close the tunnel. That does not have to occur, but could occur. 

    __________________________________________________________________________________________________________________

  • After changing from RSA to preshared key i see no more Problems in the ipsec logs from both sides. Only the rekeying is vissible in the logfiles. After about one week the faults returned again. IPSEC behind nat bad. IPSEC behind Telekom Digibox worse. No specific Problem of Sophos. Well try IKV2 to IKEV2. Our Experience on other Routers the same problems no matter what you configure..