Roelof JT Jonkman
roel at ...47...
Mon Mar 11 15:11:03 EST 2002
This is a somwhat common problem. I'll try my best to explain this somewhat.
(Marty and other have explained this well in the past)
Whenever you see the alert gets generated, snort has to fabricate two
packets with the RST flag set, one for the server, and one for the client.
The crucial piece is that the sequence number matches that of the connection.
If the sequence number is off, it simply gets discarded. It obviously takes
some time to fabricate these packets. In the mean time the server is also
working on a response to the client. The gotcha is when you do this
on a LAN, the delays are so low, that the server is likely to get back to
the client before snort/flexresp is able to generate the RST packets, and
the connection will have advanced beyond the sequence number that the
RST packets have, and swat, they get ignored. However on a WAN connection
where the delays are more than ~2ms, the RST packets will still have
a sequence number that matches the current sequence number of the connection,
and hence will convince both ends that the connection has ended.
This is sort of a terse background behind flexible response, and why
it works in some (WAN) cases, and not in others (LAN) This is
by no means complete, rather it reflects upon my understanding
Hope this helps.
More information about the Snort-users