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?

    Thanks.



  • 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.

    :o



  • 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.


  • Banned

    
    $ 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.