Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Aug 2007 17:21:33 +0100
From:      "Greg Hennessy" <Greg.Hennessy@nviz.net>
To:        "'Patrick Proniewski'" <patpro@patpro.net>
Cc:        freebsd-pf@freebsd.org
Subject:   RE: strange "throttling" issue with pf on xDSL connection
Message-ID:  <000701c7d458$068f1780$13ad4680$@Hennessy@nviz.net>
In-Reply-To: <569F9080-B78F-400B-B3C5-FCA05F04BF80@patpro.net>
References:  <DE71F511-8553-401A-A16C-DF4CAA5DA6E3@patpro.net> <001101c7d441$0f61aa10$2e24fe30$@Hennessy@nviz.net> <569F9080-B78F-400B-B3C5-FCA05F04BF80@patpro.net>

next in thread | previous in thread | raw e-mail | index | archive | help
> # 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
> 





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000701c7d458$068f1780$13ad4680$>