Re: Can the firewall interface be simplified

Re: Can the firewall interface be simplified

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 6322 bytes --]

Hello Nick,

Welcome to the list.

> On 28 Feb 2024, at 14:39, Nick Howitt <nick(a)howitts.co.uk> wrote:
> 
> Hi,
> 
> I posted this to the forums but this may be a better place for discussion.
> 
> I am a new user of IPFire had have just transitioned from ClearOS which is going end of life this year and I believe some of the firewalling could be a lot easier. Full disclosure - I used to be a basic maintainer of ClearOS (and sole maintainer for about 20 months) and I have good understanding of iptables.

Oh that is sad to hear.

> I have found the firewall complicated to use as it is trying to do everything in one screen and I can only really get it to work with my knowledge of iptables and using the help screens. It is not something any family member could easily take over if I ever pass on.
> 
> Many domestic routers have a very simple Port Forwarding menu. At its simplest, it has a destination (LAN) IP, protocol and port/port range which applies to the external interface. ClearOS also allows you to switch ports, so, for example incoming tcp:2222 can be switched to tcp:22. There is no mention of NAT, of source ports (which are irrelevant) or interfaces. It would greatly help unknowledgeable users to have a simple port forwarding menu something like that, with maybe a source IP field as well.

ClearOS has a much better looking web UI. IPFire’s web UI definitely isn’t one of our strong points at all. It works well and it is fast. I have gotten a lot of feeback from people asking us not to rewrite it so that it becomes slow and difficult to use i.e. corporate style. But it does not look too great.

The user experience isn’t the best either as things as very much separated from each other, not really so well connected and it takes some knowledge to piece them together.

That being said, I don’t mind a great user experience at all. Things can and should look pretty. But after all, we are looking for usability first and also clarity. That means that it needs to be very clear what the user can expect the firewall to do when a certain button is being clicked and what not. We do expect our users to know a little bit more than basic networking I suppose. Having very limited knowledge about the entire security topic is something we would rather consider a security risk itself and would recommend that people play with IPFire in a lab first before putting it on the wild internet. I suppose the same is true with every other kind of software out there. You will have to put some legwork in to learn about it.

So coming from a fork of IPCop, we have never really considered to improve the web UI that much. The only possible option is a complete rewrite as the code is very old, complicated, written in Perl which isn’t that popular any more. Over the years though, we have glued on things in various places. Definitely with varying success. Most projects have always been treated as a very low priority thing. I am not saying that this is right or the way we wanted it, but it is the way it is.

To dig more into history… We used to have a simple port-forwarding page only. On top of that a page to configure “DMZ pinholes” and we still have the MAC address filter on BLUE. This was the most basic firewall that we have inherited from IPCop.

In this day and age (or let’s say even ten years ago) this no longer cut the mustard. We needed something better, and what we released then is what you are seeing now. Basically a very flexible abstraction of iptables.

But I think it is great. For very complex firewall rule sets you are getting a lot of help with modular groups and lots of colours which I personally find incredibly helpful to avoid mistakes.

Does the configuration file format allow us to create a page that only shows a subset of the rules and make things easier? I believe so, but I don’t think that we have ever received the feedback that a simple port-forwarding was too complicated to configure. In fact we usually get the feedback that the IPFire UI is a lot more simple than others.

> I have a /29 block of static IP’s, Really using one of them should need a screen little more complicated than a Port Forwarding screen, but should also allow you to specify which of your external IPs to use. Then it should set up the Alias for you and do the port forwarding with the option of any protocol. At the same time it should set up an SNAT rule so outbound traffic is seen to originate from your designated external IP rather than the default interface IP, and a hairpin rule should be set up so the external IP can be accessed from the LAN (it is only needed for the LAN that the target device is on and not the other LANs).

I suppose this is called “1:1 NAT” in some places and I would like to have this feature actually because it would require to create a few less firewall rules. However, you would have to create another rule on another page to set this up so this might actually make things harder.

> As you have in ClearOS, you could then have a separate menu to open the incoming firewall e.g. for OpenVPN.
> 
> I like the Service groups concept but, at the same time, it could be made largely redundant. If the use of “-m multiport” is made use of for all port based rules, including a single port, then the destination port selector in the Protocol section could be opened up to allow up to 15 ports to be specified, like you can in the Services section. Then I think service groups are only relevant for when you have more than 1 protocol that you want to apply the rule to.

It would be quite easy to extend the current UI to allow lists of ports. But -m multiport has many restrictions that would make that all a little bit more complicated. You can only have up to 15 ports. If you use ranges that will be less. We have plans to replace this by using ipsets but I believe those changes have not been posted to the list, yet. We still haven’t checked if there would be any performance regressions if we were to migrate all multiport rules to ipset.

> I would also need to think about it more, but it may be good if Static Routes also created their own hairpin firewall rule.

>From where to where? I don’t think I follow on this one.

-Michael

> Regards,
> 
> Nick