Set up Sophos Firewall SSL VPN Remote Access

SSL VPN remains an important remote access path, especially when users work from hotels, guest WLANs, cellular networks or restrictive third-party networks. But it’s not just whether the tunnel is built that’s important. What is crucial is whether the firewall limits access properly, whether DNS works, whether MFA works and whether the firewall rules allow traffic from the VPN zone in a controlled manner.

The article describes the firewall-side configuration of SSL VPN Remote Access on Sophos Firewall. For the client installation, 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 basic decision between IPsec, SSL VPN, mobile clients and ZTNA, Sophos Connect or SSL VPN: Which remote access solution is suitable? is the first choice.

Which SSL-VPN article fits?

SSL VPN consists of firewall configuration, portal, client, authentication and later error analysis. Depending on the task, a different approach is appropriate:

• Set up SSL VPN on the firewall: This article.
• Basically compare Sophos Connect or SSL VPN: Sophos Connect or SSL VPN: Which remote access solution is right?.
• Maintain Sophos Connect client versions and profiles: Check Sophos Connect Client version and update safely.
• Set up SSL-VPN client on Windows: Set up Sophos SSL VPN with Sophos Connect on Windows.
• Set up SSL VPN on macOS, iOS or Android: macOS, iPhone/iPad or Android.
• Use Microsoft Entra ID SSO or Entra-MFA: Set up Microsoft Entra ID SSO for Sophos Connect and VPN Portal.
• VPN is connected but traffic is not working: Test firewall rule with Log Viewer, Policy Test and Packet Capture.
• Large transfers hang or individual applications do not load: Check MTU and MSS for VPN problems on Sophos Firewall.

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 levels must be separated.

Target state

A clean SSL-VPN structure consists of several building blocks:

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

Many SSL VPN problems arise because only the client download is documented. In practice, however, 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 limits through Device access, narrow user groups, current profiles, logging and regular reviews.

⚠️ Changes to gateway, port, certificate, DNS, lease range or policy do not automatically end up in already imported client profiles. After relevant changes, the .ovpn file must be downloaded again, distributed and replaced on the clients.

Requirements

Before configuration, these points should be clarified:

• Sophos Firewall with current SFOS version.
• Public accessibility of the firewall or upstream 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 for VPN Portal and SSL VPN: 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.
• Opt for Split Tunnel or Full Tunnel.
• Firewall rules for traffic from the VPN zone.
• Process for client update and redistribution of .ovpn file.

If Microsoft Entra ID SSO is to be used, authentication must be prepared correctly before downloading the VPN configuration. The process is in Setting 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:

• LAN_Server: 10.10.10.0/24, internal servers.
• LAN_Client: 10.10.20.0/24, client network if required.
• DNS_Internal: 10.10.10.10, internal DNS or domain controller.
• SSLVPN_Users: user group, policy members.

You shouldn’t simply release entire internal network areas if only individual servers or subnets are necessary. The more tightly the objects are defined, the simpler 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, TCP can work better in restrictive networks. The decision should be tested on the networks from which users actually work.

When it comes to ports, you have to avoid overlaps:

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

If WAF, VPN Portal, User Portal and SSL VPN are operated on the same WAN IP, you should consciously document the port, protocol and certificate. For WAF basics Sophos Firewall Set up WAF and avoid typical mistakes is suitable.

Certificate and override hostname

A certificate that matches the public FQDN should be used under SSL server certificate. A certificate error in the VPN Portal or SSL VPN profile will lead to unnecessary support cases later. Under Override hostname you specify which host name or IP address clients use in the .ovpn profile. This is particularly important for:

• multiple WAN IP addresses,
• upstream router,
• NAT or port forwarding in front of the firewall,
• dynamic WAN-IP with DDNS,
• separate FQDNs for WebAdmin, VPN Portal and SSL VPN.

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

After changing the override hostname, you have to download a new profile and check whether the client really has the new FQDN or the new public IP address. Otherwise you might end up testing the old connection even though the firewall configuration is already correct.

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.

You should avoid particularly common subnets such as:

• 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

When the lease range collides with a user’s home network, the tunnel sometimes connects successfully, but internal destinations remain inaccessible. This then looks like a firewall rule problem, but is a routing problem at the endpoint.

For firewall rules, 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 approval. However, they are not suitable as a standard for all users. The more static assignments there are, the more difficult operation, error analysis and subsequent migrations become.

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

If a user has to log in repeatedly after several hours, you should not only check MFA, client version and firewall rule. Additionally, these points belong 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 has expired?
• Does the same user work more stable with dynamic IP assignment?
• Is a static IP really necessary or is a rule about user group, SSL-VPN system host and logging sufficient?

Sophos cites two pragmatic countermeasures: plan key lifetime so that it covers the normal working day, or use dynamic IP allocation. In many environments, dynamic allocation is cleaner because firewall rules should already be controlled across VPN zone, user group, target objects, and the SSL VPN system hosts.

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, DNS from the VPN zone must be allowed under Administration > Device access if the firewall itself is used as a DNS resolver in the VPN design.

If DNS doesn’t work in the tunnel, you should test separately:

• Is the target reachable via IP address?
• Is the internal DNS server allowed by the firewall rule?
• Does the client receive the correct search domain?
• Does the client really use the current .ovpn profile?
• Does the endpoint’s local DNS or DoH configuration intervene?

For Split Tunnel, DNS should be planned particularly carefully. If only internal target networks are routed through the tunnel, it must be clear whether internal names are resolved via the internal DNS server and whether public names are resolved locally or via the firewall. Otherwise, errors arise in which IP access works, but internal host names only resolve on individual clients.

3. Create SSL VPN policy

The policy is created under:

Remote access VPN > SSL VPN

Process:

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

Important: If users or groups are enrolled in a newer SSL-VPN policy that are already included in an older SSL-VPN policy, Sophos Firewall removes this association from the earlier policy. You should therefore avoid policy overlaps and clearly define which policy applies for each user group.

After policy changes, a normal user from the target group should be checked in VPN Portal. Exactly the expected SSL-VPN configuration should be visible, not several old profiles or no configuration at all. This portal test reveals group errors more quickly than a pure admin test with special rights.

4. Choose Split Tunnel or Full Tunnel

Split Tunnel

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

Split Tunnel often fits:

• Access to a few internal applications,
• lower firewall load,
• better user performance,
• smaller remote locations 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 remote user traffic is routed through the firewall. In Sophos Firewall this corresponds to the Use as default gateway option.

Full Tunnel is more suitable if:

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

For Full Tunnel, the SSL VPN policy alone is not enough. You also need firewall rules and NAT/SNAT for internet traffic from the VPN zone. You should also test performance, bandwidth, web filtering and logging beforehand. Full Tunnel should not be activated just because individual Split Tunnel targets are difficult to maintain. When all internet traffic goes through the firewall, capacity, web filtering, DNS, logging, data protection and support overhead become part of the design.

5. Create firewall rules for VPN zone

Establishing a tunnel does not mean that traffic is allowed. To access internal resources you need a suitable firewall rule:

Rules and policies > Firewall rules

Recommended rule for Split Tunnel:

• Rule name: VPN_SSLVPN_to_Internal_Servers.
• Source zone: VPN.
• Source networks and devices: ##ALL_SSLVPN_RW.
• Destination zones: internal target zones, for example LAN or DMZ.
• Destination networks: only allowed servers or subnets.
• Services: only needed services.
• Log firewall traffic: activate.

For Full Tunnel you also need a rule from VPN to WAN or Any, depending on the design. The Source Networks should still be the SSL VPN system hosts. It must then be checked whether a suitable SNAT rule exists.

If there is a connection but no access works, you should first check the Log Viewer. Test firewall rule with Log Viewer, Policy Test and Packet Capture is suitable for the methodology.

Rules for SSL VPN should be in a clearly named group, for example VPN Remote Access. A broad rule like VPN_to_LAN_Any is convenient, but makes subsequent error analysis difficult and often allows more access than is technically necessary. Separate rules per target area or service class with active logging are better.

6. Secure VPN Portal and Device Access

Users typically load Sophos Connect and the .ovpn file from 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 required externally.
• No permanently open User Portal on WAN when not in use.

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

The VPN Portal only appears useful for users if they or their groups are included in an appropriate remote access policy. If the policy assignment is missing, the user will not see the required configuration downloads.

If VPN Portal or SSL VPN need to be allowed on the WAN zone, this should be deliberately 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 checking or an upstream remote access design should be examined.

It is important to separate WebAdmin and VPN Portal. WebAdmin is the firewall’s administration interface. The VPN Portal is the user access for downloads and VPN profiles. Both services should not be grouped together because they have different risks, ports, permissions, and audiences.

7. Distribute client profile

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

Important:

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

Typical profile changes in operation:

• New FQDN or new public IP: Re-download .ovpn and replace old profile.
• Port or protocol changed: Re-import profile and remove old connection entry.
• Certificate renewed or changed: Redistribute profile and actively check certificate warnings.
• DNS server or domain name changed: Import new profile and test name resolution.
• Lease range changed: Re-import profile and check route/client address.
• User group or policy changed: Test portal download with normal target user.

For client updates and version maintenance, Check Sophos Connect Client version and update it safely.

Test after configuration

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

Test list:

• User sees the Sophos Connect download and the SSL VPN configuration in the VPN Portal.
• .ovpn file can be imported.
• MFA is polled as expected.
• Client receives an address from the SSL VPN lease range.
• Route to the permitted internal networks appears at the endpoint.
• Internal DNS names are resolved.
• Access to permitted servers works.
• Unauthorized networks remain blocked.
• Log Viewer shows the correct firewall rule.
• A deliberate negative test will be rejected and logged.
• Packet Capture shows traffic via a tun interface if necessary.
• Internet access and SNAT also work with Full Tunnel.

If the test is only done with one admin user, it is easy to miss group and policy errors. A normal pilot user from the target group is better.

A good acceptance test always includes blocked access. This is the only way to see whether the firewall rules are really limiting or whether a rule that is too broad further down the set of rules still allows access.

Acceptance test by scenario

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

• New User: Registration on VPN Portal and profile import. User only sees the matching SSL-VPN configuration and can import the profile.
• MFA active: Login with correct and incorrect OTP. Correct factor allows access, incorrect factor is rejected and logged.
• Split Tunnel: Access to allowed and not allowed internal target. Allowed destinations work, other networks remain blocked.
• Full Tunnel: Internet access via VPN. Firewall rule, SNAT, DNS and web/security policy work as planned.
• DNS: Access by name and by IP address. DNS errors can be separated from routing or rules problems.
• Profile change: Import new .ovpn profile. Changed FQDN, port, DNS or certificate is visible in client profile.
• Error case: Check Log Viewer and Packet Capture. The actual matching firewall rule and the packet flow are traceable. For production environments, each test should contain a time, user, client platform, and specific target. Statements like “VPN works” or “VPN doesn’t work” are too imprecise for later support cases.

Collect logs and evidence

If you have SSL-VPN problems, you should first clarify whether the error is with the login, the tunnel setup or the access to internal destinations. This separation saves time because otherwise authentication, client profile, routing and firewall rules are checked together.

For a reproducible test case, this information should be noted:

• Username and Group: shows which SSL-VPN policy and authentication should apply.
• Client platform and Sophos Connect version: separates client errors from firewall configuration.
• Time of test: makes Log Viewer, sslvpn.log and authentication logs comparable.
• User’s source network: helps with hotel-WLAN, cellular, CGNAT, restrictive firewalls or port problems.
• Target system and service: prevents overly broad statements like “VPN doesn’t work”.
• Result by IP address and by DNS name: separates routing and DNS problems.

You should then carry out the test in this order:

1. Check Authentication: Check in Log Viewer and if necessary in the authentication logs 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. sslvpn.log and openvpn-status*.log help on the firewall side.
3. Check firewall rule: Search for traffic from the VPN zone in the Log Viewer 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 for source, destination and service with Packet Capture. What is important is whether packages are only Incoming or also become Forwarded.
5. Check destination side: If traffic leaves the firewall but no response comes back, return route, server firewall, local host firewall or network conflict are more likely than the SSL VPN policy.

Sophos Firewall Troubleshooting: Services and Logs is suitable for assigning the most important log files. For rule analysis with Log Viewer, Policy Test and Packet Capture, Test firewall rule with Log Viewer, Policy Test and Packet Capture fits.

Troubleshooting

User does not see SSL VPN configuration in VPN Portal

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

If the login and policy assignment work correctly, 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 several users use the portal, but only individual downloads fail unexpectedly.

Tunnel connects, but internal systems cannot be reached

First check whether a route to the internal target network exists at the endpoint. Then search the Log Viewer for traffic from the VPN zone. If no traffic is visible, the client is not reaching the firewall as expected or the profile is out of date.

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

After a change, only some of the clients work

If new users work but old clients don’t, profile distribution is usually the problem. You check whether affected clients have really imported the current .ovpn profile and whether old connection entries have been removed.

Especially after changes to FQDN, port, certificate, DNS, lease range, policy or authentication, you should not only save the firewall, but also actively test a profile download with a normal user. You can then check at the endpoint whether the gateway, DNS and routes correspond to the current design.

DNS is not working

You check whether access via IP address works. If so, the error is probably with DNS. Then check DNS server in global SSL VPN settings, domain name, Device Access for DNS from VPN zone and endpoint DNS behavior.

Access only works for some users

Then group membership, policy mapping, SSL VPN static IP addresses, MFA status, or stale profiles are more likely than a global firewall error. You should also check for duplicate policy assignments.

User needs to reconnect after several hours

If SSL VPN initially works, but after several hours a new login or a manual rebuild is necessary, you should first check the time pattern, authentication and lease model. This is particularly relevant for local authentication with a statically assigned SSL VPN IP.

Practical process:

1. Note the time the connection was established and aborted.
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. Check 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 see 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 reworked. In most cases, groups, clearly named targets, narrow services and logging are a better basis than individual user IP addresses.

Full Tunnel does not have internet access

With Use as default gateway, a firewall rule is required for traffic from the VPN zone towards the Internet and a suitable SNAT rule. In addition, web, DNS and security policies must be planned so that they do not unexpectedly block VPN users.

Connection is established, but large transfers are hanging

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

For systematic analysis, Sophos Firewall Check MTU and MSS for VPN problems fits.

WAF or portal collides with SSL VPN

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

Profile is out of date after change

After any 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 checked for VPN Portal and SSL VPN.
• SSL-VPN-Lease-Bereich does not conflict with internal or typical home networks.
• SSL-VPN policy contains the correct users or groups.
• Split Tunnel or Full Tunnel is deliberately decided.
• Permitted network resources are narrowly defined in Split Tunnel.
• DNS server and domain name are set correctly.
• Firewall rule from VPN to internal targets exists and logs.
• Full Tunnel has internet rules and SNAT.
• Device Access for SSL VPN and VPN Portal is deliberately set.
• MFA is tested for remote access.
• Test user can download, import profile and achieve internal goals.

For ongoing operations

• MFA for VPN Portal and force remote access.
• Check VPN groups regularly.
• Keep firewall rules tight for VPN and log.
• Check Lease-Bereich before network changes.
• Only use static SSL VPN IP addresses specifically and check them regularly.
• Document DNS and search domain.
• Renew portal and SSL VPN certificates before expiration.
• Track Sophos Connect versions.
• Schedule profile redistribution after changes.
• Evaluate logs over the long term using Syslog or Sophos Central if traceability is important.

Sophos Firewall Troubleshooting: Services and Logs is suitable for log files and services.

Check special cases regularly

• Static SSL VPN IP addresses are justified and documented.
• Key Lifetime fits the operating model and has been tested with Reconnect.
• Old .ovpn profile will be 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 checked separately.

FAQ