Understand and securely configure Sophos Firewall IPsec profiles

An IPsec profile determines how securely and under which conditions an IPsec tunnel is negotiated. It defines the IKE version, encryption, integrity, DH group, PFS, lifetimes, rekeying, and Dead Peer Detection. If these values do not match the peer, the tunnel remains down or fails later during rekeying.

Quick recommendation for new Site-to-Site connections: Use IKEv2, offer only the strong proposals that are actually required, enable PFS and rekeying, and configure DPD for the firewall’s role. If both peers support the values, AES256GCM16 with DH19 and PFS19 is a modern starting point. However, provider and peer requirements always take precedence.

This article explains the profile. The actual connection, including gateway, IDs, networks, rules, NAT, and routing, is covered in Set up Sophos Firewall Site-to-Site IPsec VPN. If an existing tunnel does not establish or carry traffic, see Sophos Firewall IPsec VPN troubleshooting.

What an IPsec profile controls

The profile contains the shared security parameters for Phase 1 and Phase 2. One profile can be assigned to multiple connections. For precisely this reason, a system or production profile that is in use should not be changed spontaneously: the change can affect every associated tunnel during the next connection attempt or rekey.

The profile does not contain:

public peer address or FQDN
Preshared Key, certificate, or RSA Key
Local ID and Remote ID
local and remote networks or Traffic Selectors
firewall rules, NAT, and routing
XFRM address, SD-WAN Route, or failover path

These values are configured in the IPsec connection or the associated network rules. A green Phase 1 status therefore proves neither that Phase 2 matches nor that user traffic is routed and permitted correctly.

Authentication is not the same as Authentication type

In an IPsec profile, Authentication refers to an integrity algorithm such as SHA2 256. In the IPsec connection, Authentication type determines whether the peers identify themselves with a Preshared Key, certificate, or RSA Key.

These two fields perform different tasks. A correct SHA2 256 therefore cannot fix an incorrect PSK, and a matching certificate cannot compensate for an incompatible Phase 1 proposal.

Phase 1 and Phase 2 explained

Phase 1 establishes the protected IKE Security Association. The peers authenticate each other over this control channel and negotiate additional keys and parameters. At a minimum, the IKE version, encryption, integrity, and DH group must be compatible.

Phase 2 creates the Child or IPsec Security Associations for the actual user traffic. Phase 2 encryption, integrity, PFS, and the Traffic Selectors apply here. A tunnel can therefore complete Phase 1 successfully while no Child SA is created because of an incorrect PFS value or a mismatched Phase 2 combination.

With IKEv2, the first Child SA can be established together with the IKE SA. As a result, a PFS or rekeying issue may not become visible until hours later, when the Child SA must be renewed. Validation is not complete until at least one rekey has been observed without an interruption.

Coordinate parameters with the peer

Before configuration, both administrators record and agree on the values in writing. A screenshot is often insufficient because vendors use different names for the same function.

At least the following details should be documented:

role: initiator, responder, or initiation from either side
IKE version and, for IKEv1, Main or Aggressive Mode
Phase 1 Encryption, Authentication, and DH group
Phase 1 Key Life, Re-key Margin, and randomization
Phase 2 Encryption, Authentication, PFS, and Key Life
time-based rekeying and which side initiates it
DPD interval and action when the peer is unreachable
known provider limits and permitted proposals

The profile name does not have to be identical on both devices. What matters is that at least one complete combination is compatible on both sides. More proposals are not automatically better: they increase the attack and error surface and can enlarge IKE packets enough for fragmentation to become a problem.

Choose a secure baseline configuration

The following examples are Avanet starting points for new Site-to-Site connections. They do not override requirements from Azure, AWS, a carrier, or a third-party firewall.

Modern profile for controlled peers

If both sides support current algorithms:

Key exchange: IKEv2
Phase 1: AES256GCM16, DH19
Phase 2: AES256GCM16, PFS19
Re-key connection: On
Use strict profile: On
Compression: Off
SHA2 96-bit truncation: Off
Dead peer detection: On

AES256GCM16 is an AEAD algorithm: it provides encryption and integrity protection in one operation. This combination uses no additional Authentication algorithm such as SHA2. GCM16 refers to the 16-byte authentication tag, not 16-bit encryption.

The Pseudo-Random Function for IKE key generation cannot be selected separately in SFOS. The firewall derives it from the offered integrity algorithms and coordinates it with the peer.

DH19 uses an elliptic curve and provides a good balance between security level, packet size, and computational overhead. AES128GCM16 is also a current algorithm and is not automatically insecure for a normal 128-bit security level. The overall strength is always determined by the weakest component in the profile.

Compatibility profile for current third-party devices

If the peer does not support AES-GCM or an ECP group, this combination is a more widely compatible starting point:

Key exchange: IKEv2
Phase 1: AES256, SHA2 256, DH14
Phase 2: AES256, SHA2 256, PFS14
Re-key connection: On
Dead peer detection: On

Here, AES operates in CBC mode and therefore requires the separate integrity protection SHA2 256. DH14 and PFS14 are compatibility choices, not the preferred modern option when both peers support DH19.

Avoid for new profiles

For new designs, avoid IKEv1, Aggressive Mode, DES, 3DES, Blowfish, MD5, SHA1, and DH groups 1, 2, and 5. PFS: None should likewise remain a documented exception only for peers that do not support PFS.

Despite its position in the Phase 2 Encryption field, AES-GMAC does not provide encryption; it only provides authentication and integrity. A normal confidential Site-to-Site tunnel therefore uses AES-GCM or AES with an appropriate SHA2 algorithm.

Document legacy exceptions with the reason, affected peer, risk, owner, and replacement date. A weak combination should not remain alongside strong proposals merely because the tunnel can also establish with it. The BSI TR-02102-3 on IPsec and IKEv2 and the NIST Guide to IPsec VPNs provide technical guidance.

When an environment must meet formal cryptographic requirements, the dedicated guide explains how FIPS 140-3 mode on Sophos Firewall affects platforms, profiles, certificates, backups, and HA. FIPS compliance doesn’t replace the deliberate selection of a modern common proposal.

Clone or create a profile

Menu path:

Profiles > IPsec profiles

For Sophos-to-Sophos connections, the paired system profiles provide transparent templates:

Branch office (IKEv2) for the initiating branch
Head office (IKEv2) for the responding head office

Clone the appropriate profile and give it a clear name, for example Branch-Zurich-IKEv2. This keeps the system profile unchanged and allows the previous tunnel profile to be reassigned during a rollback.

General settings

Key exchange: Use IKEv2 for new Site-to-Site connections. Use IKEv1 only for a documented legacy peer.
Authentication mode: Exists only for IKEv1. Do not use Aggressive Mode because authentication information receives less protection during transmission.
Key negotiation tries: Sophos recommends 0. However, for a VPN failover group, SFOS sets the effective value to 3.
Re-key connection: Turn it on so that new Phase 1 and Phase 2 keys are negotiated before expiry. SFOS only supports time-based rekeying.
Use strict profile: Turn it on when the peer proposals are known exactly. SFOS then offers only the configured parameters. Check the provider’s requirements first for provider profiles; the official AWS example, for example, does not use this option.
Pass data in compressed format: Leave this off under normal circumstances. Turn it on only when its benefit and support on both sides are confirmed.
SHA2 with 96-bit truncation: Turn it on only for a documented compatibility requirement, not as a general security improvement.

Use strict profile reduces unexpected fallbacks and can help when oversized IKE proposals cause problems. However, it is not an option that should be enabled blindly in every provider profile.

Phase 1

Phase 1 contains Key life, Re-key margin, Randomize re-keying margin by, the DH group, and up to three pairs of Encryption and Authentication algorithms.

SFOS accepts 120 to 86400 seconds for Key Life, 30 to 999 seconds for Re-key Margin, and 0 to 100 percent for randomization. A formally accepted value is not automatically appropriate: the Margin must remain considerably lower than the Key Life and must match the peer’s behavior.

Enter only the DH groups and proposals that are actually required. The known issue NC-136352 can occur when a default IKEv2 profile offers so many DH groups that the IKE packet grows larger than 1'500 bytes. If an intermediate component drops fragments, the initiator repeatedly transmits while the responder sees nothing. For a known peer, one confirmed DH group is the cleanest configuration.

Phase 2

Phase 2 contains PFS, Key Life, Encryption, and Authentication for user traffic.

PFS forces a new DH key exchange during a Phase 2 rekey. If a long-term key is compromised later, this is intended to prevent older recorded sessions from being decrypted using the same key material. Therefore, enable PFS and select a value that matches the peer. In modern profiles, the PFS group often matches the Phase 1 DH group.

Choose a Phase 2 Key Life that is shorter than the Phase 1 Key Life. This renews the keys for user traffic more frequently than the IKE control channel.

Dead Peer Detection

DPD detects a peer that no longer responds. It replaces neither Gateway Monitoring nor a real application test.

Branch or initiator: Re-initiate, so that the firewall immediately attempts a new connection after a DPD timeout.
Head office or responder: Disconnect, so that the stale connection is closed. Hold is a deliberate alternative when the Traffic Selectors should remain installed and renegotiation should occur only when new traffic arrives.
Check peer after every: Check interval in seconds.
Wait for response up to: Applies only to IKEv1. With IKEv2, SFOS uses its internal IKE retransmission timeout; the entered value does not change this behavior.

For IPsec failover groups, SFOS disables DPD for the assigned connections and sets Key negotiation tries to 3. The group condition then performs the monitoring. The linked guide explains member order, the Failover Condition, and Automatic failback; the profile view alone does not show the entire effective failover behavior.

Understand lifetimes and rekeying correctly

Key life is not a session or idle timeout. It limits the lifetime of a Security Association. Before it expires, the negotiation of new keys starts within the Re-key Margin.

Shorter lifetimes renew keys more frequently, but they cause more processing overhead and more opportunities for interoperability or rekeying failures. Longer lifetimes reduce this overhead but use the key material for longer. Therefore, neither the shortest nor the longest accepted value is automatically the best choice.

NIST lists 86400 seconds for the IKE SA and 28800 seconds for the IPsec SA as common guidance. Sophos and cloud providers use different values depending on the role and platform. These figures are therefore not a universal SFOS profile.

Sophos recommends the following to prevent rekey collisions:

The initiator’s Key Life is shorter than the responder’s.
The Phase 2 Key Life on both firewalls is shorter than the Phase 1 Key Life.
Rekeying is enabled on at least one side and explicitly uses time-based rekeying with third-party devices.

Randomization changes the Re-key Margin, not the complete Key Life. With an eight-hour Key Life, a ten-minute Margin, and 20 percent randomization, Sophos states that rekeying starts between 7 hours 48 minutes and 7 hours 52 minutes.

For providers, use their exact values. The documented AWS example uses approximately 28000 for Phase 1, a Re-key Margin of 360, randomization of 50, and 3600 seconds for Phase 2 on Sophos Firewall. This is an AWS example, not a general Avanet default.

Assign and safely test the profile

During a maintenance window, assign the new profile only to the intended connection first. Document the profile name, previous values, and rollback before making the change.

For Site-to-Site, assign it under:

Site-to-site VPN > IPsec

Remote Access IPsec also uses profiles but has different limits: the current Sophos Connect configuration accepts IKEv1 profiles with DPD disabled or set to Disconnect. Therefore, do not reuse the modern Site-to-Site IKEv2 profile for Remote Access without checking it. The complete procedure is covered in Configure Sophos Connect on Sophos Firewall. The specific OTP/rekeying case is covered in Sophos Connect disconnects after about four hours.

After the tunnel establishes, check the status and recent IKE messages read-only in the Advanced Shell:

ipsec statusall
tail -n 200 /log/strongswan.log

Then test real traffic in both directions. The Child SA byte counters must increase. Repeat the test after at least one Phase 2 rekey; only then have lifetimes, PFS, and rekeying behavior truly been validated.

Typical causes by symptom:

Tunnel remains completely down: Check the IKE version, Phase 1 Encryption, Authentication, DH, Strict Profile, ID, and peer authentication.
NO_PROPOSAL_CHOSEN before Phase 1: Compare Phase 1 proposals.
Phase 1 is up, but the Child SA is missing: Check Phase 2 Encryption, Authentication, PFS, and Traffic Selectors.
Disconnection after a similar interval: Compare Key Life, Re-key Margin, randomization, and initiator/responder values.
Tunnel is green, but no traffic flows: Do not change the profile first; check firewall rules, NAT, routing, the return path, and byte counters.

If the change causes problems, reassign the documented previous profile to the connection. Services, databases, or Advanced Shell configurations do not need to be changed for a normal profile rollback.