Since the release of the firewall configuration page in fw 3.x, i have asked GL to change from using a custom rules file, to using the OpenWRT config files (ie /etc/config/firewall).
This is very important as now configuring something via command line or Luci works perfectly, but the rules are not shown in the GL UI. This is also true in reverse, if you add rules to the GL UI, they are not shown in Luci.
In my opinion this is a huge flaw, as users can have conflicting rules set, with undefined behavior and issues (seen previously in a lot of threads).
Also, add support for the “reflection” option for port forwards in OpenWRT. This lets users access ports added to port forwarding from INSIDE their lan. Without this, the user must use their public ip / hostname to access the port.
Since this STILL hasn’t been fixed since 3.x, which has been more than 1 year now, i would not recommend that 4.x be released without it.
GL UI is fine for simple rules, which is what it is intended for.
I tend to use source ip on forwards, as it telephony functions so open ports are a no-no. GL-UI does not do this.
If you want all your firewall rules in one place, just use LUCI firewall page.
Not sure I see it as a biggie. Those with simple needs can use the GL-UI, those with more complicated still have a GUI to do these rules in. Those that can type can use UCI at the command line.
It does not have to do with how advanced or not the UI is, the issue is now there are conflicting rules if you add to both locations. This is easily fixed if GL uses the intended config files provided by OpenWRT, as they do with everything else.
It seems pointless, redundant and complicated to replicate the LUCI interface in the GL interface.
The GL Interface job is to allow simple rules to be written witout jumping into Luci.
I can see the port forward tables competing, so you have a fair point there. I would argue anyone using the Luci interface (probably) knows what that are doing, if there is a problem they would know to compare both,
There GL UI cannot show the rules properly, as there are many many more options in the full openwrt config than you can configure in the GL interface.
Currently it cannot display the more complicated rules.
How would you propose the current GL UI to show a forward with source point ip address as port limits? Or a NAT loop for the LAN interface?
It would require reimplementing the LUCI interface into GL UI. Yes they could use “advanced” button to hide complexity, but why bother at all, just do firewall in Luci only?
I think you will agree the simplicity of the GL interface is its advantage.
I am curious how do you see the complexity of thr Luci interface re-implemented in GL UI and the complexity hidden?
Huh?
The GL UI will be exactly as it is now, just using the correct config file in the backend? Is that hard to understand?
Anyway this is not up for discussion, it is more to remind the devs that this is pending. I already talked to Alfie about all this long ago, it has been on the todo list for a long time.
I agree with this, back when I was writing alot of java programs adding abstraction was important also to keep it maintainable for many reasons, I think this makes it also more maintainable and user friendly aswell because its using one config than multiple ones, makes debugging network issues also easier because there are no other strings attached like a second config idd and rules which are on one side visible and somewhere else not, I think its a very valid point.
Gl-UI V4.0 already uses /etc/config/firewall to configure firewall rules. You can try to configure firewall rules in GL-UI and it will display correctly in Luci.
Rules in Luci are not fully displayed in GL-UI because of simple filtering in GL-UI. You can easily see that GL-UI only displays rules with name GL-*. Rules in Luci are complex and fully displayed in GL-UI would be redundant.
You can use a PM to remind the developers, or thread necromancy to show the problem’s age . If you do not want to discuss do not put on a discussion board.
If the dicussion board is the only way to communicate, perhaps a bit of background so people are aware of the purpose, rather than asking people who do not know the background “if they understand”, and telling them “I have already talked to the developers, not up for discussion”.
Comes over a bit rude, which I am sure was not your intent.
And I do not understand how a simplifed UI that cannot show all the rules in one place, and another view showing a different view in another place, both using the same files is going to improve the situation.
Which is why I asked, if I understood, I would not have asked.
I think my only suggestion would be to add support for firewall zones from traffic rules in the simple UI, indeed it might be not easy to implement at first but it would make it usable from luci back to simple UI, I agree its maybe not feasible to add also contracking and those things in it, but alot of them are just zone1 to zone2.
Maybe its better to make two type catogaries for the simple ui where the user can write and read simple rules.
And the other catogary is where all luci ones come in but you can only edit ports, zones or delete but cannot add a rule, therfor you can set a message box that the user needs to go to luci.
I mean one could have followed a tutorial somewhere to add something on the firewall in luci, forgetting about it, and since the person could be a very beginner, he starts to get issues and ask support on the forums which is fine, but then someone assisting him asks for the firewall and he shows the simple firewall one, and this way the problem cannot be found, same as finding a potentional bug, devs could get put on the wrong fence because there is intercompatibility between those two, though I think thats a very low chance but its still valid.
I think in my opinion its better to go with a skeleton model approach, just a base skeleton if a zone forwards to a other zone then add it in the simple filter and ignore all other settings in it if someone does a edit via simple ui, those ignored settings thats for luci.
But as for the time being, im fine with this if it gets added later or after release, I think the devs work on a deadline aswell this requires bigger ui changes in which it could introduce newer bugs and people want a stable release.
