Connections remain in ESTABLISHED state
I have this strange issue where connections remain in ESTABLISHED state even though the computers that started those connections are already turned off.
For example, I have a machine with IP 192.168.10.91 in my 192.168.10.0/24 network. If I open pftop, I can see connections from and to 192.168.10.91 in ESTABLISHED state even though the machine has been turned off and the DHCP lease is already not showing up on menu "Status ->DHCP Leases".
How is this possible, since there is no traffic to maintain the activity on the connection, given the computer is turned off.
Is there a reasonable explanation behind this strange behaviour?
chpalmer last edited by
Im too having this phenomenon.
2.2.3 full install i386. I left my office the day before and noticed when I logged in that I still had states from my tablet which is sitting in front of me 65 miles away.
I could not seem to kill the states until I rebooted the box.
Ignoring chpalmer's post that indicates a possible issue, the fact that a computer was turned off has no bearing on why a connection is still established. The ONLY way a connection gets torn down is via a FIN exchange or a RST packet. If a connection was made, and the computer got turned off, then the FIN exchange never happens and according to the firewall, the connection is still open.
Of course there are some safe guards, like if the other side was expecting the turned off computer to respond, it would send some packets and eventually timeout because of no ACK and forcefully close the connection itself. If both computers were to be shutoff without any exchange of FINs, then you're pretty much guaranteed to not have the connection close until the establish timeout of 24 hours from the last packet elapses.
$ pfctl -st tcp.first 3600s tcp.opening 900s tcp.established 432000s tcp.closing 3600s tcp.finwait 600s tcp.closed 180s tcp.tsdiff 60s udp.first 300s udp.single 150s udp.multiple 900s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 118200 states adaptive.end 236400 states src.track 0s
This can be modified in System - Advanced - Firewall / NAT - State Timeouts in 2.2.x
Thanks both to Harvy66 and doktornotor.
I will check again to see if they do expire after 24 hours. If I remember correctly, I think I may have seen several of those connections that never time out, not even after 24 hours, but then again I might be wrong.