Jeff Ross wrote:
I know, "Who cares?" or "Great!" is my own response but my users have
other wishes that include msn.com and this one has me stumped.
I had a more complex pf rule set but now I'm using a simple rule set
based almost entirely on the one from the PF FAQ:
ext_if="em0" # External Public Interface
int_if="bge0" # Internal LAN Interface
tcp_services = "{ 22, 113 }"
udp_services = "{ domain, ntp }"
icmp_types = "{ echoreq, unreach }"
table <zombies> persist
set block-policy return
set loginterface $ext_if
set skip on { lo, tun }
scrub in no-df fragment reassemble
nat on $ext_if from !($ext_if) -> ($ext_if:0)
nat-anchor "ftp-proxy/*"
rdr-anchor "ftp-proxy/*"
rdr on $int_if proto tcp from any to any port ftp -> 127.0.0.1 port 8021
block in log
pass out log keep state
anchor "ftp-proxy/*"
antispoof log quick for { lo $int_if }
block in log quick on $ext_if from <zombies> to any
pass in log quick on $ext_if proto tcp from any to ($ext_if) port ssh \
keep state (max-src-conn-rate 3/30, overload <zombies> flush global)
pass in log on $ext_if inet proto tcp from any to ($ext_if) port \
$tcp_services keep state
pass in log on $ext_if inet proto udp from any to ($ext_if) port \
$udp_services keep state
pass in log inet proto icmp all icmp-type $icmp_types keep state
pass in log quick on $int_if
I added all of the log lines so I could hopefully see what's going awry.
From the firewall itself, when I use lynx to try
http://www.msn.com
I get asked to accept about 5 cookies, which I accept and then a "HTTP
request sent; waiting for response." and that's it.
Watching pflog0 I see this:
May 20 09:59:58.339833 rule 1/(match) pass out on em0: 192.168.0.2.23294
> 205.128.93.51.53:[|domain]
May 20 09:59:58.548598 rule 1/(match) pass out on em0: 192.168.0.2.4281
> 207.68.173.76.80: [|tcp] (DF)
I don't ever see a return packet, and nothing is ever blocked as seen
from pflog0.
Thinking it is a scrub issue, I've tried scrub in, scrub in no-df, and
the combination listed above, with no difference.
Hopefully someone can provide me a cluestick before my msn deprived
users do something ugly--to me!
Thanks,
Jeff
I turned the debug level up to "loud" and found this in the log:
2008-05-20 12:24:38.202348500 pf_normalize_tcp_stateful: Broken RFC1323
stack did not timestamp data packet. Disabled PAWS security.
2008-05-20 12:24:38.202966500 TCP 192.168.0.2:32177 192.168.0.2:32177
207.46.19.254:80 [lo=2462224797 high=2462290110 win=32768 modulator=0
wscale=3] [lo=3824465452 high=3824727596 win=8192 modulator=0 wscale=3]
4:4 FA
Google found a thread from 2004 about Apple's software update site but,
(and this thread quickly got over my head so I might not be
understanding it correctly) there traffic was being passed back and
forth and I didn't think I was seeing that.
So I did a tcpdump on the external interface. The exchange between lynx
and msn is 33k long, so I put a file up on
http://www.openvistas.net/pf_log.txt
While I was writing this I see I got a response about checking the MTU.
Hopefully this did that.
Thanks,
Jeff
(barricaded myself in the server room, but I think they are getting out
the heavy tools to take out the door...)
