Overview

Users connected through a Service Tunnel can reach a private resource published by a SonicOS firewall Connector, but a connection that stays open for a long time is cut off before the work finishes. This is most often reported with database clients, remote shells, large file transfers, and reporting tools, because each one holds a single connection open while the server works on a request.

Symptoms

• A query, report, or transfer runs for several minutes and then fails part way through, while shorter requests to the same resource succeed.
• The client reports a dropped or reset connection, rather than a sign-in or DNS (Domain Name System) error.
• Reconnecting works right away, and the same long request fails again after roughly the same amount of time.
• The resource is published by a SonicOS firewall Connector.

Potential Root Cause

In this situation the connection is usually being closed by the firewall rather than by CSE.

SonicOS access rules apply a TCP (Transmission Control Protocol) connection inactivity timeout. TCP is the protocol most business applications use to hold an open connection to a server. If a connection sends no traffic for longer than the timeout, the firewall removes it from its list of tracked connections, and the client sees the connection drop.

On SonicOS 7 the firewall-wide default is 15 minutes. Check the value on your own firewall, because it may have been changed and it varies between SonicOS versions. A long database query that sends nothing while the server works can pass that limit, so the firewall closes the connection before the result comes back.

CSE traffic reaches your internal network over WireGuard tunnels, which is the tunneling technology CSE uses between its Points of Presence and your firewall. The access rule that applies to this traffic is therefore the WireGuard to LAN rule. SonicOS creates and manages that rule itself, and it is not listed with your other access rules, so at present the timeout cannot be changed on that rule alone. Admin visibility and control over CSE-generated access rules is tracked as an open feature request.

Resolution Steps

Raise the firewall-wide default TCP connection timeout. This default applies to access rules that do not carry their own timeout value, which includes the rules SonicOS generates for CSE.

1. Log in to the SonicWall firewall that hosts the Connector.
2. Navigate to Network > Firewall > Flood Protection > TCP.
3. Set Default TCP Connection Timeout to a value above the longest request you need to support. On SonicOS 7 the field accepts 1 to 999 minutes.
4. Save the change.
5. Reconnect the Service Tunnel on a test device, run the long request again, and confirm that it completes.

Before you change this setting: it is firewall-wide. It applies to all access rules and all traffic through the firewall, not only to CSE traffic. A higher value means idle connections are held in the firewall's connection cache longer before the firewall reclaims them. SonicWall's guidance is that excessively long timeouts slow the reclamation of stale resources and, in extreme cases, can exhaust the connection cache. If your firewall already runs close to its maximum connection count, or is undersized for its current traffic, review that headroom first and raise the value only as far as the affected application needs.

Other Options

If you would rather not change a firewall-wide setting, the following options may help. Test either one before you rely on it.

• Keep the connection from going idle. Some client applications and database drivers can send TCP keepalives, which are small periodic messages that keep an otherwise idle connection active. Setting an interval shorter than the firewall's timeout can stop the connection from being treated as idle, with no firewall change. Support for this depends on the client and driver.
• Publish the resource through a different Connector type. The timeout described here comes from SonicOS access rules. A self-hosted Private Edge or a standalone Connector does not use the SonicOS WireGuard access rules, so this timeout may not apply. This has not been confirmed for this scenario, and other firewall rules may still apply to the traffic, so treat it as something to test rather than a known fix.

If long-running connections still drop after the timeout has been raised, collect the client-side logs and open a case at https://helpdesk.sonicwall.com.