From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Can the firewall interface be simplified Date: Fri, 01 Mar 2024 17:12:06 +0100 Message-ID: In-Reply-To: <687baa26-20b0-4ca5-b0e7-efd9c2f46c3c@howitts.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3132752380142041616==" List-Id: --===============3132752380142041616== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Nick, Welcome to the list. > On 28 Feb 2024, at 14:39, Nick Howitt wrote: >=20 > Hi, >=20 > I posted this to the forums but this may be a better place for discussion. >=20 > 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 iptabl= es. Oh that is sad to hear. > I have found the firewall complicated to use as it is trying to do everythi= ng in one screen and I can only really get it to work with my knowledge of ip= tables and using the help screens. It is not something any family member coul= d easily take over if I ever pass on. >=20 > Many domestic routers have a very simple Port Forwarding menu. At its simpl= est, it has a destination (LAN) IP, protocol and port/port range which applie= s 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 h= elp unknowledgeable users to have a simple port forwarding menu something lik= e that, with maybe a source IP field as well. ClearOS has a much better looking web UI. IPFire=E2=80=99s web UI definitely = isn=E2=80=99t 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 tha= t it becomes slow and difficult to use i.e. corporate style. But it does not = look too great. The user experience isn=E2=80=99t the best either as things as very much sepa= rated from each other, not really so well connected and it takes some knowled= ge to piece them together. That being said, I don=E2=80=99t 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 ca= n expect the firewall to do when a certain button is being clicked and what n= ot. 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 som= ething we would rather consider a security risk itself and would recommend th= at people play with IPFire in a lab first before putting it on the wild inter= net. 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 th= e web UI that much. The only possible option is a complete rewrite as the cod= e is very old, complicated, written in Perl which isn=E2=80=99t that popular = any more. Over the years though, we have glued on things in various places. D= efinitely with varying success. Most projects have always been treated as a v= ery low priority thing. I am not saying that this is right or the way we want= ed it, but it is the way it is. To dig more into history=E2=80=A6 We used to have a simple port-forwarding pa= ge only. On top of that a page to configure =E2=80=9CDMZ pinholes=E2=80=9D an= d we still have the MAC address filter on BLUE. This was the most basic firew= all that we have inherited from IPCop. In this day and age (or let=E2=80=99s say even ten years ago) this no longer = cut the mustard. We needed something better, and what we released then is wha= t 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=E2=80= =99t think that we have ever received the feedback that a simple port-forward= ing was too complicated to configure. In fact we usually get the feedback tha= t the IPFire UI is a lot more simple than others. > I have a /29 block of static IP=E2=80=99s, Really using one of them should = need a screen little more complicated than a Port Forwarding screen, but shou= ld also allow you to specify which of your external IPs to use. Then it shoul= d 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 i= s on and not the other LANs). I suppose this is called =E2=80=9C1:1 NAT=E2=80=9D 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 anothe= r 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 inc= oming firewall e.g. for OpenVPN. >=20 > I like the Service groups concept but, at the same time, it could be made l= argely redundant. If the use of =E2=80=9C-m multiport=E2=80=9D 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 g= roups 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 b= e less. We have plans to replace this by using ipsets but I believe those cha= nges have not been posted to the list, yet. We still haven=E2=80=99t checked = if there would be any performance regressions if we were to migrate all multi= port rules to ipset. > I would also need to think about it more, but it may be good if Static Rout= es also created their own hairpin firewall rule. >>From where to where? I don=E2=80=99t think I follow on this one. -Michael > Regards, >=20 > Nick --===============3132752380142041616==--