Set up an SSL Site-to-Site VPN on Sophos Firewall

An SSL Site-to-Site VPN connects the internal networks of two Sophos Firewalls through an encrypted tunnel. Unlike IPsec, both sides have fixed roles: the client firewall always initiates the connection, while the server firewall accepts it.

This is particularly useful when a branch has a dynamic public IP address or when IPsec encounters problems in an upstream network. The head office with a static address or stable FQDN becomes the server, and the branch becomes the client. For growing networks, dynamic routing, redundancy or a third-party peer, route-based IPsec is usually more flexible; for a small Sophos-to-Sophos connection, SSL Site-to-Site can be simpler.

This guide uses a specific example:

Head office, server: vpn.example.com, local network 10.10.0.0/24
Branch, client: dynamic public IP, local network 10.20.0.0/24
Connection: HQ-to-Branch
SSL VPN port: 8443

vpn.example.com, the object names and both networks are placeholders and must be replaced with values from the actual environment. 8443 is the default port; keep it only if the port allocation and security design allow it.

The quick flow is: assign roles and networks, check the global SSL VPN settings, allow SSL VPN on the server’s WAN zone, create the server connection, export the .apc file, import it on the client firewall, and then verify routes, rules and real application traffic.

⚠️ The global SSL VPN settings are also used by Remote Access SSL VPN. Do not change the port, protocol, certificate, address range or cryptographic settings solely for this tunnel. First assess the effect on existing user connections and profiles.

Plan roles, networks and public access

The server firewall should be the more stable appliance and, when the models differ, the more powerful one. If only one side has a static public IP address, that side belongs in the server role. The client can be behind NAT or use a connection with a dynamic address as long as it can reach the server.

Define the following before configuration:

public IP address or FQDN of the server firewall;
protocol and port for SSL VPN;
local network at the head office and local network at the branch;
unique, non-overlapping address ranges;
required services and permitted connection directions;
return path on both sides;
alternative administrative access for the change;
current SFOS versions on both firewalls.

If the networks overlap, this standard configuration is not sufficient. A deliberate translation and routing design is then required; in practice, IPsec with planned NAT is usually more suitable.

Check compatibility before the change

Both help versions still include the migration warning for SFOS 20.0 MR1: SFOS 20.0 MR1 and later versions cannot establish an SSL Site-to-Site connection to SFOS 18.5 or earlier, or to UTM 9. This warning is not a complete compatibility matrix for all later builds. Check the specific pairing before upgrading; for an affected connection, bring both Sophos Firewalls to compatible, supported versions or plan IPsec or a RED tunnel. UTM 9 cannot simply be updated by applying an SFOS upgrade.

Check the global SSL VPN settings

The shared settings are located on the future server firewall under:

Remote access VPN > SSL VPN > SSL VPN global settings

For this example, check the following values in particular:

Protocol: UDP is usually the more efficient starting point; TCP can help in restrictive networks.
SSL server certificate: must be valid. Import an external certificate with its private key under Certificates > Certificates; for an external certificate chain, also upload the intermediate and root CAs. When a public FQDN is used, the certificate should match that name.
Override hostname: vpn.example.com when clients should use this exact FQDN.
Port: 8443 unless a different port design has been deliberately planned.
Assign IPv4 addresses: must not overlap with either site network or any other VPN pool.
Cryptographic settings: do not change existing values without compatibility and operational testing.

If the server firewall is behind an upstream router, the router must forward the selected port and protocol to the firewall. The FQDN then points to the router’s public address. WAF and SSL VPN must not use the same combination of WAN IP, port and protocol.

If Port, Protocol, SSL server certificate or Override hostname changes later, download the server configuration again and reimport it on the client firewall. The existing .apc export does not contain the new values.

SSL VPN Remote Access on Sophos Firewall explains all dependencies of the global settings. Plan changes there with existing user profiles, lease ranges, DNS and publicly reachable services in mind.

Allow SSL VPN for the server WAN zone

Allow the local SSL VPN service for the incoming zone on the server firewall:

Administration > Device access

If the client firewall has a dynamic public address or one that cannot be usefully restricted, enable SSL VPN for WAN under VPN services. This only permits the tunnel to connect to the firewall; it does not replace a firewall rule for application traffic between the sites.

This permission is only required on the server firewall. The client firewall establishes the tunnel outbound, so do not enable SSL VPN for WAN in Device Access there as a precaution.

If the public source networks on the client side are stable and known, leave SSL VPN disabled in the WAN matrix. Instead, create a targeted Accept Local Service ACL Exception with Source zone WAN, the known Source Networks/Hosts, the server WAN address as Destination host, and SSL VPN as the Service. An Accept exception does not narrow an already enabled WAN matrix permission. Configure Device Access securely on Sophos Firewall explains the planning.

Create the server connection at the head office

First create both networks as IP host objects on the server firewall:

Hosts and services > IP host

HQ-LAN: 10.10.0.0/24
Branch-LAN: 10.20.0.0/24

Then create the server connection:

Open Site-to-site VPN > SSL VPN.
In the Server section, click Add.
Enter HQ-to-Branch as the name.
Under Local networks, select HQ-LAN.
Under Remote networks, select Branch-LAN.
Enable Use static virtual IP address only when there is a justified need, and choose a free address outside the global static and dynamic SSL VPN ranges that does not conflict with any other private IP address.
Click Save.

From the server firewall’s perspective, Local networks are the head-office networks. Remote networks are located behind the client firewall. This perspective matters: if the objects are reversed, the tunnel can turn green even though routes and rules do not match the intended connection.

Without Use static virtual IP address, the firewall automatically assigns the client an address from the lease range in SSL VPN global settings. For a fixed assignment, enter the chosen address in Static peer IP; this is the client’s virtual tunnel address, not the branch LAN.

The help texts specify a maximum of 1024 hosts each for Local networks and Remote networks. They do not explain here how network objects are counted compared with individual IP addresses. This does not establish a blanket subnet-size limit or justify splitting the same networks as a workaround. For a configuration near this limit, check object selection and saving on the specific build and clarify the counting method before the production change.

Export the server configuration securely

In the server list, select Download for HQ-to-Branch. The export uses the .apc format and contains the connection details for the client firewall.

For secure transfer, enable Encrypt configuration file, enter and confirm a strong temporary password, then click Download. Send the file and password through separate channels. The .apc file does not belong in a public ticket, an unprotected chat or a permanent download directory.

Import the configuration on the client firewall

Import the configuration on the branch firewall under the same menu path:

Open Site-to-site VPN > SSL VPN.
In the Client section, click Add.
Enter Branch-to-HQ as the name.
Click Choose file and select the exported .apc file.
If the export is encrypted, enter the password.
Enable Use HTTP proxy server only if the branch actually reaches the server through an explicit HTTP proxy. Then enter the approved proxy server and its actual listening port. Enable Proxy requires authentication only if that proxy requires a login; use the designated proxy username and its corresponding password. Do not assume a port or change global proxy settings as a workaround.
Set Override peer hostname only if the server address in the export cannot be routed or resolved from the client network. Leave the field empty in this example because vpn.example.com is already exported through the global setting.
Click Save and activate the connection.

The password for the encrypted .apc import decrypts the file; it is not the proxy password. Override peer hostname identifies the server peer, not the proxy. Keep both passwords confidential and out of screenshots, logs and tickets. After saving, reopen the client entry and compare the proxy server, port, authentication option and peer with the approved values without exposing secrets; then check the tunnel and application traffic as described below.

For XML API automation, the retained SFOS 22 and 23 Add/Edit samples show ProxyServer, ProxyPort and ProxyAuthentication only when HttpProxyServer = Enable, and Username and Password only when proxy authentication is enabled. FilePassword belongs to ServerConfigurationFile; PeerHost/HostName is a separate branch. The table marks the proxy server and port as required although the sample makes them conditional, and gives proxy authentication a default of OFF but allowed values of Disable/Enable. Do not infer a serializer or valid request from this: if field inclusion or value representation is unclear, withhold automation, use the supported UI path and clarify the schema for the specific build with Sophos Support.

The status turns green when the client firewall reaches the server and establishes the tunnel. A green status confirms only the tunnel itself, not access to servers, DNS or applications.

Check routes and firewall rules

The networks selected under Local networks and Remote networks take effect for tunnel routing. They belong to the static routing class and must align with the rest of the routing configuration. A more specific static, SD-WAN or VPN route can otherwise produce a different path than expected. Understand and adjust routing precedence on Sophos Firewall explains the order.

Create firewall rules for application traffic deliberately on both firewalls, or verify suitable existing rules. In this example, where the branch initiates connections to the head office, at least the following is required:

on the branch firewall, a tightly scoped rule from LAN to VPN for Branch-LAN to the required destinations in HQ-LAN;
on the server firewall, a matching rule from VPN to LAN for Branch-LAN to those destinations;
only the required services, such as DNS, RDP and HTTPS;
Log firewall traffic during acceptance testing;
no SNAT or MASQ rule that changes site traffic without a valid technical reason.

These two rules cover the new connection initiated by the branch and its stateful return traffic; two additional mirrored rules are not required for that flow. Do not copy the zones from an IPsec guide. In Log Viewer or Packet Capture, the test flow must travel from LAN into the SSL VPN tunnel on the branch firewall and from the SSL VPN tunnel to LAN on the server firewall. If the observed zone, Out interface or Rule ID differs, correct routing and rule matching first rather than widening the rule to Any.

If the head office must also initiate new connections to the branch, permit the reverse directions separately. A broad Any rule is not a finished security design. Test a firewall rule explains how rule position, Rule ID and Packet Capture work together.

Plan failover and rollback

An SSL Site-to-Site tunnel does not become part of an IPsec failover group. The .apc file gives the client the exported server connection. An FQDN or multiple WAN paths alone do not provide seamless redundancy: an existing session breaks during a WAN change, and the client must reach the configured server again over the new path. Use route-based IPsec when automatic tunnel failover across several defined connections is required.

For a simple WAN failover test, keep the active server FQDN resolvable and reachable over the backup path; upstream NAT and port forwarding must present the same SSL VPN protocol and port there. Then verify that the client reconnects and that both permitted and blocked application traffic are still handled as designed. A green tunnel alone is not an acceptance criterion here either.

Before the change, record the previous global SSL VPN values, Device Access permissions, server and client entries, rules, and the last working .apc file. To roll back, first disable the new rules and connections, restore the previous global values and Device Access settings, and import the previous .apc file on the client. Remove new objects only after the tunnel, positive test, and negative test work again. This preserves a recovery path even when the new tunnel turns green but routes application traffic incorrectly.

Before an authorized deletion under Site-to-site VPN > SSL VPN, select the exact saved connection name, firewall and Client or Server role, check dependent production peers and rules, and retain the working export and recovery path. The retained SFOS 22 and 23 XML Delete pages mark Name as optional but contain no Delete request sample. This does not authorize targetless or broad deletion or make client and server operations interchangeable. If identity or schema is unclear, do not execute an XML deletion: retain the supported UI path and obtain build-specific clarification. After removal, inspect the operation-specific response and the actual state of the exact target entry; recheck other production connections and their permitted and blocked traffic.

Validate the tunnel and application traffic

Start the test with a specific client and a specific destination. In this example, a device in 10.20.0.0/24 accesses an allowed server in 10.10.0.0/24.

On both firewalls, check for a green status and increasing byte counters.
Test the destination first by IP address and then by hostname.
Open an actually permitted service such as HTTPS or RDP.
In Log Viewer, verify the expected Firewall Rule ID and unchanged source and destination addresses.
Test a service or destination that is not permitted and confirm the drop.
Test the reverse direction separately if it is meant to be allowed.
After a restart or WAN change, verify that the client firewall re-establishes the tunnel.

A successful ping is not sufficient. It proves neither DNS nor the required application service. For an internal destination, the firewall rule, return path and endpoint firewall must all permit the test; Device Access is relevant only when pinging an address of the Sophos Firewall itself.

Read logs when an error occurs

Open SSL VPN logging directly under Site-to-site VPN > SSL VPN > Logs. For a deeper check, connect through SSH, select 5. Device Management > 3. Advanced Shell, and read the current service log:

tail -n 200 /log/sslvpn.log

The command does not change the configuration. Record the time, connection name and server/client side together. Depending on the number of processes, additional OpenVPN status files may exist as openvpn-status0.log, openvpn-status1.log and further files; Sophos Firewall service logs explains the mapping.

Narrow down common errors

Tunnel remains red: Check the public FQDN, DNS, port forwarding, protocol, certificate and SSL VPN in Device Access for the server WAN zone. Then read sslvpn.log for the same time.
The tunnel no longer comes up after a global change: Export the server configuration again and reimport it on the client. The port, protocol, certificate and Override hostname in particular are export-dependent.
The tunnel is green, but no traffic flows: Check tunnel routing, routing precedence, rules on both firewalls, Rule ID, return path, NAT and endpoint firewall. Then trace one flow with Packet Capture.
Only hostnames do not work: Test access by IP, check DNS servers and the search domain, and ensure that the DNS server is reachable and allowed through the tunnel.
An FQDN host object still points to the old address: From SFOS 20.0, FQDN hosts and groups can be used as Local networks and Remote networks. After a DNS change, first compare the address resolved on the firewall with the expected IP, then check the selected objects, route and one application-traffic flow. The evidence here does not establish that disconnecting and reconnecting an SSL Site-to-Site tunnel refreshes these addresses; do not interrupt a working tunnel solely to force a DNS refresh. If the route remains stale, record the build, resolution, route and logs for further investigation. Do not confuse a destination object’s FQDN with the server FQDN: failure to resolve the latter can prevent tunnel establishment itself.
The client can reach the server only through a proxy: Use Use HTTP proxy server with the approved proxy values; do not enter arbitrary proxy details as a generic workaround.
Failure after migration, with a peer on SFOS 18.5 or earlier or UTM 9: First check the version pairing against the SFOS 20.0 MR1 warning above before changing the port or certificate. An affected connection needs compatible peers or a planned alternative using IPsec or RED.

If the tunnel remains unclear after a controlled test, collect the SFOS version and build of both firewalls, time with time zone, connection name, sslvpn.log, Rule IDs and a short Packet Capture. Only then should rules, networks or global SSL VPN settings be changed further.