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.
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.
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.
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.
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