Configuration Checklist

Port 500, 4500 Open by ISP

For IPsec to connect, port 500 has to be open by the ISP, please confirm with your ISP that port 500 is open, if you have an upstream device (Sophos Firewall doesn't have a Public IP on the WAN interface) make sure Port 4500 is open by your ISP and that the upstream device is passing down the Port 4500

Traffic arriving on Port 500, 4500

To confirm Port 500 is open, the simplest way is to do a TCPdump on the Firewall.

Access the initiator and Responder and confirm the Public IP and port of the WAN interface that would be used for the IPsec; then on the Responder's Firewall, enter the following string from the advanced shell

Responder's Firewall (substitute the IP as need it)

# tcpdump -eni Port4 host 66.183.140.13 and port 500

We enter for host the Public IP of the Initiator's Firewall because we want to see if traffic arrives on Port 500

In the Initiator's Firewall, enter the Advanced shell and enter the following:

# telnet 207.102.231.209 500

If Port 500 is open on the Responder's Firewall, you will see this traffic:

XGS116_XN01_SFOS 20.0.0 GA-Build222# tcpdump -eni Port4 host 66.183.140.13 and port 500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on Port4, link-type EN10MB (Ethernet), capture size 262144 bytes
14:34:46.713763 Port4, IN: 68:ab:09:47:01:8b > 7c:5a:1c:96:07:25, ethertype I Pv4 (0x0800), length 66: 66.183.140.13.34646 > 207.102.231.209.500: Flags [S] , seq 3654474738, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0

If the Responder's Firewall is behind a 3rd Party device or doesn't have a Public IP, also make sure Port 500 and Port 4500 are being passed down to the Responder's Firewall; you can run the same test as above

To test, the Initiator also has open Port 500; you can run the same command.

IPsec General Settings

Matching Connection Type and IP Version

Access the Sophos Firewall and go to Configure > site-to-site VPN > IPsec > Yourtunnelname:

Make sure that IP version matches both ends 

Make sure that the Connection Type matches both ends

Gateway Type

Access the Sophos Firewall and go to Configure > site-to-site VPN > IPsec > Yourtunnelname:

Make sure the Gateway Type is set accordingly; one Firewall should be the Initiator and the other one the Responder

DO NOT set both Gateways Type with the same value, as this will cause the tunnel to go down during rekey. 

Note: If you have Branch Firewalls, we recommend using your more beefy firewall (usually your HeadQuarters Firewall) as the responder

Profile

Select the Profile you want the IPsec to use when negotiating the connection with the other end. 

For connections between Sophos Firewall devices, we recommend selecting the Branch Office (IKEv2) and Head Office (IKEv2)

Authentication type

Preshared key: If you use dynamic IPs for your IPsecs and set the remote Gateway as '*', try avoiding this, as all tunnels with *, including L2TP, will share the last PSK you entered.
If you need to use PSK and *, select an IKEv2 profile and configure Local and Remote IDs in the IPsec for each tunnel that uses * as the Gateway address.
Digital certificate: Authenticates endpoints by exchanging certificates (locally signed or issued by a certificate authority).
RSA key: Authenticates endpoints using RSA keys. (Easy, Secure, and Fast to implement between Sophos Firewalls) 

Gateway Settings

Local/Remote Gateway

Listening Interface: Only interfaces selected as WAN would show here

Gateway Address: Public IP of the other end; if the other end has a dynamic address, we recommend using a DNS Hostname rather than a *.

Note: You can't set the remote gateway address to a wildcard (*) if you set the Gateway type to Initiate the connection.

Local ID/ Remote ID: The local and remote IDs enable the firewall to identify a remote firewall behind a router with a private IP address in scenarios like AWS, where the firewall doesn't have a direct public IP attached.

Select an ID type and type Local ID value for preshared (PSK) and RSA keys. You can use this to further validate tunnels or identify the firewall during NAT traversal.

Tip: You don't need to enter an actual and valid email address. If you select email, you can enter something like 123@abc.com 

Local Subnet: Enter the IP/Network/IP Range/IP List, of the hosts that will have access to the VPN tunnel.

Remote Subnet: Enter the IP/Network/IP Range/IP of the other side of the tunnel that hosts on the Local Subnet should have access to

Caveats: If you selected "Connection type =  Tunnel interface AND IP version = Dual " The Local and Remote subnets are automatically set as Any/Any

Network Address Translation (NAT): The address you add under Local Subnet is the address the other side of the tunnel would see, while the original subnet is your local (original subnet) 

For more info about Routing and NAT for IPsec check the following link

IPsec Profiles

Matching Key Exchange

For the IPsec Profile you built, make sure the Key Exchange matches on both ends.

If they don't match the tunnel will not come up, and you will see the following error:

[IKE] <XG_TO_XG-1|4177> IKE_SA NO_PROPOSAL_CHOSEN set_condition COND_START_OVER

Note: IKEv2 It's faster and more secure with additional benefits, such as NAT traversal.

Phase 1

Key Life

Enter the time in Seconds.

To prevent key exchange collisions, follow these guidelines:

Set the initiator's key life lower than the responder's.

Set the phase 2 key life lower than the phase 1 value in both firewalls.

For example, see the values in the default profiles Branch office (IKEv2) for the initiator and Head office (IKEv2) for the responder.

Re-Key Margin

Sophos Firewall supports only time-based rekeying. Select time-based rekeying on the third-party firewall to configure an IPsec connection between Sophos Firewall and a third-party firewall.

The re-key margin specifies how much time should remain on the current encryption keys before the firewall initiates the re-keying process.
This value should always be lower than the Key Life

DH Group

Diffie Hellman Group 

Make sure the DH group you select matches the other end. You can select more than one Group. (Allowing multiple groups ensures compatibility between various systems. During the key exchange negotiation, both parties can agree on the strongest common group they support.) 

Encryption

To ensure integrity in data exchange, you can select up to three encryption and authentication algorithms. Ensure that at least one matches in the remote Firewall.

Authentication

Make sure it matches the remote Firewall.

Phase 2

PFS Group (DH Group)

Perfect Forward Secrecy 

Selecting the "Same as Phase 1" uses Phase 1 DH groups for Phase 2 negotiations.

Selecting "None" Turns off PFS. Only select this if a 3rd party doesn't support PFS.

For the other options, the firewall uses the DH group you specify for phase 2 session keys. We recommend selecting a DH group.

Key Life

Enter the time in seconds.

To prevent key exchange collisions, follow these guidelines:

Set the initiator's key life lower than the responder's.

Set the phase 2 key life lower than the phase 1 value in both firewalls.

Encryption

To ensure integrity in data exchange, you can select up to three encryption and authentication algorithms. Ensure that at least one matches in the remote Firewall.

Authentication

Make sure it matches the remote Firewall.

Dead Peer Detection

We recommend you turn on Dead Peer Detection.

Select Dead peer detection to check if the peer is available.

For Check peer after every, enter the time in seconds.

For Wait for response up to, enter the response time in seconds for IKEv1. If the peer doesn't respond within this time, it's considered unavailable.

Note:

For IKEv1, the number of checks depends on the response time you specify.

For IKEv2, the number of checks depends on the default IKE message retransmission time-out. So, this value has no effect.

When the peer is unreachable, select an action from the following options:

Hold: Retains the installed traffic selectors and renegotiates the tunnel on demand.

Disconnect: Closes the connection. Use this for the head office.

Re-initiate: This immediately triggers an attempt to renegotiate the connection when there's a DPD timeout. Use this for remote offices.

The firewall tries to re-initiate the tunnel based on the number of Key negotiation tries you specify.