Hi Adolph,
On 29/02/2024 11:37, Adolf Belka wrote:
Hi Nick,
On 28/02/2024 15:39, Nick Howitt 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.
Welcome to the IPFire dev mailing list. You will be most welcome
to utilise your coding skills to support the IPFire project. There
are lots of bugs in the IPFire Bugzilla that would benefit from
additional resources becoming available.
I don't have much in the way of coding skills. I can script in bash.
I was able to maintain some php in ClearOS but could never originate
a new app and I have not used any IDE for code generation or
debugging, I am afraid.
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.
I have to say that my experience was different from yourself. I
have no experience with iptables, I am just a hobbyist in terms of
coding etc.
I just read through the wiki pages on the firewall and then
entered the info I needed into the firewall rule page and so far
all of the rules I have created have worked as expected.
When forwarding an alias, there is no mention anywhere of probably
needing an outbound SNAT rule or hairpin rule and the Firewall
screen specifically blocks you from creating a hairpin rule.
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.
Trying to understand what is meant by the simplification
description in words and its impact on the existing approach can
be difficult.
Surely this screen is simpler:
But it does not allow for port redirection or enable you to specify
a source IP which seems to be quite important for SIP users.
If there is a Port Forwarding menu, what about when users need to
create pinholes between the zones, which is not a Port Forward
rule. How would that be dealt with in this menu or would there
have to be another separate menu for that?
I have no problem with multiple menus, each with a different purpose
What happens with the Incoming and Outgoing Firewall firewall Rule
generation? Is that another menu or how is that dealt with. Having
different menus for each type of rule generation sounds to me like
it is getting more complicated rather than simpler.
I have no problem with multiple menus, each with a different
purpose, but each simplified menu should create all the rules it
needs, so a port forward creates Forward and DNAT rules and,
arguably a hairpin rule. If you are forwarding, so using an alias,
the screen used for that creates the alias, Forward, DNAT, SNAT
(back to the external IP) and the hairpin rule all from one screen.
Currently you have to configure 3 firewall rules (including the
hairpin) and one alias. I am saying one screen to do it all would be
simpler.
An approach could be for you to create a patch set for the
simplification that you are considering. That would enable you to
show what is being proposed and the potential impact for existing
users that are familiar with the current approach.
I am not really a coder and haven't a clue how to design a screen or
any real idea how the whole system links together.
It would also give you the opportunity to familiarise yourself
with the IPFire patch submission process.
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).
As you have in ClearOS, you could then have a separate menu to
open the incoming firewall e.g. for OpenVPN.
The incoming rules for OpenVPN are automatically created if
OpenVPN is used. If you create an OpenVPN RW connection then it
can be used without needing any additional rules defined. If you
want to limit the access of the RW to certain machines on the
green network then additional rules would have to be created
dependent on the requirements.
You have missed the point. I was using OpenVPN as a specific
example, but I meant for any service running in IPFire which you
wanted to expose to the internet, e.g Nginx, HAProxy, a public time
server etc. In iptables terms, the difference between the INPUT
chain and the FORWARD chain. I would separate them out into
different screens.
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.
Yes the service groups are when you want to apply a rule to a
collection of ports. Examples could be having a rule that allows
both http and https access to a web server, allowing both udp and
tcp traffic to a qbitorrent server etc.
What would be the benefit for the users of changing the Service
Groups option on the Firewall Groups menu to using a drop down box
on the Firewall Rule page.
No that is not what I meant. If the "-m multiport" option is always
used when generating port based rules, then the validation on the
Destination Port box can be opened up to allow things like
"80,443,9881:9884,9981:9984". Currently it will only accept a single
port or port range. This would remove the need for Service Groups if
it is for a single protocol avoiding having to use another menu,
which could be for advanced usage only. So no moving of the
dropdown, but changing the validation on the Destination Port box
and changing the resulting firewall rules generated to use the
multiport module always. If you use service Groups, the multiport
module gets used anyway.
If it just does the same thing but in a different location then I
would suggest leaving it as it is as users will already be
familiar with where to go for that function.
You can leave Service Groups. Advanced users will appreciate them,
but less advanced users will get more power and not be pushed into
having to configure a separate menu as well.
Regards,
Adolf
I would also need to think about it more,
but it may be good if Static Routes also created their own
hairpin firewall rule.
Regards,
Nick