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"
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 showTo change route precedence, please run Device Console commandsystem route_precedence setTo make SD-WAN policy routes to be the least preferred, please run Device Console commandsystem 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)
2022-05-31, added section "Common issues"
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
Regarding section "5. Settings don't need to be matched", this KB seems to disagree (See problem #6):
support.sophos.com/.../KB-000038566
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.
__________________________________________________________________________________________________________________