Hi all, last week I reported a problem with firewall logging. After looking deeper into Firewall.pm I have a better understanding of the problems I first had with using the Firewall as a rather fresh PVE User:
- the different levels of log_level_in / out don't make sense to me. Firewall.pm uses them as boolean to decide wether to log or not. The level is is never ever used (which i'd expect from the UI and the docs). Or did I miss something? - I don't see a clear consistent way on how packets are getting logged (and in what direction). From a user point of view i was expecting more logging with increasing log levels up to logging accepted packets for a loglevel of debug. Now I know that this asumption is wrong. - Macros can't be edited or extended since they are hardwired in the code. - Same for the Standard Set of Rules I was thinking on how to improve the situation. My first thought was to give the log_levels a better meaning (like start logging drops at a certain log_level and accepts a the highest loglevel). But I think, with lots of chains used by all guests, this is no good approach. IMHO a flag to toggle logging for a rule or security group in general would be the most usefull thing to have. This would even make it possible to log accepted packages. I'd also like the Idea of having the macro definitions outside the code, where an admin can change them (same for the standard set of rules). But before I start putting too much time into this I'd like to ask for comments and if there is interest at all :-). I'll also send a first patch that makes all (except for one place) iptables rule generation in Firewall.pm differenciate between the match and the action part of the rule, which gives us one central place to generate logging rules. This is meant as an interim patch on the way to the final goal - so some of the code probably looks clumsy - but the goal was to generate exactly the same rules as before - which appears to work on my setups (comparing pve-firewall compile outputs) except for a few additional spaces sometimes. And since this is my first patch here, I'd appreciate feedback for the patch in any case :) Tom _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel