[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]

Reply via email to