Set up Sophos Connect provisioning with .pro

A Sophos Connect provisioning file with the .pro extension isn’t a complete VPN profile. It tells the Windows client which VPN portal to use to retrieve the IPsec and SSL VPN configurations. After a successful portal sign-in, Sophos Connect imports the .scx file and, if the user is assigned to an SSL VPN policy, also the .ovpn file. A visible profile does not yet mean that tunnel authentication or access to internal destinations is permitted.

This is particularly useful when profiles must be distributed centrally and later changes should be retrieved automatically. At the same time, the VPN portal becomes part of the production sign-in path. Its reachability, certificate, MFA, user assignment, and hardening are therefore just as important as the JSON syntax of the file.

⚠️ If external users are to provision from the WAN, the VPN portal must be reachable from the WAN. This increases the publicly exposed attack surface. Before rollout, use a trusted certificate, MFA, the narrowest possible Local Service ACLs, tested login blocking, and a fallback with a manually distributed profile.

Provisioning in eight steps

1. Fully configure IPsec Remote Access or SSL VPN on the firewall and test it with a manually imported file.
2. Provide the VPN portal through a trusted FQDN and certificate.
3. Under Administration > Device access, enable the VPN portal only for the required zones. To restrict access to specific source networks, an appropriate Local Service ACL exception rule is also required.
4. Create a minimal .pro file with display_name, gateway, and vpn_portal_port.
5. Add MFA, auto-connect, and gateway ordering only when the corresponding workflow is already defined.
6. First import the file manually with a pilot user and test IPsec and SSL VPN separately.
7. Then hand the approved .pro file over to the managed Windows rollout and deploy it to a small pilot group first.
8. Validate portal sign-in, imported profiles, tunnel, internal destinations, logs, profile updates, and rollback.

When a .pro file is suitable

Provisioning is well suited to managed Windows endpoints that use Sophos Connect for IPsec, SSL VPN, or both. After the portal sign-in, the firewall provides the IPsec profile to all users. This does not mean that every user may successfully authenticate the tunnel or access internal destinations. An SSL VPN configuration is imported only when the user is a member of a matching SSL VPN policy.

During initial provisioning, SFOS can automatically create a directory user that doesn’t yet exist locally and assign the user to a group based on the authentication server mapping. The user doesn’t need to sign in to the VPN portal or user portal beforehand. This automatic creation doesn’t replace validation of the group order and actual VPN permission.

Manual .scx and .ovpn files remain useful when the VPN Portal should not be publicly reachable, only a few clients exist, or the portal is an unwanted additional dependency. .pro retrieves IPsec (.scx) and the user’s authorised SSL VPN configurations (.ovpn) through the VPN Portal and fetches later changes; it is not itself a tunnel profile. Supported clients include compatible Windows clients and Sophos Connect for macOS from 2.1, not macOS client 2.0 or earlier. IPsec provisioning requires Sophos Connect 2.1 or later. On macOS client 2.0, direct imports and controlled manual refresh remain required.

Update to the dated observation: Sophos release notes list Sophos Connect 2.1 for macOS, released on October 6, 2026, with .pro provisioning, Entra ID SSO and native ARM support. The September 24, 2026 observation describes the situation at that time. Check the version of the installer actually available; publication does not prove that your firewall portal already serves that package or that it has been tested on a specific device.

The actual VPN configuration remains in the focused guides: Configure Sophos Connect IPsec on the firewall and Set up SSL VPN remote access.

Requirements and example values

The following example uses the public portal name vpn.example.com and the internal probe host intranet.corp.example. Both names are placeholders:

• Replace vpn.example.com with the real VPN portal FQDN that resolves correctly both publicly and internally. The portal certificate must be valid for this name and trusted by the clients.
• Use intranet.corp.example as auto_connect_host only when the host is reliably reachable and responds exclusively from the internal network. A public or unreliable host would distort network detection.
• Port 443 is the default VPN portal port. If the firewall uses another port, the same value must be set in vpn_portal_port.

At least the following points must be successfully tested before creating the file:

• The intended IPsec or SSL VPN profile works with a manual import.
• The VPN portal is reachable through the intended FQDN and uses a complete certificate chain.
• Users, primary groups, SSL VPN policy, and authentication methods match.
• For SSO provisioning, the VPN portal, IPsec, and SSL VPN use the same configured identity provider (IdP) server under Authentication > Services: Microsoft Entra ID in the SFOS 22 documentation, or a supported OpenID Connect (OIDC) IdP in SFOS 23.
• gateway matches the firewall FQDN or IP address configured in the IdP server’s Redirect URI section. Enter only that host, not the complete callback URI with scheme, port, and path; set the portal port separately in vpn_portal_port.
• MFA and the negative test with an unauthorised user work.

For public portal access, see Device access and Local Service ACL. Brute-force protection for the VPN portal covers repeated failed sign-ins and hardening a WAN-facing portal.

Select the SSO version and provider

For Windows with Sophos Connect 2.4 or later, the SFOS 22 guidance describes Entra ID SSO; the SFOS 23 guidance broadens this to supported OIDC IdPs. This is not support for every OIDC provider or proof of availability in a particular firmware build. Use the matching version branch in Entra ID VPN SSO or the SFOS 23 Google Workspace OIDC setup. Google’s redirect requirements call for a valid public FQDN, not an IP address. These guides own provider setup, service assignments, and troubleshooting.

For direct .scx or .ovpn downloads without .pro, first select the IdP under Authentication > Services, then download the profile. SSL VPN must use the same IdP for the portal and tunnel; direct IPsec can use the same or a different IdP. Do not apply that IPsec exception to provisioning.

For macOS 2.1 or later, the client guidance names Entra ID SSO, not general OIDC support. The saved requirements and client guidance differ in their macOS coverage; confirm support for the intended firmware/client/VPN combination and pilot it separately. The macOS browser field below remains Entra-only; GPO, import-folder automation, and logon scripts remain Windows-only.

Create the provisioning file

A .pro file is JSON. gateway is the only required field. The display name and portal port should nevertheless be set explicitly so that the configuration can be reviewed unambiguously. Create the file with a text editor and save it, for example, as avanet-vpn.pro.

Minimal profile for one gateway

[
  {
    "display_name": "Avanet Remote Access",
    "gateway": "vpn.example.com",
    "vpn_portal_port": 443,
    "otp": false,
    "auto_connect_host": "",
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

display_name can contain no more than 60 characters. Without a display name, Sophos Connect shows the gateway value. With can_save_credentials set to true, users can save their username and password; this setting isn’t used for SSO. Allowing saved credentials is a security decision, not a convenience default.

Fields that are not specified use the vendor defaults. The example deliberately sets them all so that a review does not overlook implicit values:

With check_remote_availability, the client performs a reachability check when the connection starts. run_logon_script applies only to Sophos Connect for Windows; allowed values are true and false, with a default of false. It runs the logon script provided by the domain controller after the tunnel is established. The logon script remains disabled until a pilot test confirms the need and behaviour.

The older user_portal_port syntax is still accepted, but it now also identifies the VPN portal port. vpn_portal_port is clearer for new files.

Choose the Entra ID SSO browser on macOS

The optional sso_auth_browser_type field applies only to Microsoft Entra ID SSO with Sophos Connect for macOS version 2.1 or later. It is not a Windows setting or a general browser setting for other identity providers. Use these literal values:

• auto: the default; uses the in-app browser and can fall back to the system browser if needed.
• embedded: uses the browser integrated into Sophos Connect.
• system: uses the operating system’s default browser.

If the field is omitted or contains an invalid value, Sophos Connect uses auto. For a suitable macOS Entra configuration, add this optional property to the connection object in the .pro file:

"sso_auth_browser_type": "auto"

This is only a JSON fragment, not a complete .pro file. Place the property alongside gateway in the existing object; separate properties with commas, without a comma after the last property. auto makes the default explicit for review; set embedded or system only for a deliberately selected browser workflow verified in a pilot. Sophos Connect on macOS covers import and interactive sign-in; the field syntax is described here.

Plan auto-connect correctly

auto_connect_host helps Sophos Connect determine whether the client is already on the internal network. Whenever a network interface receives a new or changed IP address, the client checks this host. If it isn’t reachable, the connection is enabled. The tunnel is established automatically when credentials are saved or the last sign-in used SSO.

"auto_connect_host": "intranet.corp.example"

The probe host isn’t a general internet health check. It must be stable and resolvable internally and must not be reachable externally. Test it both on the corporate network and through an external network before rollout. An empty string "" disables auto-connect.

For always-on operation, saved credentials, SSO, MFA, and behaviour after network changes must be coordinated. Start SSL VPN automatically with auto-login explains the differences.

Use multiple gateways

Multiple portal gateways are entered as an array. gateway_order only determines how Sophos Connect selects the portal for retrieval. The later tunnel uses the gateways in the imported .scx or .ovpn configuration.

[
  {
    "display_name": "Avanet Remote Access",
    "gateway_order": "in_order",
    "gateway": [
      "vpn-zrh.example.com",
      "vpn-ber.example.com"
    ],
    "vpn_portal_port": 443,
    "otp": false,
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

The selection modes have different operational effects:

• in_order tries the entries in the defined order.
• latency selects the gateway based on the response time of a TCP connection attempt.
• distributed selects a gateway at random when a connection is attempted.

The order is not a substitute for a tested WAN, DNS, or HA design. Every listed portal name needs a valid certificate, matching reachability, and the same expected provisioning content.

Multiple connections must be distinguished from this. Two separate objects in the outer JSON array create two entries in Sophos Connect, for example one for employees and one for administrators. By contrast, one object with multiple values in the gateway field remains a single connection with alternative provisioning gateways. Before combining both variants, define the names, target groups, and fallback paths.

Set MFA fields deliberately

With otp: true, Sophos Connect shows a third input field. 2fa determines how its contents are sent to the authentication server:

• 2fa: 1 uses the Sophos Firewall configuration. Password and OTP are concatenated as passwordotp.
• 2fa: 2 uses an external service such as Duo. Password and code are separated by a comma; depending on the Duo configuration, push, phone, sms, or a token passcode are also possible.

[
  {
    "display_name": "Avanet Remote Access MFA",
    "gateway": "vpn.example.com",
    "vpn_portal_port": 443,
    "otp": true,
    "2fa": 1,
    "can_save_credentials": false,
    "check_remote_availability": true,
    "run_logon_script": false
  }
]

The sign-in dialog may appear twice during the first retrieval: once to download the configuration and again to establish the tunnel. This isn’t automatically an error. The help desk should understand this behaviour before broad deployment. The firewall-side MFA configuration is covered in Set up Sophos Firewall MFA.

The GPO and import-folder steps below apply to Windows. On macOS from 2.1, import the approved .pro directly into the client and pilot the package, portal access, profile retrieval and VPN connection separately; do not transfer Windows paths or GPO steps to the Mac.

Import on Windows and hand off to managed deployment

The file can be provided through a protected download and imported manually. Users select Import connection or double-click the .pro file. Email is only appropriate when transport and recipients are controlled; user passwords, OTPs, and tokens must never be placed in the file.

Sophos Connect monitors this import folder:

C:\Program Files (x86)\Sophos\Connect\import\

A .pro file placed there is imported automatically and then deleted from the folder. Deletion is normal behaviour and doesn’t prove that portal authentication or the tunnel already works. This folder handoff is the interface to managed deployment.

GPO startup scripts, client packaging, SCCLI, exit codes, and the full rollback path belong in Deploy Sophos Connect on managed Windows endpoints. That workflow hands the approved .pro to the already installed client as a separate, versioned artefact, keeping package rollout and profile provisioning independently verifiable.

For the pilot import here, document the approved source-file version or hash, hand the file to the import folder, and then verify which connection actually appears in the client. The source should be readable only by the intended devices, use a trusted certificate, and contain no credentials in a URL or script. Install Sophos Connect on Windows additionally covers installation and supported Windows platforms.

A .pro file normally contains no user passwords. It is nevertheless a controlled configuration artefact: portal addresses, behaviour, MFA, and auto-connect settings should come only from an authorised source.

Reusable .pro metadata and SSL identity

The raw .pro file is reusable provisioning metadata, not a user’s SSL VPN certificate or private key. The SFOS 22 client documentation distinguishes it from the SSL profile generated during import: that profile and its certificates are associated with the importing user identity, authentication method, and domain. For another authentication method or domain, import a separate .pro or the user’s own .ovpn; reusing the imported SSL profile can cause Login failed. Wrong fingerprint of certificate. This documented restriction does not apply to IPsec .scx profiles.

An .ovpn file contains user-specific certificates and private keys: never share it between users. Reusing approved raw .pro metadata does not mean sharing a generated SSL profile or exporting another user’s keys. Windows import and sign-in and macOS import and sign-in cover the client steps; apply this version qualification to the SSL binding/fingerprint guidance.

The saved SFOS 23 client documentation omits the SFOS 22 identity-binding section without explaining a runtime change. That omission proves neither relaxed profile reuse nor unchanged binding on every version. Until authoritative version-specific clarification is available, keep SSL imports separate by identity/authentication method/domain as a safety precaution and do not present this precaution as a verified SFOS 23 runtime rule.

Changes and profile updates

After successful import, Sophos Connect automatically retrieves the available .scx and .ovpn profiles. The provisioning file also retrieves later changes to these configurations automatically. Operations must still distinguish between the retrieval path in the .pro file and the retrieved VPN profile:

• If gateway or vpn_portal_port changes, update and redistribute the .pro file.
• If the port or protocol changes under SSL VPN global settings, users must click the gear button for the connection in the client and select Update policy.
• The client retrieves other changes to the provided VPN profile automatically. Changes to the SSL VPN gateway, server certificate, port, or protocol may require users to sign in again.
• If gateway and the VPN portal port in the .pro file remain unchanged after a restore or configuration import, it automatically retrieves the affected IPsec and SSL VPN configurations again.
• If this provisioning path has changed, redistribute and reimport the .pro file.
• Without a working .pro file, use the direct-profile workflow: reimport affected IPsec configurations; after changes to the SSL VPN port, protocol, interface, or server certificate, download the .ovpn file from the VPN portal again and reimport it.
• A client update is not a substitute for controlled redistribution of a changed .pro file.

Don’t distribute old and new provisioning files in parallel through different GPOs, downloads, and emails. Document the filename, version or modification date, target group, and fallback for each rollout.

Validate provisioning and the tunnel

Test with an authorised and an unauthorised user from a real external network. Successful portal authentication alone isn’t a successful VPN test.

1. Check the Sophos Connect version and Windows platform.
2. Import the .pro file manually or through the pilot GPO.
3. Verify which .scx and .ovpn connections actually appear.
4. Complete the MFA workflow, including a possible second sign-in.
5. Connect IPsec and SSL VPN separately if both are offered.
6. Check the lease address, internal DNS resolution, destination server, firewall rule, and return path.
7. For the unauthorised user, distinguish between profile import and access: an IPsec profile may appear, but the tunnel or internal access must fail at the intended authentication and policy stage. An SSL VPN .ovpn file must not be imported without a matching policy.
8. Test both update paths: a normal profile change must arrive automatically through the imported .pro file; after changing the SSL VPN port or protocol, select Update policy in the client.
9. Test a client restart, network change, and another handoff through the chosen deployment method.
10. Test manual fallback to an approved .scx or .ovpn profile.

With Microsoft Entra ID SSO, also check the Redirect URI, Conditional Access, and forced reauthentication on shared endpoints. Microsoft Entra ID SSO for Sophos Connect and the VPN portal explains the full mapping.

For the SSO pilot, record firmware version, client version, and IdP. Use the version branch selected above, check the same IdP assignment across provisioning services, and separately test portal retrieval and the tunnel with authorised and unauthorised users. SSL identity guidance remains version-qualified; a successful pilot does not generally resolve the outstanding SFOS 23 source-documentation conflict.

Troubleshoot systematically

No connection is imported

First check that the file contains valid JSON, ends in .pro, and was imported by the client. Then verify gateway, vpn_portal_port, DNS, the certificate chain, and VPN portal reachability. A file disappearing from the import folder was processed, but this doesn’t prove successful authentication.

If the client reaches the portal but receives no profile, check the configured IPsec connection, SSL VPN policy, group membership, and authentication methods. The IPsec .scx file is provided to all users; an SSL VPN .ovpn file is provided only to members of a matching policy.

Certificate or SSO errors

The public name in gateway must match the certificate and the firewall host in the configured IdP’s Redirect URI section. Check vpn_portal_port separately. In SSO provisioning, the VPN portal, IPsec, and SSL VPN must use the same IdP. Validate portal retrieval and tunnel authentication separately for the selected SFOS/client/provider branch; a visible profile or successful Test connection proves neither.

For Entra, correlate the attempt with the Entra sign-in log, including MFA and Conditional Access. Follow the version-specific diagnosis in Entra ID VPN SSO: its legacy SSO log names apply to SFOS 22, not every OIDC deployment. For SFOS 23 Google, follow Google Workspace OIDC troubleshooting. Do not transfer provider-specific log or restart instructions across versions.

MFA appears twice or fails

Two sign-ins can be expected during the initial retrieval. If authentication fails, compare otp, 2fa, the configured Sophos or external MFA method, and the expected input format. passwordotp and the comma-separated external method aren’t interchangeable.

The profile exists, but traffic doesn’t work

Provisioning has then progressed beyond the actual failure point. Check the lease range, client routes, DNS, firewall rule, NAT, return path, and packet capture separately. For IPsec, continue with Sophos Firewall IPsec VPN troubleshooting.

The managed handoff doesn’t import the file

First test a manual import of the same approved file. If it works, the fault is in the handoff rather than the .pro schema. Then check service status, system context, source access, file permissions, and the exact import path. Continue package, GPO, and SCCLI diagnosis in managed Windows deployment. Blind redistribution without identifying the cause is no substitute for troubleshooting.

Roll back safely

For rollback, first stop deployment to the affected target group so that no further import occurs. Stopping the handoff does not delete connections that have already been imported. On pilot devices, remove or replace them in a controlled manner before importing and testing the previously approved manual .scx or .ovpn file. Revert VPN portal, Device Access, or authentication changes only after no production provisioning depends on them.

Remove and reimport the existing Sophos Connect connection on test clients in a controlled manner. Repeat portal sign-in, tunnel, DNS, internal destination, and negative tests. Remove the faulty .pro file from central repositories and software deployment only after the fallback path works.

FAQ