This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Default Drop Rule v18

Is there a way to log the default drop rule traffic or supersede it with a rule to log it?    



This thread was automatically locked due to age.
Parents
  • Hello John,

    I already asked this a couple of months ago. See the discussion here: https://community.sophos.com/xg-firewall/f/discussions/123399/new-drop-all-rule-in-v-18

    In short:

    - Activating logging on the default drop rule is not possible.
    - You can put a explicit deny rule before the default drop rule with logging. This was the method you needed to use in V 17.5 to see the dropped traffic.

  • I read that last night(thx) but did not solve this issue for myself at least.

  • Go on the rule above the rule #0. Create a new rule below.

    Yes my post was about V18 only V18 has this predefined rule #0. 

    Maybe mentioning 17.5 was a bit misunderstandable. In version 17.5 an Explicit Deny rule was the only way to see what packets wer dropped in the end. There was no predifined "Drop all". 

  • I did do that and no change. Will group this in a saying had to make up after a few corporate meetings. "It is not how bad the idea is, but who thought of it"  Not your recommendation but the the idea to take the feature out. Went through these a few times in corporate meetings and at the end would finally say why are we doing this? They would just say because so and so thought of it?  The reason it is important is so can plan a strategy if the interface processing is being hurt from a rouge bot. Can't do that if have no idea who is knocking at the door. The options are to put them in a table and lock out with very little processing or block the country entirely or remote to them and send a message.  On election night there was an DOS attack and it took my first wave device at the time ubiquiti out from processor utilization. So in minutes replaced with a watchguard and always use their autoblock feature that wish all would implement. Immediately had 3+ pages of lockouts and plenty of bandwidth available back.  You just never know without the proper information. best regards

Reply
  • I did do that and no change. Will group this in a saying had to make up after a few corporate meetings. "It is not how bad the idea is, but who thought of it"  Not your recommendation but the the idea to take the feature out. Went through these a few times in corporate meetings and at the end would finally say why are we doing this? They would just say because so and so thought of it?  The reason it is important is so can plan a strategy if the interface processing is being hurt from a rouge bot. Can't do that if have no idea who is knocking at the door. The options are to put them in a table and lock out with very little processing or block the country entirely or remote to them and send a message.  On election night there was an DOS attack and it took my first wave device at the time ubiquiti out from processor utilization. So in minutes replaced with a watchguard and always use their autoblock feature that wish all would implement. Immediately had 3+ pages of lockouts and plenty of bandwidth available back.  You just never know without the proper information. best regards

Children