Skip to content
Avanet

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

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

Since SFOS 20.0 MR1, Sophos has used a newer OpenVPN component. SSL Site-to-Site tunnels from SFOS 20.0 MR1 or later do not connect to SFOS 18.5 or earlier, or to UTM 9. In such a combination, both Sophos Firewalls must be updated, or IPsec or a RED tunnel must be used instead.

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 and imported with its private key and full certificate chain. 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.

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:

  1. Open Site-to-site VPN > SSL VPN.
  2. In the Server section, click Add.
  3. Enter HQ-to-Branch as the name.
  4. Under Local networks, select HQ-LAN.
  5. Under Remote networks, select Branch-LAN.
  6. 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.
  7. 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.

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 and set a strong temporary password. 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:

  1. Open Site-to-site VPN > SSL VPN.
  2. In the Client section, click Add.
  3. Enter Branch-to-HQ as the name.
  4. Under Configuration file, select the exported .apc file.
  5. If the export is encrypted, enter the password.
  6. Enable Use HTTP proxy server only if the branch actually reaches the server through an explicit HTTP proxy.
  7. 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.
  8. Click Save and activate the connection.

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.

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.

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.

  1. On both firewalls, check for a green status and increasing byte counters.
  2. Test the destination first by IP address and then by hostname.
  3. Open an actually permitted service such as HTTPS or RDP.
  4. In Log Viewer, verify the expected Firewall Rule ID and unchanged source and destination addresses.
  5. Test a service or destination that is not permitted and confirm the drop.
  6. Test the reverse direction separately if it is meant to be allowed.
  7. 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: FQDN hosts and groups are supported as local and remote networks. After a DNS change, disconnect and reconnect the tunnel in a controlled manner, then check the route and application traffic to the newly resolved IP. Failed resolution is first a traffic or routing problem, not automatically a tunnel-establishment problem.
  • 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.
  • One side runs SFOS 18.5 or UTM 9: Do not continue troubleshooting the port or certificate. This combination is incompatible with a current peer; update both sides or use 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.