Set up Sophos Connect provisioning with .pro and GPO

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 available to the user. Sophos Connect imports the actual .scx or .ovpn file only after successful authentication.

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.

⚠️ Remote provisioning requires the VPN portal to be reachable from WAN. This increases the publicly exposed attack surface. Before rollout, use a trusted certificate, MFA, narrow 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, allow the VPN portal only from the source zones or networks that are actually 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 deploy Sophos Connect and the .pro file to a small pilot group through a controlled GPO.
8. Validate portal sign-in, imported profiles, tunnel, internal destinations, logs, Update Policy, 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 authorized users. 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.

A manually distributed .scx or .ovpn file remains useful when the VPN portal shouldn’t be published to the internet, only a few clients exist, or the portal is an unwanted additional dependency. Sophos Connect doesn’t support .pro provisioning on macOS; .scx and .ovpn are imported directly there. IPsec provisioning on Windows requires Sophos Connect 2.1 or later.

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.
• With Microsoft Entra ID SSO, the VPN portal, IPsec, and SSL VPN use the same Entra ID server under Authentication > Services in the provisioning workflow.
• With Entra ID SSO, the gateway value matches the firewall’s Redirect URI.
• MFA and the negative test with an unauthorized 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.

Create the provisioning file

A .pro file is JSON. gateway is the only required field, but a display name and portal port should still be set explicitly for traceable operation. 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.

At connection startup, check_remote_availability checks reachability. run_logon_script runs the logon script provided by the domain controller after the tunnel is established. Enable either option only when the pilot confirms that the corresponding behavior is required.

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.

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.

A complete always-on design has additional constraints. Saved credentials, SSO, MFA, and behavior after network changes must fit together. Start SSL VPN automatically with auto-login explains these 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 isn’t 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.

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 behavior before broad deployment. The firewall-side MFA configuration is covered in Set up Sophos Firewall MFA.

Deploy Sophos Connect and .pro through GPO

The file can be imported manually after delivery by email or secure download. Users select Import connection or double-click the .pro file. In a managed Windows domain, a GPO is easier to trace when its source, target group, and rollback are documented.

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 behavior and doesn’t prove that portal authentication or the tunnel already works.

For deployment, add a startup script under Group Policy Management > Computer Configuration > Policies > Windows Settings > Scripts > Startup. The pattern documented by Sophos waits for the scvpn service, downloads the file from a central HTTPS location, and copies it to the import folder. The download source should be readable only by the required computers, use a trusted certificate, and contain no user passwords or tokens in the URL or script.

Test the startup script on a pilot computer first. The policy can then be refreshed with this command:

gpupdate /force

Sophos also documents a computer startup script with msiexec.exe for installing the client itself. In a production software deployment, use the established packaging, signature, version, and rollback standards instead. Install Sophos Connect on Windows covers installation and supported Windows platforms.

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

Changes and profile updates

After successful import, Sophos Connect automatically retrieves the available .scx and .ovpn profiles. It also retrieves many later configuration changes. Operations must still distinguish between the provisioning file and the actual 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, select the gear icon and Update policy in the client.
• Changes to the SSL VPN gateway, certificate, port, or protocol may require another sign-in.
• After restoring or importing a firewall configuration, retest the IPsec and SSL VPN profiles with a pilot client.
• A new client version doesn’t automatically update an outdated .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 authorized and an unauthorized 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. An unauthorized user must not receive a usable profile or access internal destinations.
8. Test a harmless policy change with Update policy or automatic retrieval.
9. Test a client restart, network change, and GPO reapplication.
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.

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. IPsec is provided to all appropriately authorized users; SSL VPN is provided only to members of a matching policy.

Certificate or Entra SSO errors

The public name in gateway must match the certificate. With Entra ID SSO, the same value must also match the Redirect URI, and the VPN portal, IPsec, and SSL VPN must use the same Entra ID server in the provisioning workflow. Even a different hostname or port can interrupt the workflow.

Check the Microsoft Entra sign-in in the Entra sign-in log. On the firewall, vpnportal.log, access_server.log, and oauth_sso_vpn.log help at the corresponding stages. Test connection for the authentication server doesn’t replace portal or tunnel authentication.

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.

GPO doesn’t import the file

Check whether the GPO actually applies to the computer account, the startup script is reachable, the scvpn service is running, and the download source is reachable from the system context. Then verify file permissions and the exact import path. Repeated copying without identifying the cause can redeploy stale settings and shouldn’t become a permanent startup-script workaround.

Roll back safely

First stop deployment to the affected GPO target group. Then remove automatic .pro deployment, provide the previously approved manual .scx or .ovpn file, and test it with a pilot user. 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