Date: Fri, 6 Jul 2007 21:40:17 +0100 From: "Greg Hennessy" <Greg.Hennessy@nviz.net> To: "'Pat Maddox'" <pergesu@gmail.com> Cc: freebsd-pf@freebsd.org Subject: RE: Losing connections/performance with PF turned on Message-ID: <000d01c7c00d$dcb6e4f0$9624aed0$@Hennessy@nviz.net> In-Reply-To: <810a540e0707051255w269b7362g576bce5695ba76ab@mail.gmail.com> References: <810a540e0707050222s55a62641je0138e931832e86@mail.gmail.com> <-7932512891363606358@unknownmsgid> <810a540e0707051255w269b7362g576bce5695ba76ab@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > We're doing some stress testing on our server, > > > > CPU ? Memory ? > > Xeon 3060 (dual core @ 2.4 Ghz) > 2 gigs of ram That's got more than enough grunt, intel gig-e nics, a good recipe for PF success. > I'm not very familiar with pf at this point. It won't take you long, it's very intuitive and more importantly easy to work on after spending time away from a policy. > Here's a snippet of the log: > > pat@~: sudo tcpdump -n -e -ttt -r /var/log/pflog | grep CLIENT > reading from file /var/log/pflog, link-type PFLOG (OpenBSD pflog file) > 281. 491774 rule 2/0(match): block in on em0: CLIENT.56441 > > SERVER.80: . ack 3842266997 win 5080 <nop,nop,timestamp 995763116 > 242815600> > 000117 rule 2/0(match): block in on em0: CLIENT.56456 > SERVER.80: P > 3759758688:3759758883(195) ack 769179073 win 1460 <nop,nop,timestamp > 995763116 242815600> > 000007 rule 2/0(match): block in on em0: CLIENT.56442 > SERVER.80: . > ack 2278771587 win 5804 <nop,nop,timestamp 995763116 242815600> > 000005 rule 2/0(match): block in on em0: CLIENT.56442 > SERVER.80: F > 0:0(0) ack 628 win 5804 <nop,nop,timestamp 995763116 242815600> > 000111 rule 2/0(match): block in on em0: CLIENT.56437 > SERVER.80: . > ack 21684384 win 2184 <nop,nop,timestamp 995763116 242815601> Hmmm, rule number two, it's not the default block which is catching these. The default block would match as rule 0/0. What's rule 2 as outputted by pfctl -vvsr ? If I am reading your policy correctly, that's the bruteforce block. Which should only match against SSH not 80/tcp traffic. I would also replace # --- LOOPBACK pass quick on lo0 all with set skip on lo0 > > I reran the benchmarks and monitored the # of entries, we hit 10k > pretty quickly. Kept upping it until we got to 35k which is where we > stopped seeing any returns. We still dropped some connections (99.6% > of requests came back successfully), and the throughput was 3.4 Mbp as > opposed to the 9.8 Mbps we get with the firewall off. Can you repeat the test with scrub commented out ? I've seen scrub cause about a 10-15% hit on throughput, but that was ~800meg/sec versus > 900 meg/sec though multiple em using iperf on a single 2.4 ghz opteron running 6.0. > I'll be doing a lot more testing over the next few days, so I'll have > better info in a couple days...but if you can shed any light on this > I'd really appreciate it. Are the drop logs still matching the same entry after increasing the size of the state table ? As Max has said previously, you could well be hitting a 2MSL issue with the benchmark hardware. Greg > > Pat > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000d01c7c00d$dcb6e4f0$9624aed0$>