getting pristine packets off a pf box, for ids (of sorts)

[b bee <bumble_(_dot_)_bee_(_at_)_xs4all_(_dot_)_nl>]

hello list,

just a quick intro. i have a net4501 (-current a few weeks ago) as the 
brains in my home network. sis0 connects to a switch for my lan, sis2 is 
crossed to an adsl modem, wi0 passes wireless ipsec to the ether. sis1 is 
crossed to tlp0 on a cobalt qube2 running netbsd -current acting as my 
internet server.
it's a pretty sweet setup, as all of the above even under full load use 
less power than a weak lightbulb, and i get 2 bsd hosts to play with. the 
whole thing is policed by a fairly strict ~300 rule default deny ruleset on 
the 4501.
the qube is untrusted in every way (being the only host that accepts 
connections from everyone on the net), it can't initiate outgoing 
connections at all, except to one ntp and two dns servers on the internet.
the one major thing i haven't set up yet is logging of blocked packets. i 
figure it may be worth it to run an ids to process these packets.

as i understand it, the common way of using an ids is either in front of or 
behind a firewall, reading _all_ the traffic, but that's not what i'm after 
since compromise of that box would be too sensetive, and i don't really 
think it's necessary since i control all the inside hosts.
the logical place to process the packets would be the qube, since it's 
already untrusted and the ids would only be processing part of the traffic. 
specifically, the unsolicited, non-private traffic, packets that came 
from "outside": things that were denied inbound on gif0 (ipv6 tunnel), sis2 
("$ext_if") and wi0. and possibly also "normal" connections to the services 
running on the qube.

if i've made any conceptual errors in the above, please correct me since 
it's my first time even considering setting up an ids.
i've been reading up on docs, manpages and i've come up with some ideas:

adding a "block in on { gif0, sis2, wi0 } all route-to sis1" just below the 
default deny rule, which would make all matched packets that aren't 
subsequently passed go to the qube.
the first problem i see with this is that someone could send packets to wi0 
with the internal address of the qube as the destination, wich would then 
be blocked at wi0 and get routed to the qube, where the qube would have no 
way of knowing if it was a legit request and would thus send a reply.
the solution would be setting up another connection between the qube and 
the 4501 just for ids, but my 4501 is out of spare interfaces :(
i could try setting up a vlan between the qube and the 4501, but i know 
even less about them then about ids'en.. is a vlan even possible between 
two hosts connected by a crosscable? and does the sis driver in openbsd and 
the tlp driver in netbsd support trunking? (are there issues with >1500b 
packets?) perhaps some other type of tunnel would be better?

the next and more difficult issue would be making sure that these packets 
are delivered to the ids untouched.. i scrub all incoming packets, 
scrubbing comes before filtering, but i obviously don't want to route the 
scrubbed packets to the ids.
basically you have to scrub to get accurate firewalling, route-to works on 
firewall rules, and you want to route unscrubbed packets. i don't see a way 
out of this. anyone?

finally, there would be no way for the ids to tell what interface (gif0, 
sis2 or wi0) the packet came from, while packets coming in on wi0 would 
obviously require a different response (from me) then packets coming from 
the internet.. don't see a way to handle this, either.

now i remember why i put this off.. i can't think of a way to do it right! 
"kiss". make the qube an nfs server, run pflogd on the 4501 with its 
logfile on the nfs mount. run a cronjob on the qube to feed the data to the 
ids. i'd really like this to be as realtime as possible.. but atleast with 
an nfs mount backlogs would not be lost should the firewall go down (this 
is in contrast with the method suggested in the pf faq).
problem: can openbsd's tcpdump file format even be read by "normal" 
tcpdump-supporting wares? aren't there lots of changes (adding interface 
names, support for pf structures et al) that make the binary format 
incompatible with other os'en?
this would still not solve the "which interface" issue.. would it even get 
around the scrub problem? does pflog see the packets scrubbed if there is a 
scrub rule that would scrub them in the pf ruleset?
plus aren't there huge security implications to mounting an nfs share from 
an untrusted host?

thinking about it, maybe i'm trying to turn an ids (or pf?) into something 
it's not.. but all the same, i'd like to hear what other people do to get 
their packets off of their pf firewalls for analysis, especially if that 
analysis is being done on untrusted boxes and/or if the firewalls are 
multihomed.

thanks for reading, and major kudos to the devs for making this great os.

bumblebee
bumble_(_dot_)_bee_(_at_)_xs4all_(_dot_)_nl