> # filter rules
> block log all
> block in log quick proto tcp from <spammers> to any port smtp
> block in log quick proto tcp from <sshscan> to any port ssh
> block in log quick proto tcp from <webspam> to any port http
>
> pass quick on lo0 all
Change this to
set skip on lo0
>
> block drop in log quick on $ext_if from $priv_nets to any
> block drop out log quick on $ext_if from any to $priv_nets
Superfluous, a default block policy should catch these.
> pass in on $ext_if inet proto tcp from any to ($ext_if) port
> $tcp_services flags S/SA keep state
> pass in on $ext_if inet proto udp from any to ($ext_if) port
> $udp_services keep state
I tend to avoid using 'any' as a source, use !<LAN-Subnets> instead.
> > and trawling the logs for drops around the
> > same time as the transfers are underway would be useful.
>
> Absolutely nothing interesting out of `tcpdump -n -e -ttt -i pflog0`
> Only a bunch of blocks for rule "0":
You need to enable logging on the pass rules to identify which rule number
the throughput test traffic is matching against.
Then use pfctl -vsr to identify the precise one.
Looks like someone has compiled out inet6.
> 000000 rule 0/0(match): block in on fxp0: 82.235.245.158 >
> 82.235.12.223: [|tcp]
You need to increase the snap size. Change the tcpdump on pflog0 whilst
testing to
tcpdump -s 160 -l -e -tttt -i pflog0
This will give you far more meaningful firewall logs to identify potential
out of state drops.
Greg
>
>
> I've found this in /var/log/debug.log:
>
> ../..
> Aug 1 14:00:01 boleskine pflogd[410]: [priv]: msg PRIV_OPEN_LOG
> received
> Aug 1 16:00:02 boleskine pflogd[410]: [priv]: msg PRIV_OPEN_LOG
> received
> ../..
>
> But I believe it's not related to my problem at all.
>
>
> regards,
> patpro
>
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
