[Karl O. Pinc] wrote:
[...]
AFAIK, when a client violates the 2MSL rule should I not see the
initial
SYN blocked by PF (since it would create a state mismatch, hence a BAD
state log entry) ?
Yes. (I'm not clear about what I'm looking at when I look at
bad state log entries. I couldn't find documentation
and decided not to turn my brain on.)
Daniel Hartmeier has published some nice articles regarding PF on
undeadly.org. One of them is about debugging PF and has a very nice
explanation of BAD state errors - definitly worth a read.
As a side note, have you tried scaling down the tcp.closed parameter
for
PF ? I have seen numerous references that this might help against 2MSL
violations ...
Duh. That's exactly the sort of thing I need. I
can't believe I've not explored that option. Thanks!
Glad I could help.
I'll need to examine my traffic to see whether
I need to mess with tcp.closed, interval, or tcp.finwait.
(I know in one case it's RST packets that are the trouble
so tcp.closed/interval would do the trick for that.)
What version of OpenBSD are you running? I remember something in the
commit logs regarding finwait and PF that might relate to your problem.
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf.c?rev=1.559&content-type=text/x-cvsweb-markup
As a side note, reading the commit logs is VERY useful when you depend
on OpenBSD or releated technology such as PF. It has saved my butt on
numerous occasions and it is worth spending the 5-10 minutes every other
day.
What am I missing? Based on google searching
RSTs (fixed with tcp.closed)
more likely associated with 2MSL violations than
FINs (tcp.finwait). Why is this? Do perverse
TCP stack programmers prefer RSTs?
I've not thought this through, but it seems
to me that there are two general cases when
RSTs are received: when the receiving system
returns to LISTEN (receiving system in
un-synchronized state, RST received while in
SYN-SENT or SYN-RECEIVED), and otherwise.
If the 2MSL violators are violating 2MSL
only for those connections that never reached
the ESTABLISHED state (I _think_ I remember this
from my tcpdump analysis) then would it make
sense for pf to have a separate timeout for
these sorts of resets? A tcp.aborted timeout
for when RSTs are received before the tcp.established
state is reached?
Karl <[EMAIL PROTECTED]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
P.S.
I also don't get the tcp.opening state. As
pf.conf(5) is written I can't tell what sends
pf out of tcp.first into tcp.opening.
After reading the udp.single entry I thought
it was something like:
"tcp.opening The state if the
source host sends more than one packet before
the destination host ever sends a packet."
But that does not make sense if pf is always supposed to
be in one of the listed tcp states. So, I suspect
it's something like:
"tcp.opening The state before the destination host
sends it's first packet after the SYN/ACK tcp handshake
packet."
Or alternately:
"tcp.opening The state before the destination host
sends it's first packet with a data payload."
Why wouldn't it be:
"tcp.opening The state after the first packet but
before the 3-way tcp handshake has been completed."
Perhaps not the last because pf does not know the
handshake got through until the destination sends
it's first packet with a data payload?
--
Med venlig hilsen / Best Regards
Henrik Johansen
[EMAIL PROTECTED]
