So snort was running and I could use my little C test divert program also to see I was passing packets back and forth thru divert. I never got a snort alert though even though traffic was passing to and from client. So after noticing the snort exit output that showed "bad chk sum: 100.000%" I used the snort -k none option and now snort is alerting also. Just an FYI in case this is at all related to your work. I have run snort a lot in the past but never on OpenBSD so I don't know if that's normal or not.
Justin -----Original Message----- From: Justin Mayes Sent: Thursday, March 07, 2013 4:02 PM To: 'Lawrence Teo' Cc: misc@openbsd.org Subject: RE: snort inline This works. Thank you very much. I'll let you know if I run into any issues but I am able to run snort inline now along with NAT. Justin -----Original Message----- From: Lawrence Teo [mailto:l...@openbsd.org] Sent: Wednesday, March 06, 2013 8:55 AM To: Justin Mayes Cc: misc@openbsd.org Subject: Re: snort inline Hi Justin, Not sure if you still need to use divert-packet with NAT, but if you do, could you please try the diff at http://marc.info/?l=openbsd-tech&m=136245826921904&w=2 to see if it works for you? The easiest way to get the diff is: ftp -o divert-checksum.diff \ 'http://marc.info/?l=openbsd-tech&m=136245826921904&q=raw' If you do try it, please let me know if it works for you. Thanks, Lawrence On Wed, Dec 19, 2012 at 03:09:47PM -0600, Justin Mayes wrote: > Another update in case there is any interest in running divert-packet > along with NATing. I ditched snort and wrote a little divert program > based on the man page to test easier. I can now see that with nat as > well as divert-packet on egress rule on external interface the packet > will get NATed and go out. A reply will come back to external > interface and then get diverted again and never make it to the client. > I am as sure as I can be at this point that you cannot divert packets from a NATed client. > > Justin > > -----Original Message----- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Justin > Sent: Sunday, November 25, 2012 4:37 PM > To: misc@openbsd.org > Subject: Re: snort inline > > Quick update. It seems to be a nat problem. If I just test by pinging > either the 192.168.1.32 interface or the 192.168.0.13 interface it > works fine and snort sees the packets. Its only when the traffic is NATed that it fails. > > > > -----Original Message----- > From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf > Of Justin > Sent: Saturday, November 24, 2012 2:21 PM > To: misc@openbsd.org > Subject: snort inline > > Anyone running snort 2.9.3.1p0 in inline / IPS mode with 5.2 cuurent? > From what I read it's possible with pf divert functionality. > > This is what I'm doing for testing in pf using simple ping > > > > Gateway info > > internal interface fxp0 - 192.168.1.32 > > external interface bce0 - 192.168.0.13 > > > > Running snort via this cmd line > > snort --daq-dir /usr/local/lib/daq -Q --daq ipfw -c > /etc/snort/snort.conf -v > > > > Internal interface is in the skip list hence no active rules for it > > Pfctl -sr > > pass out on bce0 all flags S/SA scrub (reassemble tcp) nat-to (bce0:0) > > pass in on bce0 inet all flags S/SA scrub (reassemble tcp) > > > > This works as expected, I can ping 8.8.8.8 and since no diverting is > active snort sees nothing > > I change rules to this to start diverting to snort > > Pfctl -sr > > pass out on bce0 all flags S/SA scrub (reassemble tcp) divert-packet > port > 8000 nat-to (bce0:0) > > pass in on bce0 inet all flags S/SA scrub (reassemble tcp) > > > > Now internal interface sees outgoing ping > > tcpdump -n -i fxp0 -n host 8.8.8.8 > > 192.168.1.32 > 8.8.8.8: icmp: request: > > > > External interface shows it going out and coming back > > 192.168.0.13 > 8.8.8.8: icmp: request: > > 8.8.8.8 > 192.168.0.13: icmp: reply: > > > > Snort sees it twice, external interface first > > 192.168.0.13 -> 8.8.8.8 > > ICMP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:84 DF > > Type:8 Code:0 ID:64870 Seq:2 ECHO > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > =+=+ > > > > 8.8.8.8 -> 192.168.1.32 > > ICMP TTL:48 TOS:0x20 ID:64655 IpLen:20 DgmLen:84 > > Type:0 Code:0 ID:52297 Seq:2 ECHO REPLY > > =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > =+=+ > > > > Client @ 192.168.1.32 never sees reply. Any comments or suggestions? > > > > Justin [demime 1.01d removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
