Lan rule passes src:Lan*, log reports blocked packets?

  • My LAN firewall rules include "any protocol, src = LAN subnet, dest *, defaults…"  followed by a block all all rule with logging I entered just for the lan subnet.

    The logs show plenty of entries like: "blocked; LAN src dest TCP:RA"  -- note: sourcing my lan block all rule.

    1. What part of 'pass all' am I missing?  The above packet is certainly sourced on the lan.

    2. As the rule above to pass it clearly fails to pass it, why does the block rule after it succeed to catch it and log it?

    I can't be the first one to ask, maybe a sticky?

  • It was blocked because the packet was out-of-state (doesn't belong to an established connection).

    I can think of a variety of reasons this could happen. Faulty cable between your PC and the firewall, application that likes to slam doors (terminate connections abruptly rather than closing them gracefully) resulting in packets arriving after your application has closed the connection, etc.

  • A logging switch to separate 'protocol weirdness' from packets the rules could actually block or pass would make a big difference in keeping clear what new attempts are being rightly/wrongly accepted / denied vs.  the less bothersome post-acceptance state/protocol fails.

  • Not certain if it would work, but you could possibly create a second "default deny" type rule at the very bottom of your WAN rule set (directly above the existing default deny rule) and leave logging disabled, specify TCP as the protocol, and edit the tcp flags in the advanced options so that it catches everything except SYN packets. This way strays will be dropped without being logged, and valid connection attempts on closed ports pass this rule to be caught and logged by the default deny rule.

  • Good thought, I had that idea as well. No joy.  The 'block all with no logging' failed to catch the protocol weirdness.  What we need is a rule that catches only protocol weirdness, only blocks it, and lets you decide whether or not to log it.

Log in to reply