Skip to content
Avanet

Set up Sophos Firewall IPsec Site-to-Site with certificates

Sophos Firewall

A shared preshared key is quick to set up for a single site tunnel. With several firewalls or stricter PKI requirements, a digital certificate is often easier to control: each side has its own private key, the peers trust the issuing CAs, and an individual certificate can be renewed or revoked selectively.

This procedure shows a policy-based IPsec connection between two Sophos Firewalls. It complements the general guide to set up a Site-to-Site IPsec VPN. Route-based designs additionally require routing and XFRM planning, but the trust and certificate procedure described here remains the same.

The safe procedure in eight steps

  1. Document the tunnel roles, networks, IKEv2 profile and Certificate IDs.
  2. Verify a configuration backup and working administrator access on both firewalls.
  3. Export each firewall’s issuing CA and import it on the peer.
  4. Generate a separate locally signed certificate with a unique Certificate ID on each firewall.
  5. Export only the public certificate and import it on the peer as the Remote Certificate.
  6. Create policy-based IPsec with Authentication type > Digital certificate on both sides.
  7. Closely review Device Access and automatically generated firewall rules.
  8. Validate tunnel status, certificate trust, logs and real traffic in both directions.

⚠️ The private key file remains on the firewall where the certificate was generated. Only CA certificates and public peer certificates are transferred for the trust exchange. Without tested secondary administrator access, a backup and a documented recovery path, do not disable existing PSK tunnels or replace production certificates.

Example and planning values

The example connects head office SF1 to branch SF2:

SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN
  • SF1 WAN: 172.10.10.1
  • SF2 WAN: 172.20.20.1
  • SF1 certificate: SF1_Certificate
  • SF2 certificate: SF2_Certificate
  • SF1 Certificate ID: 172.10.10.1
  • SF2 Certificate ID: 172.20.20.1

These addresses and names are documentation values. In the actual environment, use the real WAN addresses, network objects and an organization-wide unique ID scheme. The Certificate ID must remain associated with the corresponding peer and must not be confused with the display name or an arbitrary SAN.

Establish mutual CA trust

First, on SF1, review and download the issuing CA under Certificates > Certificate authorities. If the example uses the local Default CA, give the exported file an unambiguous name such as Head_Office_Default.pem. On SF2, import it under Certificates > Certificate authorities > Add, for example as SF1_CA.

Then repeat the procedure in the opposite direction: export the CA from SF2, give it an unambiguous name such as Branch_Office_Default.pem, and import it on SF1, for example as SF2_CA.

The filenames are only for administration. Subject, issuer, fingerprint, validity and the correct CA chain are what matter. Compare these values through an independent channel before import. Manage certificates on Sophos Firewall explains the general CA, certificate and service-assignment tasks.

Do not regenerate the built-in Default CA as a side task. Regeneration changes the trust anchor and can affect other portals, TLS services and IPsec peers. For an enterprise CA, import its complete trusted chain instead.

Prepare local and remote certificates

Create the local certificate on SF1

On SF1, create a certificate under Certificates > Certificates > Add > Generate locally-signed certificate. The Sophos example uses RSA, a key length of 2048 and SHA-256. These values do not replace the organization’s cryptography and validity policy; the selected IPsec profile and both peers must support them.

Under Subject Alternative Names (SANs) > Advanced settings, select a Certificate ID. Supported types are DNS, IP address, Email and DER ASN1 DN [X.509]. The example uses IP address with 172.10.10.1.

With DER ASN1 DN [X.509], Sophos uses the subject of the issuing CA. In this case, leave DNS names and IP address under SANs empty because, according to Sophos, additional values cause a conflict during IPsec authentication.

After Save, check validity, issuer, Certificate ID and that the private key exists. Export the public certificate, change the extension to .cer if required, and import it on SF2 under Certificates > Certificates > Add > Upload certificate as SF1_Certificate. The Trusted column on the peer must confirm trust through SF1_CA.

Create the local certificate on SF2

Repeat the procedure on SF2 with a separate private key. In the example, the certificate is named SF2_Certificate, the Certificate ID is 172.20.20.1, and the issuing CA is the local CA on SF2.

Import the public certificate on SF1. There, Trusted must be confirmed through the previously imported SF2_CA. Each firewall now has exactly two different roles:

  • Local certificate: its own certificate with the private key.
  • Remote certificate: the peer’s public certificate, validated by its CA.

A green trust checkmark proves the certificate chain, but not a working tunnel. Validity, Certificate ID, IKE profile, gateway and networks must still align. Revocation and CRL distribution are a separate operational process; see Certificate Revocation Lists on Sophos Firewall.

Create the IPsec connection on both sides

Under Site-to-site VPN > IPsec > Add, create two matching connections. In the example, the head office waits for the branch:

  • Connection type: Policy-based
  • Gateway type: Respond only
  • Profile: Head office (IKEv2) or an aligned custom profile clone
  • Authentication type: Digital certificate
  • Local certificate: SF1_Certificate
  • Remote certificate: SF2_Certificate
  • Listening interface: WAN on SF1
  • Local subnet: SF1_LAN
  • Gateway address: WAN address of SF2
  • Remote subnet: SF2_LAN

Reverse the roles at the branch:

  • Gateway type: Initiate the connection
  • Profile: Branch office (IKEv2) or its matching custom profile
  • Local certificate: SF2_Certificate
  • Remote certificate: SF1_Certificate
  • Local subnet: SF2_LAN
  • Gateway address: WAN address of SF1
  • Remote subnet: SF1_LAN

Plan the profiles as a pair. Understand IPsec profiles on Sophos Firewall explains how IKEv2, phase 1, phase 2, PFS, lifetimes and DPD work together.

Check Device Access and firewall rules

The side with Gateway type > Respond only must be allowed to accept IPsec connections on the intended WAN path. Under Administration > Device access, therefore enable IPsec only for the WAN zone actually required, or use a narrow Local Service ACL exception for known peer addresses. SSO, certificates or a strong IPsec algorithm do not justify broad WebAdmin or SSH access. Configure Device Access securely on Sophos Firewall explains the ACL planning.

When Create firewall rule is enabled, SFOS creates automatic VPN rules. These rules are a starting point. Under Rules and policies > Firewall rules, review order, direction, source and destination networks, services and logging, then narrow them to the actual requirement. Create firewall rules on Sophos Firewall explains rule validation.

Ping/Ping6 for the VPN zone is only required when a firewall address itself is intentionally used as the test target. This local service does not need to be enabled broadly for a normal end-to-end test between hosts behind the firewalls.

Validate the tunnel and certificates

Validation separates four layers:

  1. Under Site-to-site VPN > IPsec, the connection and tunnel are active.
  2. Both firewalls show the expected Local and Remote Certificate, valid lifetimes and a trusted issuer.
  3. A real test host reaches the intended service in the remote network, and the reverse direction is then tested.
  4. Firewall Rule ID, Packet Capture and IPsec logs confirm the same path and timestamps.

strongswan.log is the main starting point for IKE and certificate errors. charon.log, ipsec_monitor.log and the connection-specific log under /log/ipsec_conn/ provide additional evidence. Sophos Firewall IPsec troubleshooting covers the complete diagnostic procedure.

Narrow down errors by symptom

Tunnel remains down

First confirm that Local certificate and Remote certificate are truly mirrored on both sides. Then check Certificate ID, Gateway address, IKEv2 profile, validity and trust chain. An imported peer certificate without the corresponding CA is not a trusted identity.

Certificate is Trusted, but authentication still fails

Trusted only confirms the chain. With DER ASN1 DN [X.509], no additional DNS or IP SAN values may override the identifier. With the other ID types, value, type and expected peer must match exactly. Compare the IDs actually offered and expected in strongswan.log for the same connection attempt.

Tunnel is green, but no traffic flows

Certificate authentication has already succeeded. Now check local and remote subnets, automatic VPN rules, Rule ID, NAT, return route and the real destination service. Regenerating certificates speculatively only obscures the original state in this situation.

Certificate is about to expire

Prepare the new local certificate in parallel, transfer its public part to the peer and confirm trust there. Only during a maintenance window, change Local certificate and Remote certificate on both sides in a controlled manner. Keep old certificates and CAs available until successful bidirectional validation, and remove or revoke them only afterwards.

Rollback and operations

Before the change, document both IPsec connections, certificate names, fingerprints, Certificate IDs, validity periods and current rule order. A Sophos Firewall configuration backup is part of the preparation, but does not replace direct recovery access to the firewall.

If validation fails, restore the previously used certificate assignments or reactivate the still available PSK tunnel. Delete newly imported peer certificates or CAs only after confirming that no other connection or service uses them. Then recheck tunnel status and a real test flow.

In operation, certificates require an owner, expiry monitoring and a planned renewal window. The first alert should leave enough time for issuance, trust distribution, parallel testing and rollback. Replacing a certificate only on its expiry date turns planned maintenance into a VPN outage.

Frequently asked questions

Is a certificate automatically more secure than a long preshared key?

Not automatically. The main advantages are separate private keys, selective renewal and revocation, and traceable CA trust. Weak profiles, unprotected private keys or unplanned validity periods remain security problems.

Must the peer certificate be imported in addition to the CA?

Yes, in this Sophos-to-Sophos procedure. Each firewall uses its own certificate as the Local Certificate and the peer’s public certificate as the Remote Certificate. The imported CA establishes trust in that peer certificate.