PF Incoming port 80 connections blocked randomly

I have a web server with plenty of traffic to port 80 (shown in Apache logs), but just noticed with pflog that a few connections to port 80 are being blocked for no apparent (to me) reason, for example:

Code:
 00:00:00.000000 rule 0/0(match): block in on vtnet0: (tos 0x0, ttl 56, id 64107, offset 0, flags [DF], proto TCP (6), length 52)
    104.154.168.156.51980 > 123.123.123.123.80: Flags [F.], cksum 0xf2d5 (correct), seq 1146210415, ack 1928168162, win 3814, options [nop,nop,TS val 3923550373 ecr 3414636681], length 0
 00:18:30.801502 rule 0/0(match): block in on vtnet0: (tos 0x0, ttl 106, id 1, offset 0, flags [DF], proto TCP (6), length 40)
    52.167.144.187.10181 > 123.123.123.123.80: Flags [R.], cksum 0xfec1 (correct), seq 0, ack 479371196, win 0, length 0

Any idea why those IPs got blocked? There isn't any specific rule blocking them. Most of the blocked IPs seem to belong to crawling bots (Google, MSN and the like).

This is my pf.conf:

Code:
ext_if = "vtnet0"
set block-policy drop
set skip on lo0

tcp_services="{ 25, 53, 80, 443, 587, 953 }"

block log all

block in quick on $ext_if from any to 255.255.255.255

pass from lo0 to lo0 keep state

pass out proto tcp to any port 25 keep state
pass out proto { tcp, udp } to any port 53 keep state

pass out proto icmp to any keep state

pass in quick on $ext_if inet proto { tcp, udp } from any to ($ext_if) port $tcp_services

# this blocks a list of IPs, but those blocked to port 80 are not in the list, I'm sure
table <enemigos> persist file "/etc/ips_bloqueadas.pf"
block log on $ext_if from <enemigos> to any
 
those are possibly re-sent or otherwise out-of-sequence FINs after the connection has either fallen out of the state table, or been successfully closed and thus not in the state table. do a capture on port 80 for maybe half an hour, and see if the connections at hand get torn down with a normal fin/ack/fin/ack sequence before you see the blocked packets on the pf log.

also, this is tangential, but, you have set skip on lo0 along with a pass rule specifying lo0 — the skip prevails, and can be confusing if you also expect the rule to work. or at least we've been confused by that before.
 
Back
Top