Since the LTM is a full-proxy architecture, the VS/Virtual-IP (depending on the VS-type) are generally always reachable from a TCP/IP perspective regardless of pool member availability. A great resource is SOL8082: Overview of TCP connection setup for BIG-IP LTM virtual server types. This behavior makes sense if you think about F5 features - for example, you can select a pool based on a URI value, so before the F5 knows which pool to use, it must parse client data and needs the client-side to be established.
If a pool member goes down while there are live connections to that pool member, LTM will act based on the pool's "action on service down" configuration SOL15095: Overview of the Action On Service Down feature. By default, this is "none", so the LTM will let the connection be handled by the protocol in play. If you want the LTM to send TCP RST to users when their pool member fails, this can be set to "reject".
There are TCP idle timeouts spread across different configuration items, but if this is a standard VS, then those connections will probably timed out by the assigned TCP profile SOL7606: Overview of BIG-IP idle session time-outs. In your case, if "action on service down" is "none", it will let TCP time out on its own, which on many stateful network devices is 300 seconds. You can tweak the timeout value on the LTM by creating and assigning a custom client-side TCP profile to the virtual server.