Set Up Sophos Firewall SSL VPN Remote Access

SSL VPN remains an important remote access method on Sophos Firewall, especially when users work from hotels, guest Wi-Fi, mobile networks, or restrictive foreign networks. However, it’s not just about whether the tunnel is established. It’s crucial whether the firewall properly restricts access, whether DNS works, whether MFA is effective, and whether the firewall rules allow traffic from the VPN zone in a controlled manner.

This article describes the firewall-side configuration of SSL VPN Remote Access on Sophos Firewall. For client installation, see Set Up Sophos SSL VPN with Sophos Connect on Windows, Set Up Sophos SSL VPN with Sophos Connect on macOS, Set Up Sophos SSL VPN on iPhone and iPad, and Set Up Sophos SSL VPN on Android.

For the fundamental decision between IPsec, SSL VPN, mobile clients, and ZTNA, first see Sophos Connect or SSL VPN: Which Remote Access Solution Fits?.

Which SSL VPN Article Fits?

SSL VPN consists of firewall configuration, portal, client, authentication, and later troubleshooting. Depending on the task, a different starting point is appropriate:

This separation is important: A user problem in the VPN Portal, an outdated .ovpn profile, a missing firewall rule, and a DNS problem often look the same to the user. For analysis, these layers must be separated.

Target Image

A clean SSL VPN setup consists of several components:

1. Users or groups are authorized in the correct SSL VPN policy.
2. The global SSL VPN settings define gateway, port, certificate, lease range, DNS, and cryptography.
3. The VPN Portal is only as broadly accessible as necessary and protected with MFA.
4. Firewall rules allow traffic from the VPN zone only to the necessary destinations.
5. Split Tunnel or Full Tunnel is consciously decided.
6. Clients import a current .ovpn profile.
7. Logs, Packet Capture, and support data can be evaluated in case of errors.

Many SSL VPN problems arise because only the client download is documented. In practice, portal, authentication, SSL VPN policy, firewall rule, DNS, and NAT must be considered together.

⚠️ SSL VPN is a publicly accessible entry point. MFA and strong passwords are important but do not replace restriction via Device access, tight user groups, current profiles, logging, and regular reviews.

Prerequisites

Before configuration, these points should be clarified:

• Sophos Firewall with the current SFOS version.
• Public accessibility of the firewall or a pre-configured port forwarding.
• FQDN or public IP address for VPN access.
• Certificate for VPN Portal and SSL VPN, ideally matching the FQDN.
• Users or groups for Remote Access.
• Authentication server: local, Active Directory, RADIUS, or Microsoft Entra ID.
• MFA/OTP concept for VPN Portal and Remote Access.
• Internal target networks, DNS servers, and search domain.
• Decision for Split Tunnel or Full Tunnel.
• Firewall rules for traffic from the VPN zone.
• Process for client update and redistribution of the .ovpn file.

If Microsoft Entra ID SSO is to be used, authentication must be correctly prepared before downloading the VPN configuration. The procedure is described in Set Up Microsoft Entra ID SSO for Sophos Connect and VPN Portal.

1. Prepare Local Objects

First, the target networks should exist as hosts or network objects:

Hosts and services > IP host

Typical objects:

You should not simply allow complete internal network areas if only individual servers or subnets are needed. The more narrowly the objects are defined, the easier the firewall rule will be later.

2. Check Global SSL VPN Settings

The global settings apply to all Remote Access SSL VPN policies:

Remote access VPN > SSL VPN > SSL VPN global settings

Protocol and Port

SSL VPN can use TCP or UDP depending on the configuration. UDP is often more efficient, while TCP can work better in restrictive networks. The decision should be tested with the networks from which users actually work.

When it comes to the port, overlaps must be avoided:

• The standard SSL VPN port is often 8443.
• The VPN Portal uses 443 by default in current SFOS versions.
• WAF rules and SSL VPN must not overlap on the same WAN IP with the same port and protocol.
• If SSL VPN and VPN Portal use the same port, login security functions may not work as expected.

If WAF, VPN Portal, User Portal, and SSL VPN are operated on the same WAN IP, port, protocol, and certificate should be consciously documented. For WAF basics, see Set Up Sophos Firewall WAF and Avoid Common Mistakes.

Certificate and Override Hostname

Under SSL server certificate, a certificate that matches the public FQDN should be used. A certificate error in the VPN Portal or SSL VPN profile will later lead to unnecessary support cases.

Under Override hostname, you specify which hostname or IP address clients use in the .ovpn profile. This is especially important for:

• multiple WAN IP addresses,
• a pre-configured router,
• NAT or port forwarding before the firewall,
• dynamic WAN IP with DDNS,
• separate FQDNs for WebAdmin, VPN Portal, and SSL VPN.

If the field remains empty, multiple interface addresses can end up in the profile. This can work, but in productive environments, it is often less clear than a clean FQDN.

Lease Range

Sophos Firewall assigns SSL VPN clients addresses from the configured lease range. This range must not collide with internal networks, static routes, site-to-site VPNs, or typical home network ranges.

Particularly common subnets to avoid are:

• 192.168.0.0/24
• 192.168.1.0/24
• 192.168.2.0/24
• 10.0.0.0/24
• 10.0.1.0/24

If the lease range collides with a user’s home network, the tunnel sometimes connects successfully, but internal targets remain unreachable. This then appears as a firewall rule problem but is a routing problem at the endpoint.

For firewall rules, you should use the system hosts ##ALL_SSLVPN_RW and for IPv6 ##ALL_SSLVPN_RW6, not manually recreated hosts with old lease ranges.

Static SSL VPN IP Addresses and Key Lifetime

Static SSL VPN IP addresses can be useful in individual cases, for example, for admin access, strictly logged special access, or legacy applications with IP-based access. However, they are not suitable as a standard for all users. The more static assignments exist, the more difficult operation, troubleshooting, and later migrations become.

A specific special case is documented in the Known Issues list: With SSL VPN using local authentication and statically assigned SSL VPN IP, re-authentication after the key lifetime expires can fail. The firewall may treat the already assigned lease address as a conflict. Users then have to reconnect manually, even though the tunnel previously worked. A typical key lifetime value is 18000 seconds.

If a user has to repeatedly log in after several hours, you should not only check MFA, client version, and firewall rule. Additionally, these points should be included in the analysis:

• Is local authentication used for SSL VPN?
• Does the user have a static SSL VPN IP address?
• Does the problem occur approximately after the key lifetime expires?
• Does the same user work more stably with dynamic IP assignment?
• Is a static IP really necessary, or is a rule over user group, SSL VPN system host, and logging sufficient?

As pragmatic countermeasures, Sophos suggests two directions: Plan the key lifetime to cover the normal workday or use dynamic IP assignment. In many environments, dynamic assignment is cleaner because firewall rules should be controlled over the VPN zone, user group, target objects, and the SSL VPN system hosts anyway.

DNS and Domain Name

For internal name resolution, DNS servers and optionally a domain name are set in the global SSL VPN settings. In Active Directory environments, this is usually an internal DNS server or Domain Controller.

Additionally, under Administration > Device access, DNS from the VPN zone must be allowed if the firewall itself is used as a DNS resolver in the VPN design.

If DNS does not work in the tunnel, you should test separately:

• Is the target reachable by IP address?
• Is the internal DNS server allowed by the firewall rule?
• Does the client receive the correct search domain?
• Is the client really using the current .ovpn profile?
• Does local DNS or DoH configuration of the endpoint interfere?

3. Create SSL VPN Policy

The policy is created under:

Remote access VPN > SSL VPN

Procedure:

1. Select Add.
2. Use Configure manually.
3. Assign a name, for example, SSLVPN-Remote-Users.
4. Under Policy members, select the authorized users or groups.
5. Decide on Split Tunnel or Full Tunnel.
6. For Split Tunnel, select the Permitted network resources.
7. Optionally configure Disconnect idle clients.
8. Save and then test with a test user.

Important: If users or groups are entered in a newer SSL VPN policy that are already included in an older SSL VPN policy, Sophos Firewall removes this assignment from the earlier policy. Therefore, policy overlaps should be avoided, and it should be clearly defined which policy applies per user group.

4. Decide on Split Tunnel or Full Tunnel

Split Tunnel

With Split Tunnel, only traffic to the allowed internal resources runs through the VPN tunnel. The user’s internet traffic continues directly over the user’s local network.

Split Tunnel is often suitable for:

• Access to a few internal applications,
• Lower firewall load,
• Better user performance,
• Smaller remote sites and mobile users.

Security then depends more on the endpoint, the local network environment, and the shared internal resources.

Full Tunnel

With Full Tunnel, all traffic from the remote user is routed through the firewall. In Sophos Firewall, this corresponds to the option Use as default gateway.

Full Tunnel is more suitable when:

• Internet traffic should be centrally controlled,
• Web Protection, DNS Protection, or logging for VPN users should apply,
• Users work from insecure networks,
• Compliance requires central evaluation.

With Full Tunnel, the SSL VPN policy alone is not enough. Additional firewall rules and NAT/SNAT for internet traffic from the VPN zone are needed. Performance, bandwidth, web filtering, and logging should also be tested beforehand.

5. Create Firewall Rules for VPN Zone

The tunnel setup does not mean that traffic is allowed. For access to internal resources, a suitable firewall rule is needed:

Rules and policies > Firewall rules

Recommended rule for Split Tunnel:

For Full Tunnel, an additional rule from VPN to WAN or Any, depending on the design, is needed. The source networks should still be the SSL VPN system hosts. Then it must be checked whether a suitable SNAT rule exists.

If a connection is established but no access works, the Log Viewer should be checked first. For the methodology, see Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture.

6. Secure VPN Portal and Device Access

Users typically download Sophos Connect and the .ovpn file via the VPN Portal:

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

At least check:

• VPN Portal port and certificate.
• VPN Portal Authentication Methods.
• MFA for VPN Portal and Remote Access.
• Device Access for VPN Portal only in required zones.
• Device Access for SSL VPN on the WAN zone only if externally necessary.
• No permanently open User Portal on WAN if not needed.

For hardening local firewall services, see Device Access and Local Service ACL on Sophos Firewall. For MFA basics, see Enable MFA for Sophos Firewall WebAdmin, VPN Portal, and Remote Access.

The VPN Portal only makes sense to users if they or their groups are included in a suitable Remote Access policy. If the policy assignment is missing, the user does not see the necessary configuration downloads.

If VPN Portal or SSL VPN must be allowed on the WAN zone, it should be consciously documented. In many environments, it is not enough to open the service worldwide and rely on MFA. Where possible, fixed source networks, country restrictions, threat feeds, log review, or a pre-configured remote access design should be checked.

7. Distribute Client Profile

After configuring the policy and portal, the .ovpn file is distributed. This can be done via the VPN Portal or controlled by the admin process.

Important:

• After changes to gateway, port, certificate, DNS, lease range, policy, or authentication, the profile must be reloaded.
• A Sophos Connect update does not replace an old .ovpn profile.
• Profile names should be clear.
• Old profiles should be removed when changing location, gateway, or user.
• Windows, macOS, iOS, Android, and Linux sometimes use different client paths.

For client updates and version maintenance, see Check and Securely Update Sophos Connect Client Version.

Test After Configuration

With a test user, you should not only check if Sophos Connect shows Connected.

Test list:

• User sees the Sophos Connect download and SSL VPN configuration in the VPN Portal.
• .ovpn file can be imported.
• MFA is queried as expected.
• Client receives an address from the SSL VPN lease range.
• Route to the allowed internal networks appears on the endpoint.
• Internal DNS names are resolved.
• Access to allowed servers works.
• Unallowed networks remain blocked.
• Log Viewer shows the correct firewall rule.
• Packet Capture shows traffic over a tun interface, if necessary.
• With Full Tunnel, internet access and SNAT also work.

If the test is only done with an admin user, group and policy errors are easily overlooked. A normal pilot user from the target group is better.

Acceptance Test by Scenario

Before a broad rollout, at least these test cases should be clearly documented:

For productive environments, each test should include a time, a user, a client platform, and a specific target. Statements like “VPN works” or “VPN doesn’t work” are too vague for later support cases.

Collect Logs and Evidence

For SSL VPN problems, you should first clarify whether the error lies in login, tunnel setup, or access to internal targets. This separation saves time because otherwise authentication, client profile, routing, and firewall rules are checked in confusion.

For a reproducible test case, these details should be noted:

Then the check should be conducted in this order:

1. Check authentication: In the Log Viewer and, if necessary, in the authentication logs, check whether user, MFA, group, and authentication server are successful. For Microsoft Entra ID SSO, oauth_sso_vpn.log is also relevant.
2. Check tunnel status: Check SSL VPN connection, lease address, and OpenVPN status. On the firewall side, sslvpn.log and openvpn-status*.log help.
3. Check firewall rule: In the Log Viewer, search for traffic from the VPN zone and check which rule really matches. The rule should have Log firewall traffic active.
4. Check packet flow: If the Log Viewer is not enough, filter by source, target, and service with Packet Capture. It is important whether packets are only Incoming or also Forwarded.
5. Check target side: If traffic leaves the firewall but no response comes back, return route, server firewall, local host firewall, or a network conflict are more likely than the SSL VPN policy.

For the assignment of the most important log files, see Sophos Firewall Troubleshooting: Services and Logs. For rule analysis with Log Viewer, Policy Test, and Packet Capture, see Test Firewall Rule with Log Viewer, Policy Test, and Packet Capture.

Troubleshooting

User Does Not See SSL VPN Configuration in VPN Portal

Usually, the policy assignment is missing. Check whether the user or their group is included in the SSL VPN policy under Policy members. Additionally, authentication, MFA, and VPN portal accessibility should be checked.

If login and policy assignment seem correct, but the download of the .ovpn file is still missing or fails, the Sophos Firewall User-ID Limit should also be checked. This is particularly relevant if multiple users use the portal, but only individual downloads unexpectedly fail.

Tunnel Connects, but Internal Systems Are Not Reachable

First, check if a route to the internal target network exists on the endpoint. Then search for traffic from the VPN zone in the Log Viewer. If no traffic is visible, the client does not reach the firewall as expected, or the profile is outdated.

If traffic is visible but the wrong rule applies, the rule order or the service/target definition must be corrected. If no response comes back at all, routing, target firewall, local server firewall, or a network conflict are likely.

DNS Does Not Work

Check if access by IP address works. If so, the error is likely with DNS. Then check DNS server in the global SSL VPN settings, domain name, Device Access for DNS from the VPN zone, and endpoint DNS behavior.

Access Only Works for Some Users

Then group membership, policy assignment, static SSL VPN IP addresses, MFA status, or outdated profiles are more likely than a global firewall error. Duplicate policy assignments should also be checked.

User Must Reconnect After Several Hours

If SSL VPN initially works but requires re-login or manual reconnection after several hours, you should first check time patterns, authentication, and lease model. This is particularly relevant with local authentication with statically assigned SSL VPN IP.

Practical procedure:

1. Note the time of connection establishment and disconnection.
2. Compare the time with the configured key lifetime.
3. Check if the user has a static SSL VPN IP address.
4. Test dynamic IP assignment for a pilot user, if operationally possible.
5. Search in sslvpn.log, openvpn-status*.log, and Log Viewer for authentication, lease address, and re-login.
6. If a longer key lifetime is chosen, document the change and do not understand it as a replacement for MFA or clean session control.

If static IPs are only used to make firewall rules look simpler, the design should be revised. Usually, groups, clearly named target objects, tight services, and logging are a better foundation than individual user IP addresses.

Full Tunnel Has No Internet Access

With Use as default gateway, a firewall rule for traffic from the VPN zone towards the internet and a suitable SNAT rule are needed. Additionally, web, DNS, and security policies must be planned so that they do not unexpectedly block VPN users.

Connection Stands, but Large Transfers Hang

If login, DNS, and small accesses work, but RDP, file transfers, web applications, or large downloads hang, MTU and MSS should be checked. The error pattern often fits fragmentation, PPPoE, tunneled connections, or an asymmetric path, not just SSL VPN itself.

For systematic analysis, see Check Sophos Firewall MTU and MSS for VPN Issues.

WAF or Portal Collides with SSL VPN

If WAF, VPN Portal, User Portal, and SSL VPN run on the same WAN IP, port and protocol must be cleanly separated. Particularly critical are shared combinations of WAN IP, port, and TCP. For unclear drops, check Log Viewer and Packet Capture.

Profile Is Outdated After Change

After changes to SSL VPN policy, gateway, DNS, certificate, port, or authentication, the .ovpn file should be re-downloaded and imported. Many apparent client problems are outdated profiles.

Operational Checklist

Before Productive Rollout

• FQDN and certificate for VPN Portal and SSL VPN checked.
• SSL VPN lease range does not collide with internal or typical home networks.
• SSL VPN policy contains the correct users or groups.
• Split Tunnel or Full Tunnel is consciously decided.
• Permitted network resources are narrowly defined for Split Tunnel.
• DNS server and domain name are correctly set.
• Firewall rule from VPN to internal targets exists and logs.
• For Full Tunnel, internet rule and SNAT exist.
• Device Access for SSL VPN and VPN Portal is consciously set.
• MFA is tested for Remote Access.
• Test user can download, import the profile, and reach internal targets.

For Ongoing Operation

• Enforce MFA for VPN Portal and Remote Access.
• Regularly check VPN groups.
• Keep firewall rules for VPN tight and log.
• Check lease range before network changes.
• Use static SSL VPN IP addresses only selectively and check regularly.
• Document DNS and search domain.
• Renew portal and SSL VPN certificates before expiration.
• Track Sophos Connect versions.
• Plan profile redistribution after changes.
• Evaluate logs long-term via Syslog or Sophos Central if traceability is important.

For log files and services, see Sophos Firewall Troubleshooting: Services and Logs.

Regularly Check Special Cases

• Static SSL VPN IP addresses are justified and documented.
• Key lifetime fits the operational model and has been tested with reconnect.
• Old .ovpn profile is redistributed after changes.
• VPN Portal, User Portal, WAF, and SSL VPN do not collide on the same WAN IP with port and protocol.
• Users with special rights or admin access are separately checked.

FAQ