* Ted Unangst <[email protected]> [2015-11-10 06:27]:
> Luke Small wrote:
> > I recently tested what would happen with a TCP connection in my kqueue
> > enabled client server software when the 5 hour window lapsed in pftop
> > for a local host connection, which is allowed in both directions in
> > the pf rules. It simply didn't allow the client and server to
> > communicate. The ESTABLISHED state went away as expected, but it
> > didn't signal a closed port to either the client(which was sitting on a
> > blocking read() call) or server. Even so,
> > shouldn't pf create a new state if the client signals to the server's
> > kqueue that there is an EOF event. The communication isn't dependent
> > upon a keep state in the pf rules, shouldn't it make a new state
> > entry? My OpenBSD box isn't connected to the internet, so I still have
> > it on 5.7, maybe that doesn't matter.
>
> No, when the pf state disappears, that's no different from cutting a
> connecting ethernet cable. Until a packet is sent, the TCP state of the
> endpoints will not know the connection is down. You can send keep alives if
> you want to detect this condition.
And to your second question: no, pf should not create a new state.
TCP states are only created by the initial packet (flags S/SA). If we
don't see the 3WHS we don't know about some of the connection properties,
i. e. window size; that can lead to problems. In fact, that was one of
the more common topics on the mailing lists before "flags S/SA" became default.
heck, the manpage (surprise :)) has nicer wording to explain that than
I ever could come up with:
flags ⟨a⟩ /⟨b⟩ | any
This rule only applies to TCP packets that have the flags ⟨a⟩ set
out of set ⟨b⟩. Flags not specified in ⟨b⟩ are ignored. For
stateful connections, the default is flags S/SA. To indicate
that flags should not be checked at all, specify flags any. The
flags are: (F)IN, (S)YN, (R)ST, (P)USH, (A)CK, (U)RG, (E)CE, and
C(W)R.
flags S/S Flag SYN is set. The other flags are ignored.
flags S/SA This is the default setting for stateful connections.
Out of SYN and ACK, exactly SYN may be set. SYN,
SYN+PSH, and SYN+RST match, but SYN+ACK, ACK, and
ACK+RST do not. This is more restrictive than the
previous example.
flags /SFRA
If the first set is not specified, it defaults to
none. All of SYN, FIN, RST, and ACK must be unset.
Because flags S/SA is applied by default (unless no state is
specified), only the initial SYN packet of a TCP handshake will
create a state for a TCP connection. It is possible to be less
restrictive, and allow state creation from intermediate (non-SYN)
packets, by specifying flags any. This will cause pf(4) to
synchronize to existing connections, for instance if one flushes
the state table. However, states created from such intermediate
packets may be missing connection details such as the TCP window
scaling factor. States which modify the packet flow, such as
those affected by af-to, modulate, nat-to, rdr-to, or synproxy
state options, or scrubbed with reassemble tcp, will also not be
recoverable from intermediate packets. Such connections will
stall and time out.
--
Henning Brauer, [email protected], [email protected]
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtual & Dedicated Servers, Root to Fully Managed
Henning Brauer Consulting, http://henningbrauer.com/
