Best practice for site-to-site policy-based IPsec VPN

Note: Please contact Sophos Professional Services if you require direct 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 XG 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 XG 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 XG 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 XG 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 XG 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 XG firewall is configured with local VPN ID "xg" (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 "xg" (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. XG firewall doesn't automatically summarize VPN subnets

The XG 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,

  • XG 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

XG 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.

XG firewall accepts IPsec SA of split remote VPN subnets. For example,

  • XG 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 XG firewall.

FQDN host in local/remote VPN network is not supported by the XG firewall.

Configure the IPsec policy

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

On the XG 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 XG 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, XG firewall needs to be configured as VPN responder with IKEv1. However, on XG 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 XG firewall has to be configured as a VPN responder and the remote VPN gateway only supports IKEv1.

Note:

  • The XG 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 XG firewall, as the XG 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.

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

1. VPN throughput is always lower than the WAN link throughput, due to the delay caused by packet encryption/decryption.

2. VPN tunnel is sensitive to packet loss. Please make sure there is a 0 packet loss between the WAN IP of the VPN gateways. Packet loss that is higher than 2% reduces VPN throughput drastically from my personal experience.

3. To achieve high data transfer speed in the VPN, please ensure low latency between the WAN IP of the VPN gateways.

Here are the steps to check the packet loss and network latency between the XG firewall WAN IP and the remote VPN gateway WAN IP:

  • Log on to the XG firewall SSH terminal using the admin account. Once authenticated, you will be presented with the Sophos Firewall console menu.
  • Go to 5. Device Management > 3. Advanced Shell, and run the following commands:
    ping -i XG_WAN_IP REMOTE_WAN_IP -s 1200 -c 50

    The above command sends 50 ping requests from the specified XG firewall WAN IP to the remote VPN gateway WAN IP with ICMP data payload of 1200 bytes.

4. Please also make sure there is a 0 packet loss and low latency between the VPN gateway LAN IP and the internal computers.

5. To test the VPN speed, it is recommended to ping/transfer files between computers in the local VPN subnet and the remote VPN subnet.

It is not recommended to ping from the LAN IP of the XG firewall to the LAN IP of the remote VPN gateway, as it might not be in the VPN subnet.

Some information about SMB transfer speed

  • SMB, Windows File Share is extremely sensitive to packet loss and latency.
  • SMB requires 0 packet loss.
  • SMB transfer speed is determinted by network latency.
    The following speed was tested in a 1Gbps link with 0 packet loss:
    • 0ms latency, SMB speed is 247MB/s
    • 5ms latency, SMB speed is 18MB/s
    • 10ms latency, SMB speed is 10.6MB/s
    • 15ms latency, SMB speed is 8.32MB/s
      In comparison, the HTTP transfer speed can reach 51.2MB/s on a link with 15ms latency.

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"

Edition History

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



2021-05-25
[edited by: taowang at 9:40 AM (GMT -7) on 25 May 2021]

[edited by: FloSupport at 1:04 AM (GMT -7) on 8 Jun 2021]