Hi, I several time based firewall rules and used "--kerneltz" to be able to set the time in local time zone. It used to work until a day or two ago when I updated to the latest firewall package. Now I do not get any entries in iptable-save if "--kerneltz" is used. I remove it and the rule is back. Am I doing something wrong?
Never mind, I did not realize that "Time in UTC" check-box is now being handled and if not selected, "--kerneltz" is added automatically. I had to remove "--kerneltz" from "Extra arguments" and it is all working now.
Yep. Firewall was fixed in such a way that it always automatically adds the kerneltz argument to time fields, unless you specifically want UTC in firewall.
However, iptables chokes on having several kerneltz parameters on the same line, so having it also in the extra argument will break things, as you noticed.
So, old rules that included kerneltz extra parameter will need to be checked and possible changed.
The change was on firewall version 2017-05-09. Currently both LEDE master and 17.01 branch have the update, so it will also get into the 17.01.2 release.
It would help a lot to have a warning on the page to show incompatible parameters. I suspect this is a long standing bug / workaround so many will be unknowingly affected...
1 Like
That might help indeed. The firewall fix from @jow fixed the UTC time option handling but the side effect is that some old configs will be invalid, as iptables itself is strangely strict about not having --kerneltz option twice. (that would be harmless, so a bit strange). Jow added exception handling to iptables in order to help firewall config parsing to get over that error, but a rule like that is still invalid.
It would indeed be nice if LuCI would show a warning in case "extra arguments" field contains "--kerneltz" as that kerneltz/UTC selection needs to handled via the UTC time field now.
Easy approach is to add a static explanation to the "extra" field that kerneltz option is to be handled via the UTC time option, but a fancier approach would be to have in addition validation so that kerneltz can not be in the extra argument field.
Now that we are talking about different approaches, the best one would be to detect two identical settings and collapse them into one. Otherwise there will be a lot of broken firewall rules once this change gets into more routers.