Troubleshoot remote access VPN

Cause

Firewalls using SFOS 20.0 MR1 won't establish remote access SSL VPN connections with the legacy VPN client that was available earlier.

Remedy

You can use one of the following options:

• Use the Sophos Connect client.
• Use remote access IPsec connections.

Cause

In version 19.0.x and later, on SSL VPN global settings, for Assign IPv4 addresses, you enter a network IP address and subnet rather than an IP range.

Here's an example:

The firewall leases IP addresses to remote access SSL VPN users from the network you configure.

When you migrate to 19.5 and later, the firewall converts the IP range and subnet mask configured in 18.5.x and earlier versions to the subnet value.

However, if you've added a custom IP host for the lease range to the corresponding firewall rules, the host's lease range may not match the migrated subnet. So, traffic may not flow through the remote access SSL VPN connections after you migrate.

Remedy

For the source and destination networks in the corresponding firewall rules, select the system hosts ##ALL_SSLVPN_RW and ##ALL_SSLVPN_RW6. See Configure remote access SSL VPN as a split tunnel.

The firewall automatically applies the conversion from IP range to network for these system hosts because it dynamically adds the leased IP addresses to these system hosts when remote users establish connections.

The issue may occur because of incomplete certificate or CA configurations or other reasons.

Do as follows:

1. Make sure you've correctly configured the signing CA. By default, the server certificate uses ApplianceCertificate, and its CA is Default CA.
2. Regenerate the certificate generated from this CA.
3. Users must download and install the SSL VPN configuration (.ovpn) file again.

Make sure you have the following configurations:

• A firewall rule to allow traffic from the VPN zone to the WAN zone.
• An SNAT rule to masquerade outbound traffic.

For more information, see Check the SNAT rule.

Cause

The Sophos Connect Client configuration uses a third-party certificate.

On Remote access VPN > IPsec, when you set the local certificate to ApplianceCertificate or any locally-signed certificate and set the remote certificate to a third-party certificate, the client imports the connection and establishes a connection the first time. The error message appears when users try to connect after the endpoint or the Sophos Connect client restart.

The error appears when the same CA hasn't signed the local and remote certificates.

Remedy

Do one of the following:

• Set self-signed certificates generated on the firewall or those signed by the same third-party CA as the local and remote certificates.
• If you use third-party certificates, upload the signing CA to the firewall.
• Alternatively, use a preshared key for IPsec remote access connections.

If your IPsec tunnel is disconnected, check if you have turned off the associated interface.

If you've turned off the associated interface:

• Site-to-site IPsec tunnel initiators immediately disconnect the tunnel.
• Site-to-site IPsec tunnel responders and remote access connections disconnect the tunnel when inactivity or Dead Peer Detection (DPD) time-out occurs.

During phase 1 IKEv1 rekeying, remote access IPsec tunnels go down when an OTP request is made.

The default IPsec profile's rekey interval is implemented as approximately four hours.

If you want to prevent the disruption, create a custom IPsec profile with a longer rekey interval of up to 24 hours.

Check if the username has umlaut, UTF-8, or UTF-16 characters. Currently, the Sophos Connect client doesn't support these. It only supports ASCII characters.