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