Jon Simola wrote:
On 4/10/06, James Nachlin <[EMAIL PROTECTED]> wrote:
I'm having a strange situation where I'm getting back errors when
connecting to a web server (lighttpd) from IE, which I do not get from
firefox and I don't get connecting directly, not through the pf firewall.
To the client, this appears as slow connections or dropped connections.
Looking at the traffic with Ethereal, the main difference seems to be
the presence of tons of packets with the RST flag set.
This fits with IE's known TCP stupidity. IE can assume it's talking to
a IIS server and together they leave and/or assume TCP sessions that
are stil open past the point that PF would drop the state.
So, you're saying that IE is assuming that the connection through the
firewall is still open when it's not?
If you're currently doing "block drop" you could try block return,
which should get things working a bit quicker. Alternately, the
pf.conf would also help a lot.
Currently my pf.conf doesn't specify any block rules in the filter
section. It just looks like:
pass on $real_lan proto carp keep state
pass on $real_wan proto carp keep state
pass on $sync_if proto pfsync
"block return" would send rst immediately, but that would still mean a
lot of the requests would be unsuccessful. Or do I misunderstand?
Also, not clear on what I'd specify to block. Not all packets from IE,
so what's the rule. That is, how do I identify a connection to block.
The other question is why does IE think it's talking to IIS?
Considering that it's still the most popular browser, everyone using
this firewall can't be having this problem.
At the risk of providing too much information, I'm attaching cap files.
Hope this list doesn't strip attachments.
Umm, 350K of attachments to a mailing list... I'm certainly glad I'm
not hosting this mailing list. Anything over about 20K I'd suggest
posting on an ftp/htp server somewhere.
OK. Chastened, I out them here: http://nachlin.com/pf-ie-captures.tar.gz
Thanks very much for your help.
--
Jim Nachlin
Motionbox Systems Administrator
