I found out a solution, although I have no idea why it works.
Since I just couldn't understand what was going on, I started crawling
around the packet traversal code specific to snort_inline and found that
it's really just a simple abstraction layer to pulling data off of
libipq.
So I copy & pasted the test code in libipq manpage, compiled and ran in
place of snort_inline with all packets set to NF_ACCEPT.
Well, it looked like there was nothing wrong with kernel or libipq or
iptables since using the same test FORWARD iptables rule, the data
packets didn't disappear.
After a brief look at the snort_inline portion of snort, it wasn't doing
anything too different than the code in the manpage so I started to
question snort.
I was running snort_inline with -i set to eth0, switching it back and
forth between eth0 and eth1 based on which direction I wanted the
snort_inline to analyze.
But, when I removed that piece altogether, it all began to work.
I suppose libipq does not care which interface the target QUEUE comes
from, as long as it's in the QUEUE the requestor can get access to it.
Perhaps the -i flag has more relevance just for 'snort' when it is
running the signature analysis of the data, and somehow sets the status
to be 'silently drop' by default when *some* internal state doesn't
match up? even if there is NO rule for it to take such action?
I have no idea... but w/o it everything seems to be happy.
-Peter
|
