Note: Please contact Sophos Professional Services if you require direct assistance with your specific environment.
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.
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?
RSA 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
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.
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 will create 2 IPsec SA
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,
The VPN can be established, and 2 IPsec SA will be created
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.
FQDN host in local/remote VPN network is not supported by the XG firewall.
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.
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:
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:
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"
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.
If re-keying is enabled on peered VPN gateways,
No need to worry about it, if only one VPN gateway has re-key enabled.
The following settings in the IPsec policy don't need to be matched on peered VPN gateways.
All other settings in IPsec policy must be matched.
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:
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.
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"
2021-09-03, minor update to section "Some information about SMB transfer speed"
2021-05-25,
2021-05-20,
2021-05-17,
2021-02-15,
2020-08-25, modified the format and wordings -dominicremigio
2020-08-19, first version