[Karl O. Pinc] wrote:
On 12/14/2007 02:17:22 AM, Henrik Johansen wrote:
Hi list,
We are experiencing a steady flow of BAD state error messages that I
cannot explain.
I continue to have problems with (Microsoft) hosts that
violate the 2MSL TCP rule (STD7, RFC793, page 27
"Knowing When to Keep Quiet"). I strongly suspect
that MS is setting the MSL to 1 minute rather than the
2 minutes of the standard. (I don't know about Vista,
which supposedly has a new TCP stack.) This causes
pf to see state errors.
It would, *urp*, be nice if pf had a way to
specify the MSL in the scrub directive to
work around the brokenness. I've had to replace
a lot of stateful rules with stateless filtering.
Not only is it ugly and less secure that way, but
diagnosing the problem is a real pain in the butt.
I can't say if this is your problem. I ran the
following script against your log after I did a
random check and saw a 1 minute interval during
which a particular sourceip/sourceport/destip/destport
was failing. The script (kinda) does a frequency analysis
on how long the bad state persists on any particular
connection. The results tell me nothing. Maybe
somebody else will have better luck.
[...]
Thank you for your input.
I don't think that this is my problem however. Most BAD state messages
are generated by ACK packets, not SYN packets.
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) ?
Out of the 2936 BAD state lines in my log snippet, 2617 are ACK/PACK and
only 227 are SYN/SYN ACK packets.
Furthermore, it looks like most of the blocked packets are return data
from the inside of our network (dir=our,rev on 2552 out of 2617 blocked
ACK packets).
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 ...
I am still lost on this one ... any help would be greatly appriciated.
--
Med venlig hilsen / Best Regards
Henrik Johansen
[EMAIL PROTECTED]