Re: Public web server behind a PF bridge, crap clients
On Fri, Dec 06, 2002 at 04:10:54PM -0800, Stephen Gutknecht (OBSD-PF) wrote: Are the default timeout values documented somewhere. If not, you post them. The man pages for pf.conf show how to set them, but doesn't seem to indicate the defaults. pfctl -s timeouts shows the ones you're currently using. On similar note: does set optimization influence the timeouts, or is it merely relaxing the state matching tolerance? set optimization affects exactly the timeouts, yes. -- Henning Brauer, BS Web Services, http://bsws.de [EMAIL PROTECTED] - [EMAIL PROTECTED] Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
RE: Public web server behind a PF bridge, crap clients
I'm going to revisit this topic... as a comment from eWeek's OpenHack 4 caught my attention. On the following page, in the left column... http://www.eweek.com/image_popup/0,3662,s=25546iid=18512,00.asp Regarding OpenBSD 3.2 PF: *** We did notice a few problems where pf rules we wrote using the firewall's keep state option would incorrectly block packets returned as a result of an incoming connection *** That is a pretty good description of what I thought we observed that prompted me to start this thread. In our case, we suspected the problem seemed to favor some users over others. So I had assumed it was the browser / TCPIP stack thee web browser was using? Maybe the common thread is: Windows 2000 IIS behind the firewall. When we used keep state on our out rules, we would see port 80 packets originating from our IIS server were sometimes showing in the log as dropped. But we could not figure out why some people have this happen and not others. At the time we were busy and had to resort to pass out all on port 80 style rules to get around the problem. At this point I'm still at the discussion stage. We are in the process of updating our PF bridge firewalls from 3.1-STABLE to 3.2-STABLE right now, so I don't have logs to show of this. But I am interested if anyone else can confirm this type of problem so we can help focus where to look. We are using Intel ISP1100 servers for our PF firewalls, using the onboard fxp adapters for the bridge. These seem to be on the good stuff in terms of recommended OpenBSD hardware. After we get the firewall on 3.2-stable, I will revert back to using keep state or modulate state instead of our pass out all and see what we find. Again, anyone else in same boat? Thanks. Stephen Gutknecht -Original Message- From: Stephen Gutknecht (OBSD-PF) [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 23, 2002 3:02 AM To: [EMAIL PROTECTED] Subject: Public web server behind a PF bridge, crap clients [snip] We have a OpenBSD 3.1 firewall protecting a public web site. We are using good hardware (Intel ISP1100 1u server / Intel Pro Ethernet adapters) by all accounts, etc. At times, the only way we have been able to get a particular user in is to make a special pass all on port 80 rule for their IP. My question: How well does stateful inspection work with crappy clients? Windows 95 users? Windows for Workgroups 3.11 TCP/IP stack? Macintosh 8.x tcp/ip stacks, etc? Are there cases where using stateful inspection, and not using allow all port 80 is preventing _users on broken old systems_ from accessing a public site? On one had, you want your users to reach your site - but you also want to be secure (prevent spoofing, etc). I wondered if people knew examples of some broken client configurations that are known to cause problems.
Re: Public web server behind a PF bridge, crap clients
On Fri, Dec 06, 2002 at 12:37:32PM -0800, Stephen Gutknecht (OBSD-PF) wrote: *** We did notice a few problems where pf rules we wrote using the firewall's keep state option would incorrectly block packets returned as a result of an incoming connection *** That is a pretty good description of what I thought we observed that prompted me to start this thread. In our case, we suspected the problem seemed to favor some users over others. So I had assumed it was the browser / TCPIP stack thee web browser was using? To investigate this kind of problem, I'll need more specific data. A tcpdump of a blocked packet (tcpdump -nvvvepi pflog0) and the state entry (pfctl -vss) you expect the packet to match. Also, enable debug logging (pfctl -x m) and watch for 'bad state' messages in /var/log/messages. I pass several thousand http connections statefully each day, and I get a couple of blocked packets daily. In every case, either the state has timed out already or the peer was re-using a port with a new initial sequence number before the old state has timed out. You can compensate both by adjusting the tcp state timeout values. A certain percentage of real traffic will always be dropped, there's just too many weird stacks or browsers out there that don't honor 2MSL. If you can reliably reproduce connection drops or stalls, the tcpdump and state information will help explain what is going on. Daniel
RE: Public web server behind a PF bridge, crap clients
Correction to last post... I wrote: When we used keep state on our out rules, we would see port 80 packets originating from our IIS server were sometimes showing in the log as dropped. I meant to say: When we used keep state on our *in* rules (both interfaces of bridge) - we would sometimes see the return results being blocked from our servers (port 80). Stephen Gutknecht
RE: Public web server behind a PF bridge, crap clients
Hi Daniel, Are the default timeout values documented somewhere. If not, you post them. The man pages for pf.conf show how to set them, but doesn't seem to indicate the defaults. On similar note: does set optimization influence the timeouts, or is it merely relaxing the state matching tolerance? Thanks. Stephen -Original Message- From: Daniel Hartmeier [mailto:[EMAIL PROTECTED]] Sent: Friday, December 06, 2002 1:08 PM Subject: Re: Public web server behind a PF bridge, crap clients [snip] In every case, either the state has timed out already or the peer was re-using a port with a new initial sequence number before the old state has timed out. You can compensate both by adjusting the tcp state timeout values.
