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.

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:

SSL server certificate in the global SSL VPN settings authenticates the tunnel 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.

For IPv4, SFOS allows a maximum pool size of /24 here; smaller ranges such as /25 cannot be selected. Access is restricted through the policy and firewall rules, not through an artificially small pool. 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, allow DNS for the VPN zone under Administration > Device access instead. 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.

Create the SSL VPN policy

Create the policy manually or with the wizard:

Remote access VPN > SSL VPN

The wizard displays the global settings for review but cannot change them. It creates the policy, configures the selected authentication and Device Access settings for the VPN Portal and SSL VPN, and creates the firewall rule. In existing environments, Configure manually is usually 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.
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.

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.

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.

For Microsoft Entra ID, select the same Entra server for the VPN Portal and SSL VPN. The complete setup is documented under Microsoft Entra ID SSO for Sophos Connect.

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

For a manually imported .ovpn file, profile-relevant changes to the global settings must be downloaded and imported again. These include the protocol, port, interface, server certificate, and other values from the global SSL VPN configuration. A Sophos Connect update does not replace an outdated profile.

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. These changes do not require a new .ovpn download.

A .pro provisioning file is supported only on Windows 10 and 11. It downloads the IPsec and SSL VPN configurations available to the user and automatically retrieves later changes. If the provisioning gateway or VPN Portal port changes, update and redistribute the .pro file. During initial provisioning, 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.

After enabling or changing Microsoft Entra ID SSO, the client must use a current configuration. Entra SSO in Sophos Connect is supported on Windows with client version 2.4 or later.

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.

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: oauth_sso_vpn.log
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.

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

Common error patterns

No or empty .ovpn in the VPN Portal: Troubleshoot a missing or empty OVPN download separates 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, vpnportal.log, or oauth_sso_vpn.log with the test time. For Entra, check that the same server is configured for the portal and SSL VPN and that the certificate chain is complete.
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.