Set up Sophos Firewall SSL VPN Remote Access

Remote Access SSL VPN is configured on Sophos Firewall under Remote access VPN > SSL VPN. Six components must work together for secure access:

Assign users or groups to an SSL VPN policy.
Configure the protocol, certificate, gateway, lease range, and DNS globally.
Deliberately choose Split Tunnel or Use as default gateway.
Allow traffic from the VPN zone with tightly scoped firewall rules.
Secure the VPN Portal, authentication, MFA, and Device Access.
Distribute a current .ovpn profile or, on Windows, a .pro provisioning file and test both permitted and blocked access.

⚠️ SSL VPN is a publicly reachable entry point. MFA and strong passwords do not replace tightly scoped user groups, Local Service ACLs, firewall rules, current profiles, logs, and regular reviews.

This article covers the firewall side. Client installation is documented separately for Windows, macOS, iPhone and iPad, Android, and Linux. For the initial choice between SSL VPN, IPsec, and ZTNA, see Sophos Connect or SSL VPN.

Prepare requirements and objects

Before configuration, define the public access point, authorized users, and internal destinations:

current SFOS version and current Sophos Connect client;
public FQDN or public IP address;
certificates for the SSL VPN tunnel and VPN Portal;
users or groups and the authentication server;
MFA method for the portal and tunnel;
non-overlapping SSL VPN lease range;
internal destination networks, DNS servers, and search domain;
decision between Split Tunnel and Full Tunnel;
process for profile distribution and client updates.

Create the internal destinations as hosts or network objects first:

Hosts and services > IP host

The following example uses:

LAN_Server: 10.10.10.0/24 for internal servers;
LAN_Client: 10.10.20.0/24 if remote users genuinely require this client network;
DNS_Internal: 10.10.10.10 for the internal DNS server or domain controller;
SSLVPN_Users: user group for the policy members.

Do not allow entire internal networks when individual servers or subnets are sufficient. DNS servers also need a clearly defined object so that the route and firewall rule remain easy to understand later.

Configure global SSL VPN settings

The global settings apply to all Remote Access SSL VPN policies and are included in the .ovpn configuration:

Remote access VPN > SSL VPN > SSL VPN global settings

These settings are also used for SSL Site-to-Site connections between two Sophos Firewalls. When changing the port, protocol, certificate or Override hostname, check both Remote Access profiles and existing SSL Site-to-Site tunnels, and redistribute their configurations.

Before changing global profile values, record Protocol, Port, Override hostname, SSL server certificate, lease and DNS values, and the configuration of affected SSL Site-to-Site peers. Include any upstream NAT or port forwarding in the rollback plan. If acceptance testing fails, restore these values and the previous Site-to-Site configuration, then repeat the portal, tunnel, permitted-access, and blocked-access tests with the old profile.

Protocol, certificates, gateway, and port

SSL VPN supports TCP and UDP. UDP is usually the more efficient starting point; TCP can be a tested alternative when external networks block UDP. Test the choice from actual hotel, mobile, or guest networks.

The default SSL VPN port is 8443, while the VPN Portal uses 443 by default. A unique combination of WAN IP, port, and protocol for each publicly reachable service is easiest to understand and operate.

Sophos uses two separate certificates:

The SSL server certificate selected in the global SSL VPN settings is used by the SSL VPN server.
The VPN Portal HTTPS certificate is selected under Administration > Admin and user settings.

Both certificates should match the public FQDN used for the respective service. Certificates from an external CA also require the necessary certificate chain.

Override hostname defines the FQDN or public IP address in the client profile. This is particularly important with upstream NAT, multiple WAN interfaces, or DDNS. If the field is empty, the profile can contain multiple interface addresses. Sophos Connect prioritizes DDNS gateways and tries additional entries in reverse order, so a single, unambiguous FQDN is easier to test and operate.

The VPN Portal and SSL VPN can technically share the same port and protocol. In that case, login security settings do not work as intended, and the VPN Portal becomes reachable from the zones enabled for SSL VPN. WAF must differ from the VPN Portal by WAN IP or port, and from SSL VPN by WAN IP, port, or protocol. Sophos Firewall WAF explains the additional WAF dependencies.

Lease range and DNS

The IPv4 lease range must be private and must not overlap with internal networks, site-to-site VPNs, static routes, other Remote Access pools, or common home networks. Frequent examples are 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 10.0.0.0/24, and 10.0.1.0/24.

The SFOS 22 documentation contradicts itself about the permitted mask for smaller IPv4 pools. The field help states that /24 is the limit and that /25 or smaller subnets can’t be selected, while the current FAQ also describes smaller subnets that are split internally across multiple OpenVPN instances. The installed SFOS version is therefore authoritative: check which mask its UI offers, then verify the actual number of available leases.

According to the Sophos FAQ, the number of concurrent SSL VPN instances depends on the CPUs in the firewall model. Each instance creates a tun0 interface and needs its own subnet for routing and internal traffic distribution. SFOS divides the configured pool accordingly; this address overhead occurs before client leasing. As an illustration, the FAQ gives 192.168.0.0/27 with eight concurrent instances and just one remaining leasable IP address. This is not a universal capacity figure or a recommended example network: verify actual leases on the target build and model; the field-help-versus-FAQ conflict described above remains unresolved.

SFOS 23: The selectable IPv4 range depends on the firewall model; larger models support subnets with more IP addresses. The SFOS 23 help identifies /24 as the smallest selectable subnet. This is a model-dependent selection limit, not a promise of a particular number of client leases. CPU-dependent internal splitting explains address overhead, but not the supported selection ranges. It does not resolve the SFOS 22 conflict or turn the /27 illustration into a configuration recommendation.

Before changing the range, record the SFOS build, model, previous range and static assignments, and retain the previous values for rollback. Select only a range supported by the target model in its UI, keep static user addresses within the resulting static range, and check the actual available leases. Then reconnect a pilot user and test the lease, DNS, permitted destinations and blocked destinations. If acceptance fails, restore the previous values and assignments and retest. If the build, UI, help or FAQ disagree, stop the dependent capacity rollout until support clarifies the discrepancy; do not force a mask.

SFOS 23 XML API – status 551: The raw status row for Configure SSLVPN Tunnel Access refers to the unresolved runtime identifier Message.SSLVPNInvalidLeaseIPv4Mask. It establishes neither confirmed message wording, a definite rejection cause nor a new supported mask range. If the API returns 551, retain the complete response and the previous settings. Before making any change, check StartIP, SubnetMask and the pool selection supported by the installed build and model using the help approved for that environment or with Sophos Support; do not force a mask.

After a supported correction, verify the API response, the settings actually saved on the target firewall and the lease of a reconnected pilot user. Retain the previous values and assignments for the rollback described above. If the diagnosis or message wording remains material to approval and unresolved, keep deployment pending.

A small pool is not an access control; use the policy and firewall rules for that. Use the system hosts ##ALL_SSLVPN_RW and, for IPv6, ##ALL_SSLVPN_RW6 in firewall rules.

Enter internal DNS servers under IPv4 DNS. Domain name contains the search domain appended to short hostnames. With Split Tunnel, the DNS server or its network must also be included under Permitted network resources and allowed by a firewall rule from the VPN zone. With Full Tunnel, the Split Tunnel route is not required, but the firewall rule remains necessary.

If the firewall itself acts as the DNS resolver, enter its appropriate address under IPv4 DNS. In addition, allow DNS for the VPN zone under Administration > Device access. A test by IP address and a separate test by hostname distinguish routing issues from DNS issues.

Static IPs, parallel sessions, and time settings

Static SSL VPN IP addresses are possible for justified exceptions, such as a legacy IP-based allowlist, and must remain within the configured pool. However, a user with a static SSL VPN IP address cannot establish parallel Remote Access sessions.

Separately, Simultaneous logins under Authentication > Services or on the local user limits parallel sign-ins. The global value applies only to users created afterwards.

Key lifetime controls rekeying; it is not an idle timeout or maximum session timeout. Idle connections are controlled by the global idle settings and optionally by Disconnect idle clients in the policy. For unexpected disconnects, check these values, the static IP assignment, parallel sign-ins, and logs separately.

Disconnect dead peer after is a global value in seconds and closes unresponsive clients. The defaults are 180 seconds for TCP and 100 seconds for UDP; SFOS accepts values from 60 to 110 for UDP. Disconnect idle peer after, by contrast, is specified in minutes and closes genuinely idle sessions. Before increasing a value, use sslvpn.log, the client log, and packet-loss evidence to determine which timer is actually firing.

A policy’s Override global timeout can only shorten the global idle value. If the policy value is higher, the global value still applies. An older Sophos troubleshooting page recommends a higher policy value for individual users, but the current SFOS 22 field help explicitly contradicts this. To allow longer sessions, do not make an ineffective increase in the policy; adjust the global value after an impact assessment and retest with the same user group.

Create the SSL VPN policy

Create the policy manually or with the wizard:

Remote access VPN > SSL VPN

Sophos recommends the wizard particularly for the first SSL VPN policy. It displays the global settings for review but cannot change them. It applies the selected authentication servers and methods, configures Device Access for the VPN Portal and SSL VPN, and creates the policy and firewall rule. On first use, it creates the Automatic VPN rules group at the top of the rule table and enables the new rule. Later wizard rules are placed at the bottom of this group. Check their position and the Rule ID that actually matches after every run. In existing environments, Configure manually is often more transparent:

Select Add > Configure manually.
Enter a Name, for example SSLVPN-Remote-Users.
Under Policy members, select the SSLVPN_Users group.
Choose Split Tunnel or Use as default gateway.
For Split Tunnel, select LAN_Server and DNS_Internal as Permitted network resources. Use network or host objects here, not interfaces: selecting an interface doesn’t ensure access to its subnet.
Optionally configure Disconnect idle clients and Override global timeout.
Save and verify the result with a regular member of the target group.

Guest users and guest groups cannot be used as policy members. If a user or group is already included in an older SSL VPN policy, SFOS removes the assignment from the earlier policy. Check for overlaps before saving.

A policy-specific Override global timeout only takes effect when it is lower than the global idle value. A higher value does not override the global limit.

Split Tunnel or Full Tunnel

With Split Tunnel, only the IPv4 and IPv6 networks and supported FQDN destinations selected under Permitted network resources are routed through the VPN. FQDN destinations are supported for IPv4 only. All other internet traffic remains local. This reduces firewall load and latency but requires precise resource and DNS planning.

If the IP address of an allowed FQDN destination changes, existing tunnels are not updated automatically. Affected users must disconnect and reconnect.

With Full Tunnel, enable Use as default gateway. All user traffic then passes through the firewall. Permitted network resources are not enforced as an access limit in this mode. Firewall rules must restrict internal destinations and services, and IPv4 internet access also requires a suitable SNAT/MASQ rule.

Full Tunnel enables centralized web, DNS, and log control, but increases bandwidth requirements, firewall load, privacy considerations, and support overhead. Test it with actual applications and the expected number of concurrent users.

Firewall rules, Device Access, and authentication

Firewall rules and DNS

Establishing the tunnel does not grant access to internal resources. Create a firewall rule:

Rules and policies > Firewall rules

Split Tunnel example:

Rule name: VPN_SSLVPN_to_Internal_Servers
Action: Accept
Source zone: VPN
Source networks and devices: ##ALL_SSLVPN_RW
Destination zones: LAN
Destination networks: LAN_Server, DNS_Internal
Services: only the required application services and DNS
Log firewall traffic: enabled

Place the rule above broader VPN rules. A negative test to a destination that should be blocked reveals whether a general rule further down unintentionally permits the traffic.

For IPv4 Full Tunnel, add a rule from VPN to WAN and a suitable SNAT/MASQ rule. IPv6 requires deliberate IPv6 routing and separate IPv6 firewall rules instead. If access fails, use the Log Viewer, Rule ID, and the guide to testing firewall rules.

VPN Portal, Device Access, and MFA

Check the portal, local services, and authentication in separate locations:

Administration > Admin and user settings
Administration > Device access
Authentication > Services
Authentication > Multi-factor Authentication

At a minimum, configure:

SSL VPN in the zones from which users may establish the tunnel;
VPN Portal only in the zones where it is actually required;
DNS in the VPN zone only when the firewall acts as the resolver;
appropriate VPN portal authentication methods;
appropriate SSL VPN authentication methods;
MFA for the portal and tunnel.

When an authentication method contains multiple servers, SFOS forwards requests in the displayed order; each method can contain up to 20 servers. Check this order deliberately when identical usernames or fallback behavior are involved.

Normal firewall rules do not control these local services. Restrict source networks, individual IP addresses, or countries with Local Service ACL Exception Rules. The complete security workflow is documented under Device Access and Local Service ACL.

The firewall’s web proxy is a special case: HTTP and HTTPS requests passing through it are treated as internal for local services. Users with proxy access can therefore reach the VPN Portal even when it isn’t enabled for their source zone. Test this reachability separately when using the proxy instead of relying only on the Device Access zone matrix.

Third-party Threat Feeds can also block system-directed access to VPN services. They provide an additional way to block known unwanted sources; Threat Feeds on Sophos Firewall explains their configuration and limitations.

VPN portal authentication methods control sign-in to the portal and profile download, while SSL VPN authentication methods control the tunnel sign-in itself. WebAdmin is a separate administration interface and does not need to be exposed to the WAN zone for SSL VPN.

SSO by SFOS version: On SFOS 22, configure Microsoft Entra ID with Server type: Microsoft Entra ID SSO. On SFOS 23, open Authentication > Servers > Add, select Server type: OpenID Connect, then IdP vendor: Microsoft Entra ID or IdP vendor: Google Workspace. App, server, Redirect URI and group setup is covered in Microsoft Entra ID SSO for Sophos Connect and Google Workspace OIDC on Sophos Firewall, respectively. These version branches do not establish a build’s GA availability.

Before downloading the profile, select the same configured IdP server under Authentication > Services for VPN portal authentication methods and SSL VPN authentication methods, and click Apply for each service; on SFOS 22, this is the same Entra server. Compare the complete Redirect URI at the selected provider, including FQDN, port and path, and check the required login endpoints. Successful SSO replaces neither group membership nor Policy members or tightly scoped firewall rules. Before switching, retain service assignments, server order and working profiles. After SSO changes, download and import the current configuration again, then use a regular pilot user to test the portal, tunnel, IdP MFA, DNS, permitted destinations and blocked destinations. On failure, restore the recorded service assignments, order and corresponding profiles, and repeat the same tests; do not remove the previous access method before acceptance succeeds.

For SFOS-native OTP, select the target users or groups under Authentication > Multi-factor authentication and enable both VPN portal and SSL VPN remote access under Require MFA for. With Generate OTP token with next sign-in, the user must first scan the QR code in the VPN Portal before the tunnel test can begin.

The VPN Portal does not support RADIUS authentication with challenge-based MFA. Sophos Connect also does not support an OTP challenge; it sends the password and OTP together. Call and Push methods are supported. Test the selected method with a regular pilot user. See MFA for Sophos Firewall for the fundamentals.

Distribute and update the client profile

If profile-relevant global values such as the protocol, port, interface, server certificate, or Override hostname change, download the current .ovpn from the VPN Portal again, distribute it securely, and reimport it into the client for manual deployments. Update policy is not the first step here and is not a substitute for manual reimport. Its documented use applies to a connection provisioned through .pro: after changing the SSL VPN port or protocol, run Update policy for that connection; this provisioning path retrieves other configuration changes automatically. Changes to settings such as the port, gateway, server certificate, or protocol may require signing in again. A Sophos Connect software update does not replace an outdated profile. Securely retain the known working profile and its associated global firewall values for rollback; before broad distribution, use a regular pilot user to check the new import for gateway/port, authentication/MFA, routes, DNS, and access to allowed and blocked destinations. If acceptance checks fail, restore the corresponding old values and the known working profile, and repeat the same checks.

After changing Override hostname or the port, verify in the client that the newly imported profile actually uses the new gateway name and port.

After changes to Policy members, Permitted network resources, or the IP address of an FQDN destination, a disconnect and reconnect is normally sufficient. Permitted networks aren’t stored statically in the .ovpn; SFOS adds the user’s resources when the tunnel is established. These changes therefore don’t require a new .ovpn download.

.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.

If the provisioning gateway or vpn_portal_port changes, update and redistribute the .pro file. The older user_portal_port field is accepted only for compatibility. During initial provisioning with OTP or another MFA method, the sign-in prompt can appear twice: first for the profile download and then for establishing the tunnel.

If .pro provides only an IPsec connection or no SSL VPN configuration, check policy members, group membership, VPN Portal reachability, and authentication first.

For SSO provisioning with .pro on Windows with Sophos Connect 2.4 or later, SFOS 22 describes Entra ID; SFOS 23 supports the OIDC identity providers supported for this workflow, not arbitrary identity providers. Under Authentication > Services, the VPN Portal, IPsec VPN and SSL VPN must use the same configured IdP server. gateway contains only the firewall FQDN or IP address from that server’s Redirect URI section, not the complete callback URI; set the portal port separately in vpn_portal_port. For SSO here, macOS with Sophos Connect 2.1 or later remains limited to Entra ID, not general OIDC; the support clarification required before rollout below still applies. The following provisioning article explains the provider- and version-specific prerequisites.

See Sophos Connect provisioning with .pro and GPO for the complete JSON structure, MFA fields, gateway selection, and GPO deployment.

For Google Workspace SSO, this guidance is limited to Windows with Sophos Connect 2.4 or later; Entra guidance for macOS cannot be applied to Google. For Entra, the overview pages list macOS from 2.1, not 2.0, while the requirements pages list only Windows from 2.4. This contradiction remains unresolved in the linked detail article too: stop before a macOS rollout until support for the target build, client platform/version and required VPN type has been separately confirmed and tested. For every approved path, check compatible SFOS settings, current client configuration, authentication methods and the Redirect URI; test MFA at the IdP. Neither an identical browser flow nor applicability of Windows GPO deployment to macOS is promised.

Use unique profile names, remove old connection entries after a gateway or user change, and test distribution with a regular target user. See Update Sophos Connect safely for client version guidance.

SSL VPN with Sophos Connect: Windows 10/11; macOS client 2.0 on macOS 13+, and client 2.1 onward on macOS 14+. Linux, iOS and Android use a compatible OpenVPN client.

Under Current activities > Remote users, you can filter signed-in remote users by Connection date, Username, Source IP address, and Leased IP address. The Mode column distinguishes three states:

SSL VPN (remote access): established Remote Access tunnel
User portal (clientless access): portal sign-in by a member of a clientless SSL VPN policy
User portal: portal sign-in without such membership

A portal entry therefore doesn’t prove that an SSL VPN tunnel exists. Disconnect actively terminates the selected session. Document the user, addresses, mode, and time before a support or acceptance test.

Test the configuration and narrow down errors

Acceptance test

Use a regular pilot user and a specific internal destination for a complete test:

Verify that the user sees exactly the expected SSL VPN configuration in the VPN Portal.
Test MFA with both a correct and an incorrect factor.
Import .ovpn or .pro and verify the assigned lease address.
With Split Tunnel, check the routes to LAN_Server and DNS_Internal.
Test the internal destination by IP address first and then by hostname.
Access an allowed service and verify the firewall Rule ID in the Log Viewer.
Attempt access that should be blocked and confirm the drop.
With Full Tunnel, also test public internet access, DNS, Web Policy, and IPv4 SNAT.
After a policy or FQDN change, disconnect, reconnect, and repeat the same test.

Record the time, user and group, client platform and version, source network, destination, and service for every test. Testing only with an administrator can easily hide group, MFA, and policy errors.

Logs by failure stage

First identify whether the error occurs during portal access, authentication, tunnel establishment, or access to the destination:

VPN Portal: vpnportal.log
Normal authentication: access_server.log
Microsoft Entra SSO on SFOS 22: oauth_sso_vpn.log; for SFOS 23, use the versioned log guidance in the relevant Entra or Google detail article.
User-specific SSL VPN certificates: peruser_cert_sslvpn.log
SSL VPN service: sslvpn.log
Active connections: openvpn-status*.log
Destination traffic: firewall log, Rule ID, and, if needed, Packet Capture

In Packet Capture, Incoming only proves that the firewall received the packet. If the status is Forwarded but no response returns, check the return route, NAT, destination system, and its local firewall.

For TUN traffic, SFOS logs sometimes list the TUN interface address as the source and the leased client address as the destination. This does not mean the addresses have been reversed. Interpret the entry using the user, lease, traffic direction, Rule ID, and test time together.

Sophos Firewall services and logs maps additional processes and log files.

No user can establish a tunnel: service and flood limits

When every user is affected, perform read-only checks before changing policies, flood limits, or services. Record the test time, configured SSL VPN protocol and port, current DoS settings, and whether at least one SSL VPN policy exists.

Sign in to the CLI, select 5. Device management, then 3. Advanced shell, and check the service state with the command documented by Sophos:
```
service -S | grep sslvpn
```
The service must show Running. UNREGISTERED means that no SSL VPN policy is registered; verify that at least one SSL VPN policy exists. If a policy exists but the service still doesn’t show Running, correlate sslvpn.log with the test time and investigate that discrepancy instead of restarting services without a documented procedure.
Under Intrusion prevention > DoS & spoof protection > DoS settings, inspect the enabled UDP, TCP, and ICMP/ICMPv6 flood flags and their limits. Use the SSL VPN’s configured protocol when checking tunnel traffic. SFOS drops SSL VPN traffic and ping requests when the corresponding flood limit is crossed; a failed ping alone doesn’t prove that a limit was crossed. Correlate the attempted connection and drop evidence before making an exception.
Only for a confirmed flood-limit match, record the existing configuration and create the narrowest temporary inbound rule under DoS bypass rules. Sophos’s example uses the relevant source IP/netmask (or * only when unavoidable), the permitted network resource address as destination, the actual TCP or UDP protocol, source port Any, and the configured SSL VPN destination port (8443 by default). Restrict the source and destination further whenever the test permits; don’t disable flood protection globally.
Repeat the same timed connection and permitted-resource tests. If the bypass doesn’t account for the drop, remove it immediately. After diagnosis, remove the temporary rule or formally approve and document the narrow exception. Restore any separately changed flood limits to the recorded values, then repeat the positive and blocked-access tests.

The request reaches the server, but the reply is missing

If the SSL VPN client’s request demonstrably reaches the permitted internal resource but the reply does not reach the client, inspect the return path in two stages: first from the resource to the firewall and then from the firewall to the leased SSL VPN address. A green tunnel status does not isolate this error.

On the internal resource or its router, verify that the return path to the SSL VPN lease range points through Sophos Firewall. A specific return route is more transparent than SNAT. Use SNAT only with a narrow scope when the return path cannot be routed and the resulting source-address change is acceptable.
Use Packet Capture to confirm that the reply reaches the firewall. The source address, leased destination address, service, and test time must match the original access attempt.
Under Routing > SD-WAN routes, inspect the current Route Precedence and broad SD-WAN routes. SSL VPN belongs to the static category. If sdwan_policyroute comes first, a route with the internal resource or Any as its source and Any as its destination and service can divert the reply away from the tunnel.
Preferably narrow the affected SD-WAN route so that the SSL VPN lease range no longer matches as a destination. Sophos alternatively identifies a service exception for the SSL VPN port and protocol; this option must fit the actual rule and traffic design.
Change the global Route Precedence only after assessing the impact. It affects more than this connection. Prepare the original order, management access, and rollback as described in Route Precedence on Sophos Firewall.
Repeat the access attempt and use the capture to verify the reply entering from the resource and being forwarded to the leased address. Then reconnect and test again with the same application.

⚠️ A broad Any rule, a blanket SNAT rule, or a global Route Precedence change can move the visible problem and disrupt other VPN, WAN, or management paths. Stop if the return path to the firewall or the SD-WAN route that actually matches has not been proven.

Home and internal destination networks overlap

If the external client uses 192.168.1.0/24, for example, and the permitted internal resource is also in 192.168.1.0/24, the operating system usually treats the destination as local. The packet never reaches the SSL VPN tunnel. The clean permanent solution is to renumber one of the two networks.

If that cannot be done immediately, Sophos documents a narrowly scoped DNAT workaround. Choose an unused virtual destination address that does not overlap any local, internal, VPN, static, or SD-WAN network. For Split Tunnel, this address must reach the client as a Permitted network resource, followed by a reconnect. The DNAT rule uses the SSL VPN lease range as the Original source, Original as the Translated source, the virtual address as the Original destination, and the real internal host as the Translated destination. Restrict the services and the associated firewall rule from VPN to the destination zone to the access that is actually required.

The user then accesses the virtual address or a dedicated DNS name that resolves to it. Log Viewer must show the expected Firewall Rule ID and NAT Rule ID; a Packet Capture confirms the translation and return path. Do not create an entire replacement range when only one host is required. Stop if the virtual address is not unambiguously unused or a broad NAT rule would be necessary.

Common error patterns

No or empty .ovpn in the VPN Portal: Fix a missing or empty OVPN download helps distinguish policy, User-ID, certificate, storage, firmware, and HA errors. Guest accounts are not supported. Sophos Connect supports ASCII usernames only; the username and domain combined must not exceed 51 characters.
Sign-in fails: Correlate access_server.log and vpnportal.log with the test time; for Entra on SFOS 22, also use oauth_sso_vpn.log, and on SFOS 23 use the versioned OIDC log guidance in the relevant detail article. Check the same IdP server for the portal and SSL VPN, Redirect URIs and the complete certificate chain.
Tunnel is established, but internal destinations are unavailable: Check the route on the endpoint, Permitted Resources for Split Tunnel, the firewall rule, return route, destination firewall, and overlap with the local home network.
The IP address works, but the hostname does not: Check the DNS server, search domain, Split Tunnel route, DNS firewall rule, local DoH or endpoint DNS, and, if applicable, Device Access for DNS.
Only individual users are affected: Compare group membership, policy assignment, MFA, static IP, Simultaneous logins, and the loaded profile.
Only older clients are affected: Import a current .ovpn after global changes. For policy-only or FQDN changes, reconnect first and check the loaded routes.
Full Tunnel has no internet access: Check the rule from VPN to WAN, IPv4 SNAT, DNS, and the applied web and security policies.
Large transfers stall: If small requests work, check MTU and MSS along the actual path. Follow the process under MTU and MSS for VPN issues.
The connection ends after an extended period: Compare the start and disconnect times with the Idle Timeout, Disconnect idle clients, and Key lifetime. Check the static IP and Simultaneous logins, use dynamic addressing for a pilot user if necessary, and review sslvpn.log and openvpn-status*.log at the test time.
No user can establish a tunnel: In addition to Device Access and verifying that the SSL VPN port is reachable, look for a broad DNAT rule with Original destination: Any and Services: Any or the SSL VPN port that intercepts the connection first.
WAF, portal, or SSL VPN conflicts: Compare the WAN IP, port, and protocol for all local services and WAF rules. Shared combinations can expose the portal more broadly or disable login security.

During ongoing operations, regularly review groups, MFA, static IP assignments, certificate expiry, the lease range, Device Access, firewall rules, profile distribution, and logs. Test new SFOS and Sophos Connect versions first with a pilot user and both a permitted and a blocked destination.