Configure Sophos Connect on Sophos Firewall

On SFOS 22, Sophos Connect for IPsec Remote Access is configured under Remote access VPN > IPsec. The tunnel alone does not grant access: authentication, client addressing, DNS, firewall rules and the distributed profile must all work together.

This article deliberately focuses on the firewall side. Installation and import are covered separately for Windows and macOS. For SSL VPN, see Set up Sophos Firewall SSL VPN Remote Access; if the architecture is still undecided, consult Sophos Connect or SSL VPN.

Before you begin

A controlled deployment requires:

• administrative access to WebAdmin and a reachable WAN address;
• users or groups in a source supported by Sophos Connect, such as the local database, Active Directory, RADIUS or Microsoft Entra ID, together with a suitable MFA design;
• an unused private client pool, internal destination networks and the services that are actually required;
• DNS servers capable of resolving the intended internal names and, if necessary, a DNS suffix;
• an IKEv1 IPsec profile and either a preshared key or suitable RSA certificates;
• external test connectivity, such as a mobile hotspot. SFOS does not support IPsec Remote Access from the LAN zone.

Before upgrading to SFOS 22.0 MR1 or later, first check whether Legacy Remote Access IPsec must be migrated.

Assign authentication services first

Under Authentication > Services, the required servers must appear in Selected authentication server in the appropriate sections:

• VPN portal authentication methods for the VPN Portal and provisioning;
• VPN (IPsec/dial-in/L2TP/PPTP) authentication methods for signing in to the IPsec tunnel.

A typical setup uses Local plus the directory, RADIUS or Entra ID server configured under Authentication > Servers. Test this assignment before exporting the profile. With Microsoft Entra ID SSO, the Entra ID server must already be selected here before the configuration file is downloaded; otherwise, the .scx file will not contain the SSO values. The complete procedure is described in Microsoft Entra ID SSO for VPN, and OTP configuration in Set up Sophos Firewall MFA.

Define addresses, destinations and a rollback path

To avoid address conflicts, the VPN pool must not overlap with LANs, WLANs, VLANs, site-to-site VPNs or common home networks. SFOS also requires the range to reside in a subnet of at least /24 and not to be used simultaneously for SSL VPN, L2TP or PPTP. One example is 10.250.10.10 through 10.250.10.200 within 10.250.10.0/24.

Before making changes, document the current IPsec configuration, selected certificates and IDs, rule order, and the .scx/.pro versions already in circulation. Keep the old profile in a secure location. If a change fails, you can then restore the individual values and rules without deleting existing users, certificates or other VPN configurations. By contrast, Reset at the bottom of the IPsec page restores the Remote Access IPsec configuration to factory defaults; it is not a normal rollback mechanism.

Configure IPsec Remote Access completely

Older interfaces and the existing screenshot still show VPN > Sophos Connect Client. In SFOS 22, the path is Remote access VPN > IPsec.

General settings

1. Enable IPsec remote access.
2. Under Interface, select the WAN port that will serve as the tunnel endpoint. SFOS permits exactly one WAN interface in this Remote Access configuration; multiple provisioning gateways do not change this tunnel binding.
3. Under IPsec profile, select an IKEv1 profile. It is shown only if Dead Peer Detection is disabled or set to Disconnect. Phase 1 and Phase 2 algorithms, DH/PFS and lifetimes must comply with your security standard. Strong algorithms and PFS are sensible best practices; the IKEv1 and DPD conditions just mentioned are SFOS requirements.
4. Set Authentication type to Preshared key or Digital certificate.
5. Complete Local ID, Remote ID and Allowed users and groups.

A PSK is included in the exported configuration. It must be random and protected and, if compromise is suspected, replaced together with every affected profile. MFA adds protection to user sign-in, but does not replace this tunnel key.

For Digital certificate, SFOS 22 imposes clear restrictions:

• IPsec uses RSA certificates, not ECDSA certificates;
• the Local and Remote Certificate require a Certificate ID;
• External certificate must not be selected;
• the Local and Remote Certificate must come from the same trust chain. Use either locally generated certificates or certificates from the same third-party CA, and upload that CA’s Signing CA to the firewall.

Sophos recommends one Local ID to identify the firewall and a different Remote ID for the clients. Valid types are DNS, IP Address, Email and, for certificates, DER ASN1 DN [X509]. With the latter, the firewall uses the certificate’s Distinguished Name. The IDs do not need to resolve publicly, but the firewall and exported profile must expect the same values.

Authorise users and groups correctly

Under Allowed users and groups, include only the intended accounts. For a directory user, IPsec Remote Access evaluates the Main group. The permitted AD group must therefore be the user’s main group; otherwise, authorise the user explicitly rather than opening access to a broad group.

Also check under Authentication > Groups that IPsec remote access is enabled for the group. The setting is disabled by default for imported AD groups and migrated groups, and enabled by default for newly created local groups. If several groups apply, the policy of the highest group takes effect; an individual user policy takes precedence. Disabling IPsec Remote Access for a group causes SFOS to disconnect its active sessions and prevents reconnection. For more information about group order, see Connect Active Directory to Sophos Firewall.

Before their first conventional Sophos Connect sign-in, AD users generally need to sign in to another Authentication Client, such as the User Portal. Provisioning can create the account at first sign-in and assign it according to the server mapping. Guest users and guest groups are not permitted for Remote Access.

Client information and Idle time

Set every field under Client information deliberately:

• Name: a short, unique display name such as remote-access-ipsec;
• Assign IP from: the start and end of the planned private pool;
• Allow leasing IP address from RADIUS server for L2TP, PPTP, and IPsec remote access: enable only when RADIUS assigns addresses. If RADIUS supplies no address, SFOS first uses a static address configured for the user and otherwise a lease from Assign IP from;
• DNS server 1 and DNS server 2: resolvers that are authoritative for the required zones or forward queries to them correctly.

Public resolvers are not inherently wrong, but they generally cannot resolve private corporate zones unless those zones are published or forwarded appropriately. For internal resources, therefore test the actual authoritative or forwarding DNS path.

Under Idle time, you can enable Disconnect when tunnel is idle. Idle session time interval is specified in seconds. The value is an operational choice: a short timeout reduces abandoned sessions, but can disrupt workflows and MFA reconnections. After an idle disconnect, Sophos Connect attempts to reconnect in the background; if that fails, select Disconnect and then Connect in the client.

Advanced settings

These values are included in .scx, but not in .tgb:

• Use as default gateway: enabled for Full Tunnel, disabled for Split Tunnel. The choice applies to all users listed under Allowed users and groups; different settings within the same IPsec configuration are not possible.
• Permitted network resources (IPv4): internal networks and hosts for the Split Tunnel. Include only resources users should reach through the tunnel.
• Send Security Heartbeat through tunnel: send the heartbeat from an existing Sophos Endpoint through the tunnel.
• Allow users to save username and password: allow only if device security and MFA requirements permit it. Sophos recommends saved credentials for Connect tunnel automatically.
• Prompt users for 2FA token: display a separate OTP field. The firewall still submits passwordotp; challenge-based MFA is not supported. SCCLI does not work with this option.
• Run AD logon script after connecting: run the AD logon script after the tunnel is established.
• Connect tunnel automatically: establish the connection automatically after the user signs in to the endpoint.
• Hostname or DNS suffix to monitor: enter a hostname that resolves only internally, or an internal suffix. Sophos Connect uses it to evaluate the automatic connection; the monitored host must be allowed to answer ICMP probes.
• Assign client DNS suffix: append a suffix such as firma.example to the endpoint’s network adapter so that short hostnames resolve as FQDNs.

With Split Tunnel, SFOS creates separate ESP SAs for the permitted subnets and removes only the affected Child SA when it becomes inactive. With Full Tunnel, a single ESP SA is removed after the idle interval if no traffic flows.

Check reachability before the firewall

If Sophos Firewall is behind a router or another NAT device, that device must translate the public address to the selected firewall WAN interface. For NAT-T, allow and forward UDP 500 and UDP 4500. If there is no NAT in the path, ESP traffic uses IP protocol 50, which the upstream device must also pass. When SFOS detects NAT, NAT-T encapsulates subsequent IKE and ESP packets over UDP 4500.

A conventional TCP/UDP port check therefore does not prove that the entire IPsec path works. Carrier-grade NAT, double NAT or a restrictive guest network can also prevent the tunnel from being established. If the public address is assigned directly to SFOS, no upstream DNAT rule is required.

Firewall rules and Device Access

Access to internal destinations

Under Rules and policies > Firewall rules, create a specific IPv4 rule:

• Rule name: a unique name, for example VPN-SophosConnect-to-ERP;
• Rule position: above a more general Drop rule or a conflicting Accept rule;
• Action: Accept;
• Log firewall traffic: enable for acceptance testing and ongoing operations;
• Source zones: VPN;
• Source networks and devices: the IPsec client pool or a suitable IP host object, not an unnecessarily broad Any;
• During scheduled time: All the time or a justified time window;
• Destination zones: the zone actually required, such as LAN or DMZ;
• Destination networks: only approved servers or networks;
• Services: only the required protocols and ports;
• Match known users and Users or groups: optionally add an identity condition if it suits the authentication design.

SFOS evaluates rules from top to bottom and stops at the first match. After saving, check the effective position; rules created automatically or added to the top later can alter the order. Web, Application Control, IPS, Heartbeat and other security policies are not blanket SFOS requirements for VPN traffic. Select them according to the protection required and test them with the applications.

Full Tunnel internet access

With Use as default gateway, traffic from VPN to WAN also requires a rule:

This rule likewise uses the client pool as the source network, the appropriate services, logging, and the required Web, Application Control or IPS policies. The client pool must also be covered by a suitable SNAT/Masquerading rule; an existing NAT rule may already provide this. A linked NAT rule is possible, but not mandatory. NAT rules are also evaluated in order, so an earlier, broader matching rule takes precedence. A Full Tunnel without coordinated NAT and security policies therefore often produces a green tunnel with no internet access—or unintentionally unfiltered traffic.

Local Service ACL

Firewall rules govern forwarded traffic, not the firewall’s local services. Under Administration > Device access:

• allow IPsec from the WAN zone in use;
• allow VPN portal only from zones that require downloads or provisioning; Sophos recommends WAN access only temporarily;
• allow DNS from VPN only if the firewall itself is used as a DNS resolver;
• allow Ping/Ping6 from VPN only if the firewall itself should be a test target.

Where an entire zone would be too broad, a Local service ACL exception rule can restrict access to specific source hosts or networks. See Device Access and Local Service ACL for details.

Export or provision the profile

Export connection creates an archive containing .scx and .tgb. For Sophos Connect, .scx is the standard and contains both General and Advanced Settings. .tgb is intended for compatible third-party clients and contains only General Settings. After changes to General or Advanced Settings, redistribute the configuration; changes limited to Advanced Settings affect only .scx.

On Windows with Sophos Connect 2.1 or later, a .pro file can download IPsec and authorised SSL VPN configurations from the VPN Portal and automatically retrieve later changes. Sophos Connect provisioning with .pro and GPO describes the exact JSON structure, multiple portal gateways, MFA fields and GPO distribution.

An important troubleshooting distinction: gateway in .pro is the firewall’s FQDN or IPv4 address through which the client reaches the VPN Portal and retrieves configurations. It is not automatically the IPsec tunnel gateway. The tunnel terminates at the Interface selected under Remote access VPN > IPsec and stored in the downloaded .scx. Multiple .pro gateways therefore provide multiple provisioning paths, but not Multi-WAN for this single IPsec Remote Access configuration.

If gateway or the VPN Portal port changes, update and redistribute .pro. If both remain unchanged, provisioning can retrieve the VPN configuration again. With a manually imported IPsec profile, users trigger retrieval in the client through Edit connection > Update policy; updating the client alone does not update the firewall policy. Existing profiles generally remain usable after a Sophos Connect version update alone.

If provisioning retrieves old values or no configuration, check VPN Portal reachability and certificate, portal port, gateway, user sign-in and MFA in that order. With Entra ID SSO, gateway must also match the registered Redirect URI.

Profiles contain security-sensitive information and must be distributed through a protected channel. Give old and new versions unambiguous names so that helpdesk staff and users do not accidentally revert.

Distributing a new firewall policy is separate from updating the client software. Versions, pilot-group approval and rollback planning are covered in Update Sophos Connect safely.

For ongoing operations, document the responsible VPN group and offboarding process, MFA reset, and user lock/unlock procedures. The operating record should also contain the profile version, change date and owner, permanent logging requirements including Sophos Fusion (formerly Sophos Central) or Syslog, and a profile review before SFOS upgrades.

Acceptance testing with a real remote client

After importing the profile, test with a standard target user from an external network:

1. Sign-in and MFA work, and the client receives the expected pool or RADIUS address.
2. The session appears under Current activities > IPsec connections. The list can be filtered by Connection name, Username, Local subnet and Remote host/subnet, among other fields; Refresh updates the view, and Disconnect terminates a specific connection.
3. Internal FQDNs—and short names through the DNS suffix, if configured—resolve correctly.
4. Permitted destinations work; unapproved destinations remain blocked.
5. Log Viewer shows hits on the intended firewall rule.
6. Split Tunnel leaves other internet traffic local; Full Tunnel sends it through the firewall, the expected SNAT rule and the intended security policies.
7. Reconnection works after an idle timeout, a network change and an endpoint restart.
8. In the Sophos Connect client, Events shows the sequence of profile import, sign-in and tunnel establishment. For a reproducible error, generate a Support report in the client and save it with the timestamp, user, client version and profile version before changing profiles or certificates.

For rule analysis, see Test a firewall rule with Log Viewer, Policy Test and Packet Capture. For deeper tunnel analysis, continue with Sophos Firewall IPsec VPN troubleshooting.

Targeted troubleshooting

Sign-in fails

First check Authentication > Services, password/MFA status, lockouts and the authentication server independently of the VPN. Then compare Main group, Allowed users and groups, and the group’s IPsec remote access setting. Sophos Connect supports only ASCII characters in usernames; umlauts and other UTF-8/UTF-16 characters can prevent sign-in.

Rather than relying on a single, ambiguously documented IKE text message as the diagnosis, break the process down: does the attempt reach user authentication; do the interface, IPsec profile, certificate or PSK, and Local/Remote ID match; and is the user actually authorised through their Main group? Client events and firewall logs from the same time provide a more reliable trail.

Failed to validate certificate after a restart

If the first connection works but Failed to validate certificate appears after a restart, the Local and Remote Certificate are often not signed by the same CA. Check the Certificate IDs and trust chain. Use locally generated certificates or certificates from the same third-party CA and upload its Signing CA, or deliberately switch to a PSK. Then export and import .scx again and retest after a restart.

Tunnel is connected, but there is no traffic

First check the lease address and routes on the client, followed by Permitted network resources, rule position, Source/Destination networks, Services, the return route and DNS. For Full Tunnel, also check the VPN-to-WAN rule and the SNAT rule that actually matches. Device access is involved only if the firewall itself is the destination, for example for DNS or ping.

Connection drops approximately every four hours

During IKEv1 rekeying, a new OTP request can disconnect the tunnel. Sophos specifies a rekey interval of approximately four hours for the default IPsec profile; a custom profile can use up to 24 hours. Fix IPsec Remote Access timeouts after four hours explains the security trade-off and implementation.

Large transfers stall or only certain external networks fail

If sign-in, DNS and small requests work but larger transfers stall, check MTU and MSS. If IPsec fails only in hotels, guest Wi-Fi networks or tightly filtered corporate networks, the external connection may block UDP 500/4500 or ESP. SSL VPN or another Remote Access design may be more robust for these users.

Remote Access IPsec after HA failover

The issue documented in the SFOS 22 release notes as NC-175860 affects Remote Access IPsec after an HA failover if the Appliance Certificate had previously been regenerated. It was fixed in SFOS 22.0 MR2 Build 546 on 14 July 2026. Sophos specifies neither a distinct log message nor an official workaround.

Before taking action, record the firmware and build, HA mode, roles and Last status change on both appliances, failover time, Authentication Type, Local/Remote Certificate with their Certificate IDs, and profile version. Do not regenerate the Appliance Certificate on suspicion. On an older affected version, verify the approved upgrade path to MR2 Build 546 or later, then test a controlled failover and external reconnection during a maintenance window. For the topology basics, see Sophos Firewall HA cluster variants; for the upgrade procedure, see SFOS firmware update.

FAQ