Rule processing order issues



  • My ISP says due to their network design they can't block some broadcast spam. It's filling up my firewall log and I just want it gone. I've tried adding rules on the WAN and Floating at the top but the traffic is always blocked by the default deny rule. This is the last rule in the list. I really just want to create an unlogged rule so I don't have to sort through these when I'm troubleshooting other things since it's not going to stop. I see it all day, everyday. Screenshots attached.
    Thanks








  • I would put the block for 169.254.193.62 on the WAN tab, not Floating, and put it at the very top.  You only need to block on the one interface, so using a floating rule isn't quite right.



  • Tried it in WAN with the same result. The traffic is blocked by default deny rule.



    • If you are using a floating rule, you have to check the "quick" option (did you?)
    • Last rule on the WAN tab on the image does not really make any sense. You are blocking incoming packets on WAN, whose source IP is the WAN address itself and the destination is the LAN address (????)

    Anyway I agree with KOM, it is clearer to block it at the WAN interface



  • Yes the quick option is checked. I tried blocking in WAN first but it had no effect. Attached with the rule in WAN. Full pfsense reboot and PC. States cleared. No change.
    Edit: Tried blocking with the easy block from the log as well.



  • Netgate

    You are really worried that blocked traffic is filling your log?  Aren't you just happy that the undesirable traffic is blocked?



  • Strange…

    What about disabling the 2 auto-added rules? You can do it on the interface options


  • Rebel Alliance Global Moderator

    Ok that rule on the bottom souce wan address dest lan address is just gibberish..  Where is the rule you created?  Create a rule on wan put it at the top that blocks source 169.254/16 dest any UDP and don't log it..  Done!

    If your still setting the block - remove the block rfc1918 that is on by default on wan..  Its not really of any use to be honest, since there is a default deny anyway so unless its allowed its blocked anyway.

    Do that rule - then clear your log, and let see if any new items show up.  If they do then click on the red X and what rule does it say blocked it?



  • @johnpoz:

    Ok that rule on the bottom souce wan address dest lan address is just gibberish..  Where is the rule you created?  Create a rule on wan put it at the top that blocks source 169.254/16 dest any UDP and don't log it..  Done!

    If your still setting the block - remove the block rfc1918 that is on by default on wan..  Its not really of any use to be honest, since there is a default deny anyway so unless its allowed its blocked anyway.

    Do that rule - then clear your log, and let see if any new items show up.  If they do then click on the red X and what rule does it say blocked it?

    That did the trick. Thanks you! Not sure why specifying a single address didn't work. I just altered the rule from single host to network (169.254/16) and it's now gone. I also removed my manual block all rule. When I first set PFsense up years ago I wasn't aware there was a default, unseen, deny all rule. That last rule was supposed to function as a deny all.


  • Rebel Alliance Global Moderator

    My guess is you enabled the source wrong, or you were just seeing lots of other traffic from that same netblock 169.254/16 is APIPA range - this is a range that devices get when set for dhcp but no dhcp server gives them a lease, or sometimes devices use this range as a sort of link local type of address.  Its not a routable address so can only be used on the local segment, etc.

    If you don't like all the udp noise that is out there, after your allow rules for udp stuff just block all of udp and don't log it.  This will not stop state traffic - just keep your logs less messy from noise.



  • So the logs are back. I don't know what changed but today they're back. Been fighting through some poorly designed match making (Warframe) and having to search through hundreds of entries each time is a pain.


  • Rebel Alliance Global Moderator

    Did you edit your rules, is the source different - is it not udp.. If your seeing logs then you must of altered the rule or the traffic doesnt match for some reason.

    Can we see your rules and log entries - and click the red X in the log, what rule is it logging on?



  • Sorry for the delay. I hadn't touched the firewall since the proposed changes.
    Attachments show the setup.








  • You have logging enabled on that rule, disable that. Also that'll be blocked by block bogon networks, you might want to disable logging on the default block rule and add a block rule to the bottom of your WAN rules that logs after blocking all the noise without logging.



  • The problem I'm having is troubleshooting a frequent blocking issue with the game Warframe. If I disable logging of the default rule then I can't see what's being blocked. With it enabled I get 2 blocks ever second from this and it's very hard to quickly correct a block. If I disable blocking of bogon and private networks my WAN something changes but slightly. Instead of 169.254.193.62 being blocked on the "WAN" interface it's blocked on the SIS0 interface. They still happen twice a second. Enabling logging of the custom rules allows me to easily distinguish if a rule I create ends up trapping this traffic.

    Edit: I wonder if it has something to do with the fact that I'm also on a PPPOE connection. When I disable private network blocking it changes from WAN to SIS0 and my internet goes down. I try to reassign interfaces which fixes the internet connection but the logging persists.


  • Rebel Alliance Global Moderator

    So you didn't show what rule was blocking it.  By clicking the red X

    But yeah you have logging enabled on your block rule - why would you do that if you didn't want noise???  On your 169.254 block rule uncheck the logging so that little I goes away ;)

    You can enable or disable bogon and private block logging in the log settings - see attached.

    To be honest blocking private and bogon is kind of pointless to me..  The only thing that gets in from the wan is something you have created an allow for because of the default deny.  So doesn't matter what the source is it blocked unless you have created an allow rule.  So only thing those rules do is block those network from accessing your allow rules that might have been created.

    And to be honest when is a bogon going to be seen even?  And if your behind a nat that block private is going to cause you grief more likely than some form of bad stuff from a private getting into your allow rules you may have created ;)




  • @johnpoz:

    So you didn't show what rule was blocking it.  By clicking the red X

    But yeah you have logging enabled on your block rule - why would you do that if you didn't want noise???  On your 169.254 block rule uncheck the logging so that little I goes away ;)

    You can enable or disable bogon and private block logging in the log settings - see attached.

    To be honest blocking private and bogon is kind of pointless to me..  The only thing that gets in from the wan is something you have created an allow for because of the default deny.  So doesn't matter what the source is it blocked unless you have created an allow rule.  So only thing those rules do is block those network from accessing your allow rules that might have been created.

    And to be honest when is a bogon going to be seen even?  And if your behind a nat that block private is going to cause you grief more likely than some form of bad stuff from a private getting into your allow rules you may have created ;)

    I show the rule that does the blocking in the log. I have them both logged because I can then see if a new rule does the blocking. If I disable logging of the default rule then I miss every occurrence of the mistaken blocks I'm trying to correct. I have two problems going on.
    1. Warframe matchmaking destination ports are completely random. When I invite or am invited to a group and it fails I have to quickly alt+tab to PFsense and resolve the conflict. These are also blocked by the default rule. I've followed their NAT practices perfectly but it's known issue to them. The game was designed around UPNP and anyone not conforming has to deal with this or not play with anyone using UPNP.
    2. Doing the above fix while sorting through hundreds or entries means by the time I resolve the issue I've missed the opportunity.
    3. I've tried to disable the manual NAT entries and allow UPNP in PFsense but the game still detects "Strict NAT" and fails to work at all.


  • Rebel Alliance Global Moderator

    I am not suggesting you disable default rule logging, I am saying you don't need to log rfc1918 or bogon.  And your rule blocking 169.254 so it doesn't fill up your logs – why do you have that logging.  Not clear up your logs if you log it ;)

    And you are right - doh!!! you do have it showing default rule blocked that, I was looking for a popup window in the picture ;)

    So it seems that rule is not triggering - can you try setting dest to 255.255.255.255



  • Ah I will try disabling logging of those rules. Didn't see that option before.



  • So those check boxes are already unchecked to not log bogon and private blocks.


  • Rebel Alliance Global Moderator

    so did you uncheck to LOG your rule for 169.254 did you change the dest in the rule to be 255.255.255.255?



  • @johnpoz:

    so did you uncheck to LOG your rule for 169.254 did you change the dest in the rule to be 255.255.255.255?

    Tried both without success. Also tried blocking anything coming to port 10019 and 10007.


  • Rebel Alliance Global Moderator

    you sure the rules are becoming active?

    take a look with pfctl -sa or look at /etc/rules.debug

    If you want can setup a time I can Team Viewer in and we can take a look see together.  Just PM when is good for you and the login info - or if you send me just login info to pfsense I can take a look see remotely as well.