FreeBSD TCP Session Termination with sockstat and tcpdrop
Identify a live TCP tuple before terminating only that session with tcpdrop, while accounting for IPv4/IPv6 selection, stale observations, and reconnect behavior.
Sometimes the right incident response is to terminate one stuck or abusive TCP session without restarting its owning service. FreeBSD provides sockstat to inspect current socket endpoints and tcpdrop to request that one connection be dropped. The safe unit is the complete four-part tuple: local address, local port, foreign address, and foreign port, not a process name or a listening port by itself.
This workflow follows the FreeBSD 15.1 manual pages. Confirm the host release and read its installed sockstat(1) and tcpdrop(8) pages before using the commands on an older or vendor-modified system. These tools operate on TCP connections; they do not block a peer from reconnecting, stop a listener, or replace an application-level recovery plan.
Find the exact connected socket
Start with a narrow inventory. -c selects connected sockets, -P tcp selects TCP, -4 or -6 restricts the address family, and -p matches a port on either the local or foreign side. A port filter is therefore a shortlist, not proof that the displayed endpoint is the one you intended to act on.
sockstat -4 -c -P tcp -p 8443
sockstat -6 -c -P tcp -p 8443
Read the USER, COMMAND, PID, FD, LOCAL ADDRESS, and FOREIGN ADDRESS columns together. Check which side owns port 8443, confirm the remote peer and address family, and correlate the process with your incident evidence. If a socket is held through more than one file descriptor, sockstat can show it more than once; the tuple is still the input to tcpdrop.
The inventory is a snapshot. Between inspection and termination, an application may close the connection, reconnect, or reuse the same tuple. Re-run the narrow inspection immediately before acting, and use a change or incident record when the session belongs to a production workload. tcpdrop does not accept a PID as an identity check.
Drop one tuple, not a class of connections
The positional form is:
tcpdrop local-address local-port foreign-address foreign-port
For example, if the current sockstat row (not this documentation placeholder) shows a service at 192.0.2.20:8443 connected to 198.51.100.27:51372, the exact-tuple command is:
tcpdrop 192.0.2.20 8443 198.51.100.27 51372
Those addresses are reserved for examples. Replace all four values with the tuple you just verified. IPv6 addresses are also accepted; pass each address and port as its own shell argument so the colons remain part of the address token.
Do not treat tcpdrop -l as a dry run for this positional form. The manual only documents -l alongside the bulk selectors -a, -C, -S, or -s, where it prints matching invocations. In particular, do not pipe generated invocations into a shell: a reviewable list is not a substitute for checking each connection’s impact.
After the command, inspect the same port again and correlate application logs or health checks. A successful exit status means the utility completed successfully; it does not prove that the client stayed disconnected, that the service recovered, or that a later reconnect is the same session. If the same peer immediately reconnects, investigate the application, client retry policy, or a narrowly scoped firewall policy rather than repeating a tuple drop indefinitely.
Bound the operational impact
Dropping an established TCP connection interrupts the application exchange carried by that connection. The remote application may report a reset, retry, or surface an error to its user. Prefer this operation when the tuple is unambiguous and the expected interruption is understood; for a stateful service, coordinate with its owner and verify the transaction or request outcome independently.
Avoid the tempting broad selectors tcpdrop -a or state-based drops during routine triage. They can affect unrelated clients on the host. If the issue is a listener, a process leak, a routing failure, or repeated hostile traffic, use the matching service, process, network, or firewall diagnostic instead. tcpdrop is a connection-level intervention, not a general-purpose containment boundary.
Related:
- FreeBSD sockstat Operations: Attribute Listeners, Connections, and Unix Sockets
- Fixing pf State Table Exhaustion on FreeBSD
Sources: