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 these settings, AES256GCM16 with group 19 (ecp256) for DH and PFS is Avanet’s modern starting point. It is neither a Sophos default nor a general vendor recommendation; the peer’s requirements 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. Before making a change, check which connections use it. Rather than editing a shared system or production profile directly, clone it and initially test the clone only with the intended connection.

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. Depending on the peer, a PFS or rekeying issue may therefore remain hidden until the Child SA is renewed with CREATE_CHILD_SA. Avanet recommends observing at least one Phase 2 rekey during acceptance testing.

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. Unneeded proposals complicate coordination and can make IKE packets unnecessarily large. The specific SFOS impact of the known issue NC-136352 is explained with the Phase 1 fields below.

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. They deliberately show only the proposal and feature selections, not a complete profile: lifetimes, Re-key Margin, DPD interval, and DPD action depend on the peer and on whether the firewall acts as initiator or responder.

Modern profile for controlled peers

If both sides support current algorithms:

Key exchange: IKEv2
Phase 1: AES256GCM16, 19 (ecp256)
Phase 2: AES256GCM16, 19 (ecp256)
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. For this combination, SFOS uses no additional Authentication algorithm such as SHA2.

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.

Group 19 (ecp256) uses an elliptic curve. For controlled, up-to-date peers, Avanet prefers it to the older MODP groups. AES128GCM16 is also a current algorithm. The applicable cryptographic policy and the profile’s weakest component determine which combination is acceptable.

Compatibility profile without AES-GCM or ECP

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

Unlike the AES-GCM entries, AES256 is configured in SFOS with the separate Authentication algorithm SHA2 256. DH14 and PFS14 are Avanet compatibility choices, not the preferred modern option when both peers support group 19 (ecp256).

Avoid for new profiles

DES is not listed as a supported IPsec algorithm in SFOS 22. IKEv1, Aggressive Mode, 3DES, Blowfish, MD5, SHA1, and DH groups 1, 2, and 5 remain selectable, but should not be used for new profiles. 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.

The documented selection in SFOS 22 and 23 depends on the IKE version and phase:

AES128GCM16, AES192GCM16, and AES256GCM16: in IKEv2 Phase 1 and in Phase 2 of both IKE versions, not in IKEv1 Phase 1.
AES128GMAC, AES192GMAC, and AES256GMAC: only in Phase 2 of both IKE versions, not in Phase 1.
TwoFish and Serpent: in Phase 1 and Phase 2 of IKEv1, not IKEv2.

These are selectable algorithms, not combinations bound to particular DH groups or hash algorithms, and not recommendations for new profiles.

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, according to Sophos, authentication information is transmitted in cleartext.
Key negotiation tries: This field specifies the number of attempts to negotiate the tunnel key exchange before the firewall stops. 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. Clearing this option prevents the local firewall from initiating a rekey, but it can still respond to peer rekey requests. The peer must then initiate renewal; rekeying remains enabled on at least one side.
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: Avanet normally leaves this disabled. Enable it only if the peer supports IPComp and the bandwidth savings justify the added complexity.
SHA2 with 96-bit truncation: This option shortens the authentication HMAC hash values. Turn it on only for a documented compatibility requirement, not as a general security improvement.

Use strict profile excludes unconfigured system defaults from the IKE exchange and can help with oversized IKE proposals. However, it is not an option to enable 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. Enter Key life and Re-key margin here in seconds. In Aggressive Mode, only one Encryption/Authentication combination can be saved per phase; the warning against this mode still applies.

Do not simply choose the largest value accepted by an input field. The Re-key Margin must remain considerably shorter than the Key Life and must suit the peer’s behavior; randomization changes only this margin.

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. This phase also allows up to three Encryption/Authentication combinations. Enter its own Phase 2 Key life in seconds. The rekey settings configured in Phase 1, including margin and randomization, also govern Phase 2 rekey timing; Phase 2 nevertheless retains its own Key Life.

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.

Under Use PFS group, Same as phase 1 uses the DH groups selected in Phase 1 for Phase 2 negotiation. Selecting an explicit group instead sets the Phase 2 DH group directly; None disables PFS. Inheriting the same groups does not mean PFS requires a different numeric group value.

Sophos recommends setting the Phase 2 Key Life 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. If the Phase 2 tunnel has been idle, DPD checks peer availability before data is sent.

Branch or initiator: Re-initiate, so that the firewall immediately attempts a new connection after a DPD timeout. The number of Re-initiate attempts depends on Key negotiation tries.
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 IKEv1, the number of checks depends on the response time configured here.

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 SP 800-77r1 recommends 24 hours for the IKE SA and 8 hours for the IPsec SA. These are vendor-neutral NIST recommendations, not SFOS defaults. Sophos and cloud providers use different values depending on the role and platform.

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 a Phase 1 Key Life of 28000, a Re-key Margin of 360, and randomization of 50 percent on Sophos Firewall; Phase 2 uses 3600 seconds. 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.

Profiles also apply under Remote access VPN > L2TP. L2TP uses a Preshared Key or digital certificate and does not support IKEv2. The modern Site-to-Site baseline therefore cannot be applied to L2TP.

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

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 this additional Avanet acceptance step also validates lifetimes, PFS, and rekeying behavior.

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. No Advanced Shell changes are required for this rollback.