Hi,

I'm seeing these in the pflog off my firewall:
Oct 27 15:20:32.845671 rule def/(short) pass in on vlanxxx: 218.76.138.156.0 > x.x.x.63.0: udp 17035 Oct 27 15:21:12.924605 rule def/(short) pass in on vlanxxx: 218.76.138.156.0 > x.x.x.38.0: udp 17035 Oct 27 15:21:15.652141 rule def/(short) pass in on vlanxxx: 218.76.138.156.0 > x.x.x.80.0: udp 17035 Oct 27 15:21:29.271224 rule def/(short) pass in on vlanxxx: 218.76.138.156.0 > x.x.x.24.0: udp 17035

The local IPs are not operative at all so there is no traffic from these IPs
or 218.76.138.156

pfctl -ss |grep 218.76.138.156 -> nothing
pfctl -ss |grep x.x.x.63 -> nothing

I've even added
block quick from 218.76.138.156 in my pf.conf
but I'm still seeing these messages.
@0 block drop in log quick inet from 218.76.138.156 to any
[ Evaluations: 22078 Packets: 0 Bytes: 0 States: 0 ]
  [ Inserted: uid 0 pid 16282 State Creations: 0     ]

According to http://marc.info/?l=openbsd-misc&m=129577235704794&w=2
"The "short" reason code indicates that the packet was truncated or too short and therefore was missing information required to make a packet filtering decision. This could be, for example, a packet that only contained the first few bytes of an IP datagram (or a header that states that it is a particular length, but the packet is shorter than the length given). Run `grep PFRES_SHORT sys/net/pf*` if you want to see where/how this can occur."

So the question is. Why "pass" and not "block"?
In sys/net/pf.c before REASON_SET(reason, PFRES_SHORT);
there is always a *action = PF_DROP;

Is it true that I see the message because there is no packet filtering decision?

regards,

Giannis

Reply via email to