Configure Sophos Connect on Sophos Firewall

Sophos Connect is the standard client for Remote Access with Sophos Firewall in many environments. The actual quality of the solution is not decided only on Windows or macOS, but on the firewall: user authorisation, IP pool, DNS, authentication, MFA, firewall rules and later profile distribution all need to fit together.

This article describes firewall-side planning and configuration for Sophos Connect, mainly for IPsec Remote Access and profile deployment. For SSL VPN, the actual Remote Access policy is described in Set up Sophos Firewall SSL VPN Remote Access. For the basic decision between IPsec, SSL VPN, mobile clients and ZTNA, start with Sophos Connect or SSL VPN: which Remote Access solution fits?.

Which article fits?

Depending on the task, a different starting point makes sense:

This separation matters because Sophos Connect touches several areas: IPsec configuration, SSL VPN configuration, VPN Portal, provisioning, authentication, client version and firewall rules.

Requirements

• Sophos Firewall with a supported SFOS version
• Admin access to the WebAdmin interface
• defined users or groups for Remote Access
• free IP address range for VPN clients
• internal DNS servers if internal names need to be resolved
• MFA concept for Remote Access
• clarified destination networks and services that should be reachable over VPN
• clear process for profile distribution, profile changes and client updates

If the firewall is to be updated to SFOS 22.0 MR1 or newer, first check whether Legacy Remote Access IPsec is still present. This old configuration can block the upgrade. The procedure is described in Migrate Legacy Remote Access IPsec before SFOS 22 MR1.

In current SFOS versions, IPsec Remote Access configuration is under Remote access VPN > IPsec. In older interfaces or older guides, paths such as VPN > Sophos Connect Client may still appear. Existing screenshots and older customer environments can therefore use different wording.

Plan before configuration

Before enabling the feature, briefly document how Remote Access will be operated later. This prevents typical mistakes such as overlapping IP pools, overly broad firewall rules or profiles that are not redistributed after a change.

Important planning questions:

For MFA basics, see Set up Sophos Firewall MFA. If Remote Access later uses Microsoft Entra ID SSO, RADIUS or AD, the authentication path should also be tested separately.

Profile types and deployment

Before configuration, it should be clear which file will later end up on which client. This prevents many support cases.

For new Sophos Connect IPsec rollouts, .scx is usually the better default because it contains the advanced settings from the firewall. .tgb should only be used deliberately when a third-party client or an old process requires it.

Provisioning can simplify distribution, but it increases dependency on the VPN Portal. If users are to use the provisioning file from the Internet, the VPN Portal must be reachable from the required zone. This belongs under Administration > Device access and should be deliberately hardened in the Local Service ACL because a WAN-reachable portal creates additional attack surface. For hardening, see Device Access and Local Service ACL on Sophos Firewall.

Enable Sophos Connect

Open Remote access VPN > IPsec in the WebAdmin interface. In older interfaces, the path may still be VPN > Sophos Connect Client. The exact display can vary slightly depending on the SFOS version, but the basic decisions remain similar.

1. Enable Connect Client

Enable IPsec Remote Access. Only then set the remaining settings and do not roll it out to production immediately.

2. Choose the external interface

The interface is usually the WAN interface through which Remote Access connections reach the firewall. With multiple WAN links, decide deliberately which link is stable for VPN, documented and reachable from the Internet.

Check:

• public IP or correct DynDNS/FQDN exists
• port forwards and upstream routers fit
• WAN failover behaviour is known
• Device Access and local service ACLs allow only required services
• VPN Portal is reachable only where it is really needed for download or provisioning

Remote Access is a publicly reachable entry point. Function alone is therefore not enough; access, MFA and logging must be considered as well.

For hardening reachable firewall services, see Device Access and Local Service ACL on Sophos Firewall.

3. Choose authentication

Different authentication models are available for IPsec Remote Access depending on SFOS version and configuration. Preshared Key and certificate are common relevant options.

Practical classification:

• Preshared Key is quick to set up, but must be strong, protected and rotated if there is suspicion.
• Certificate is cleaner for controlled environments, but requires certificate management and clear processes.
• MFA replaces neither PSK nor certificate, but additionally protects user sign-in.

If the Preshared Key has been distributed in several profiles, changing it is operationally more complex. The key should therefore not be treated as a disposable value.

For certificates, also check whether certificate type, lifetime, private keys and target client fit together. RSA certificates are especially relevant for IPsec Remote Access. Certificate changes are always also a profile and rollout topic.

4. Check local and remote ID

Local and remote ID are optional, but can be important with multiple tunnels or special peers. If they are set, they must match the profile used and the client configuration.

Typical values are:

• DNS name
• IP address
• Email
• Certificate

In simple setups, these fields often stay empty. If errors such as no IKE config found or proposal/ID problems occur later, this area must be included in the check. For deeper analysis, Sophos Firewall IPsec VPN troubleshooting is the better follow-up article.

5. Assign users and groups

Select only the users or groups that really need Remote Access. In production environments, a dedicated VPN group is usually better than a broad default group.

Check:

• Group contains only authorised users.
• Leavers are removed.
• MFA is active and tested for these users.
• Helpdesk knows how users are blocked, unblocked or newly provisioned.

Guest users do not belong in Remote Access. For production environments, a dedicated VPN group is better than a broad default group from the directory service.

Configure client data

6. Assign names

The connection name should be understandable for users and support. Names such as homeoffice, remote-access-ipsec or a site name are more helpful than internal abbreviations.

If several profiles are distributed, naming should remain consistent. This reduces mix-ups in the Sophos Connect Client.

7. Define IP pool

The firewall assigns VPN clients an address from the defined pool. This range must not overlap with internal networks, other VPN pools, Site-to-Site networks or common home network ranges.

Good practice:

• separate address range only for Remote Access
• sufficient size for simultaneous users
• no overlap with 192.168.0.0/24, 192.168.1.0/24 or common home network ranges where avoidable
• clear documentation in IPAM or network documentation

If the pool is changed later, profiles and tests must be checked again.

For IPsec Remote Access, the pool should at least be planned cleanly as its own subnet. It must also not overlap with other Remote Access pools such as SSL VPN, L2TP or PPTP.

8. Enter DNS servers

If users need to reach internal systems by name, suitable DNS servers and, if required, search domains must be distributed. In many environments this is an internal domain controller or dedicated DNS server.

External resolvers such as Cloudflare, Google, Quad9 or OpenDNS do not resolve internal zones. Such resolvers only make sense if no internal names are required through the VPN tunnel or DNS is deliberately solved differently.

Examples of external resolvers:

• Cloudflare: 1.1.1.1 and 1.0.0.1
• Google: 8.8.8.8 and 8.8.4.4
• Quad9: 9.9.9.9 and 149.112.112.112
• OpenDNS: 208.67.222.222 and 208.67.220.220

For production Remote Access, reliable internal FQDN resolution is usually more important. If DNS is not planned cleanly, the tunnel appears “connected” to users even though applications cannot be used.

Check advanced settings

9. Set Session Timeout

A Session Timeout prevents unused VPN connections from remaining open indefinitely. Values that are too aggressive can create support cases because users have to reconnect after short interruptions.

A useful value fits the working model:

• short timeouts for occasional admin access
• longer timeouts for stable work sessions
• clear communication if users need to reconnect after inactivity

If OTP/MFA is used, also test the effect on reconnects.

If the firewall disconnects an idle client, the Sophos Connect Client can rebuild the connection in the background. If that fails, the user must deliberately disconnect and reconnect the connection in the client. This behaviour should be known in the helpdesk process.

10. Set Advanced settings deliberately

The advanced settings determine how the client behaves in daily use. For IPsec Remote Access, they are included in the .scx file, not in the .tgb file.

Important points:

With Full Tunnel via Use as default gateway, an additional firewall rule from VPN to WAN and a deliberate NAT/security policy design are required. With Split Tunnel, the permitted internal resources must be documented cleanly.

If Prompt users for 2FA token is active, operation is often clearer for users. At the same time, check whether the tools or automations in use work with this setting.

11. Save and export configuration

After saving, the connection configuration is exported. Depending on the client and SFOS version, .scx, .tgb or provisioning files may be relevant. The file should not be stored openly or passed to unauthorised people.

After changes to user group, pool, DNS, profile, gateway, port, certificate or Advanced Settings, the affected clients must receive the updated configuration. Old profiles are a common cause of VPN problems that are difficult to understand.

If provisioning is used, also check whether the client reloads the changes automatically or whether users must update the policy in Sophos Connect Client or sign in again. Changes to SSL VPN port, gateway, server certificate or protocol are typical cases where another sign-in or deliberate update step may be necessary.

Set up firewall rules

Sophos Connect only establishes the tunnel. Access to internal systems is still controlled by firewall rules. Without suitable rules, the connection can be green while no productive access works.

For access from VPN clients to internal systems, a rule from VPN to LAN or to a specific destination zone is typically created.

• Source Zone: VPN
• Destination Zone: LAN

A rule for the actually required networks or services is usually better than broad access to the whole LAN. Logging should be enabled for the introduction phase so that errors are visible in the Log Viewer.

If the client works as Full Tunnel and Internet traffic should also pass through the firewall, an additional rule from VPN to WAN and a deliberate NAT/security policy design are required.

• Source Zone: VPN
• Destination Zone: WAN

For troubleshooting rules, Test firewall rules with Log Viewer, Policy Test and Packet Capture is helpful.

Firewall rules should not only “work”, they should be verifiable. For the introduction phase, logging on the Remote Access rules is useful. Later, decide which rules should be logged permanently and which events should additionally go to Sophos Central or Syslog.

Test after rollout

A green Sophos Connect status is not enough as an acceptance test. At least these points should be checked with a test user:

• Client imports the configuration without errors.
• Sign-in works with password and MFA.
• Client receives an address from the expected VPN pool.
• Internal DNS names are resolved correctly.
• Central internal systems are reachable.
• Log Viewer shows the expected firewall rule.
• Split Tunnel or Full Tunnel behaves as planned.
• Reconnect after a network change works.
• Old profiles were not reused.
• With Full Tunnel, Internet access through the firewall works as planned.
• With Split Tunnel, non-permitted destinations remain blocked.
• Log Viewer shows hits on the expected rules.
• With provisioning, profile changes are updated traceably.

Afterwards, the installation guides for Windows and macOS can be used.

Operational checklist

After the technical rollout, operations should not remain undefined:

• Responsible VPN group documented.
• Leaver process removes users from Remote Access groups.
• MFA reset process is known.
• Profile version or change date is documented.
• Helpdesk knows which profiles are current.
• Log Viewer and relevant service logs are known.
• Changes to IP pool, DNS, gateway, certificate and Advanced Settings trigger a profile check.
• Legacy Remote Access IPsec and client profiles are checked before SFOS upgrades.

Troubleshooting

Connection is established, but no traffic flows

The cause is often not the tunnel, but firewall rules, NAT, routing, DNS or the return path. First check in the Log Viewer whether traffic from the VPN zone hits the expected rule. Then narrow it down with Packet Capture or Policy Test.

User cannot sign in

Check user group, authentication server, MFA, blocked user and password status. If AD, RADIUS or Microsoft Entra ID SSO is involved, authentication should be tested separately from VPN.

Client uses an old configuration

After changes to IP pool, DNS, user group, profile, gateway, certificate or Advanced Settings, the configuration must be redistributed or reimported. Old .tgb, .scx, .ovpn or provisioning files should not remain in circulation in parallel.

Provisioning does not work

First check whether the VPN Portal is reachable from the required zone and whether Device Access was set deliberately. Then check gateway value, portal port, certificate, user sign-in, MFA and, with Entra SSO, the assignment under Authentication > Services.

SSO works only partially

With Microsoft Entra ID SSO, VPN Portal, IPsec and SSL VPN must match the correct Entra ID server depending on the workflow. With provisioning, the gateway value must match the Redirect URI of the Entra configuration. If only individual users are affected, also check UPN, email address, group mapping and imported user groups.

Connection is up, but large transfers hang

If login, DNS and small accesses work, but larger file transfers or certain applications hang, MTU/MSS should be checked. The error pattern often fits fragmentation, PPPoE, tunnelled connections or an asymmetric path. The procedure is described in Check Sophos Firewall MTU and MSS for VPN problems.

IPsec drops in third-party networks

IPsec can be blocked in hotels, guest Wi-Fi networks, mobile networks or strictly filtered corporate networks. In such cases, check whether SSL VPN Remote Access, ZTNA or another Remote Access design is a better fit.

Full Tunnel has no Internet access

If Use as default gateway is active, traffic from VPN to WAN must be allowed and handled with suitable NAT. Web Protection, Application Control, DNS and logging should also be planned deliberately as with other client networks.

FAQ