- 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.
- 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.
But does that work in version 18? When I see #0 on that rule how do you get ahead of it. This is why I have used more than one firewall for years. Not that I want to manage more than one. thanks *** why they could not just leave the LOG as an option is beyond me? So far it is not working other than showing related outside connections that were initially instigated from the inside. No ankle biter/ bot events are showing.
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
Basically XGv18 implemented a default drop rule on GUI, which was always there. It did not add features as such, instead it shows the admin, there is a inevitable drop rule. To add the logging feature to this is a logging enhancement, down the road including other features as well.
I am not saying ,this feature would not be great to implement. I am saying that the prioritization could be on other parts of XG and integration with XG.
Got it... just seems like enabling the log would take a only few seconds to do. Probably a big system to get things passed and understand that all too well. best regards
