[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

state optimization too aggressive?



Reviewing my logs for dropped packets, I see sometimes long series of blocks where a host is sending tens of R or F packets; do these indicate late responses and efforts to tear down connections for states that have already been flushed from pf's tables? Example:

=================================================================
Apr 07 15:17:36.075730 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 1729454233:1729454233(0) ack 2593400436 win 32850 (DF)
Apr 07 15:17:36.799595 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)
Apr 07 15:17:38.243383 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)
Apr 07 15:17:41.138261 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)
Apr 07 15:17:46.915364 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)
Apr 07 15:17:56.916929 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)
Apr 07 15:18:06.918915 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)
Apr 07 15:18:16.921158 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)
Apr 07 15:18:26.914892 rule 35/0(match): block in on fxp2: 66.196.72.40.60099 > 10.0.0.2.80: F 0:0(0) ack 1 win 32850 (DF)


Apr 07 04:38:23.051181 rule 35/0(match): block in on fxp2: 66.232.42.33.51028 > 10.0.0.2.25: R 196455269:196455269(0) ack 351021202 win 5840 <nop,nop,timestamp 49948789 862902586> (DF)
Apr 07 05:53:39.876675 rule 35/0(match): block in on fxp2: 66.232.42.33.34953 > 10.0.0.2.25: R 667158644:667158644(0) ack 3838625067 win 5840 <nop,nop,timestamp 50400513 862911621> (DF)
Apr 07 07:09:31.237773 rule 35/0(match): block in on fxp2: 66.232.42.33.46406 > 10.0.0.2.25: R 1195542715:1195542715(0) ack 3097498885 win 5840 <nop,nop,timestamp 50855690 862920725> (DF)
Apr 07 08:20:16.448542 rule 35/0(match): block in on fxp2: 66.232.42.33.57328 > 10.0.0.2.25: R 1391850832:1391850832(0) ack 467325695 win 5840 <nop,nop,timestamp 51280250 862929217> (DF)
=================================================================


I thought that if this is the case adding 'set optimation conservative' to my ruleset might alleviate it - is this a good idea? Or what should I interpret this as?

TIA,

DS