How are TCP connections torn down when a gateway is involved?

We use Tailscale happily at work to connect from developer machines to VMs to our deployment environments in GCP, via a gateway node in each environment.

The outage yesterday in GCP networking left me with some questions on the exact mechanics how connections through a Tailscale node work, and I was hoping someone can help me answer these. In particular: how does a Tailscale gateway manage outgoing connections that are initiated from an incoming connection from another Tailscale node?

If I have a “TCP connection” from my local machine to a VM in a subnet bridged with the gateway’s VM, let’s call the connection from my local machine to the gateway (A) and the connection from the gateway to the remote VM (B). As I understand it, Tailscale turns my TCP packets routed to the remote VM to UDP packets that are sent to the gateway, which should reassemble them to transfer them over a TCP connection from the gateway to the remote VM. That leads me to wonder how timeouts in (A) might affect the (B) connection. When/how does the gateway decide to drop the connection to the remote VM?

Concretely, I was using a local binary that connected to a PostgreSQL instance running in GCP, and it seemed like Postgres locks were not being cleaned up long after the client process was already dead. I’m wondering what role Tailscale might play in such a scenario.

My local machine is an M1 Mac using the latest App Store version of Tailscale. On the gateway we install Tailscale using the process described in Setting up Tailscale on Debian Bullseye · Tailscale.