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
I would be interested in branching off the main tree and redesigning the GUI.
Probably be better developing a better GUI for ipfire 3. That way it doesn't interfere with current efforts.
I also have a question. Are we still going to be using CGI/perl for the interface in version 3
Thanks, Bailey
Get Outlook for Androidhttps://aka.ms/AAb9ysg ________________________________ From: Nick Howitt nick@howitts.co.uk Sent: Thursday, February 29, 2024 3:39:49 AM To: development@lists.ipfire.org development@lists.ipfire.org Subject: Can the firewall interface be simplified
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
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 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.
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.
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?
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.
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.
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.
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.
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.
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
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
Hello Nick,
Welcome to the list.
On 28 Feb 2024, at 14:39, Nick Howitt nick@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
Hello Michael,
On 01/03/2024 16:12, Michael Tremer wrote:
Hello Nick,
Welcome to the list.
On 28 Feb 2024, at 14:39, Nick Howittnick@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.
Who says it has to be slow? A port forwarding screen just needs a subset of the fields exposed in the firewall screen. The Firewall screen could still exist for advanced user. Same for 1-to - NAT and Incoming firewall.
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.
Agreed. At least I know iptables pretty well to understand what some of the fields might be doing.
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.
Is it not possible to add extra screens to the Firewall menu?
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.
I agree it can work with complex rules (but I've hit a couple of bugs). I just don't understand why someone just wanting to add a port forward rule needs to be presented with a box that says NAT then have to choose between SNAT and DNAT. This is low-level iptables stuff. A simple port forward needs DNAT so it does not even have to be presented as an option on a Port Forward screen.
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 may to try to have a look, but I don't use perl. I can follow some so it may help. As an idea, can the Firewall Rules screen be cloned and all the irrelevant fields masked with their values set to whatever is correct for port forwarding (NAT and Destination NAT checked and Destination set to Red0), In Destination, just the Destination Address exposed etc.
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.
I also use the term 1-to-1 NAT. I didn't want to use it here as I was not sure if it was Just a ClearOS term, but I have seen it somewhere else recently. I just didn't know what the general term was. ClearOS does it in one screen which sets up the alias, does the FORWARD, PREROUTING (DNAT) and POSTROUTING (outbound SNAT) rules for you and also sets up a hairpin rule. From what I discovered yesterday the hairpin rule is unnecessary if you leave Source > Standard Networks set to Any rather than Red0 as ClearOS sets it. Their implementation is not perfect either and I had a number of bug fixes for it which went unpublished.
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.
The 15 port restriction is exactly the same restriction as you already have using Service Groups which also create multiport rules but iterate over the protocols as well. A port range only counts as two ports as far as the multiport rule goes. In ClearOS I used 2 regexes to validate the rule: Upto 15 ports: preg_match('/^[0-9]+((:|,)[0-9]+){0,14}$/' Cannot have port:port:port: preg_match('/[0-9]+:[0-9]+:[0-9]+/' I also checked that the first port in a range was less than the second and that all ports were in the range 1-65535.
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.
As I am relieving ClearOS from duty bit by bit, it is still running the OpenVPN server. I can't migrate that to IPFire for the moment. OpenVPN is running using the subnets 172.17.0.0/24 and 172.17.1.0/24 and ClearOS is running on 172.17.2.1. I need to take control of roadwarriors from time to time using VNC from my PC on the IPFire LAN. To do this I have set up a static route to 172.17.0.0/23 (covers both OpenVPN subnets) via 172.17.2.1. If you do that, your packet goes from my PC to the IPFire, gets redirected to ClearOS to the OpenVPN road warrior and back from the warrior to ClearOS. From ClearOS it gets lost as it went out on a redirect. I didn't check if it came back to my PC as I don't run wireshark on it, but it did exit the ClearOS interface. I assume it then went straight to my PC which rejected it as it was expecting a response via IPFire. To get round this I added an SNAT rule, effectively "iptables -I NAT_SOURCE -t nat -s 172.17.2.0/24 -d 172.17.0.0/23 -j SNAT to-source 172.17.2.254". 172.17.2.254/24 is the Green0 LAN. This way the packet leaves my PC hits IPFire where it has its source changed to IPFire then goes to ClearOS -> Roadwarrior -> ClearOS, then crucially, because of the SNAT, back to IPFire which then sends it back to me. Does this make sense or should I have done it differently? Roadwarrior to IPFire LAN is fine as ClearOS NAT's all inbound OpenVPN to the ClearOS LAN IP.
Regards,
Nick
-Michael
Regards,
Nick
Small update
On 01/03/2024 17:53, Nick Howitt wrote:
Hello Michael,
On 01/03/2024 16:12, Michael Tremer wrote:
Hello Nick,
Welcome to the list.
On 28 Feb 2024, at 14:39, Nick Howittnick@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.
Who says it has to be slow? A port forwarding screen just needs a subset of the fields exposed in the firewall screen. The Firewall screen could still exist for advanced user. Same for 1-to - NAT and Incoming firewall.
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.
Agreed. At least I know iptables pretty well to understand what some of the fields might be doing.
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.
Is it not possible to add extra screens to the Firewall menu?
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.
I agree it can work with complex rules (but I've hit a couple of bugs). I just don't understand why someone just wanting to add a port forward rule needs to be presented with a box that says NAT then have to choose between SNAT and DNAT. This is low-level iptables stuff. A simple port forward needs DNAT so it does not even have to be presented as an option on a Port Forward screen.
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 may to try to have a look, but I don't use perl. I can follow some so it may help. As an idea, can the Firewall Rules screen be cloned and all the irrelevant fields masked with their values set to whatever is correct for port forwarding (NAT and Destination NAT checked and Destination set to Red0), In Destination, just the Destination Address exposed etc.
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.
I also use the term 1-to-1 NAT. I didn't want to use it here as I was not sure if it was Just a ClearOS term, but I have seen it somewhere else recently. I just didn't know what the general term was. ClearOS does it in one screen which sets up the alias, does the FORWARD, PREROUTING (DNAT) and POSTROUTING (outbound SNAT) rules for you and also sets up a hairpin rule. From what I discovered yesterday the hairpin rule is unnecessary if you leave Source > Standard Networks set to Any rather than Red0 as ClearOS sets it. Their implementation is not perfect either and I had a number of bug fixes for it which went unpublished.
I've just found IPFire does have a specific hairpin rule that it adds to port forwards by setting a mark in the MANGLE table and then picking it up in the NAT_DESTINATION_FIX chain in the NAT table. Just a different way of doing it from ClearOS, with the additional complication of using marks.
It is possible to avoid setting marks just by using a rule "iptables -I NAT_DESTINATION -t nat -s your_LAN_subnet -d your target_LAN_machine -j SNAT --to-source your_LAN_gateway_IP". You can also add your port selectors like you have in the NAT_DESTINATION chain of the MANGLE table. It only needs to be set for the target_LAN_machine's LAN as all other packets coming from different LAN subnets automatically pass through IPFire anyway.
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.
The 15 port restriction is exactly the same restriction as you already have using Service Groups which also create multiport rules but iterate over the protocols as well. A port range only counts as two ports as far as the multiport rule goes. In ClearOS I used 2 regexes to validate the rule: Upto 15 ports: preg_match('/^[0-9]+((:|,)[0-9]+){0,14}$/' Cannot have port:port:port: preg_match('/[0-9]+:[0-9]+:[0-9]+/' I also checked that the first port in a range was less than the second and that all ports were in the range 1-65535.
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.
As I am relieving ClearOS from duty bit by bit, it is still running the OpenVPN server. I can't migrate that to IPFire for the moment. OpenVPN is running using the subnets 172.17.0.0/24 and 172.17.1.0/24 and ClearOS is running on 172.17.2.1. I need to take control of roadwarriors from time to time using VNC from my PC on the IPFire LAN. To do this I have set up a static route to 172.17.0.0/23 (covers both OpenVPN subnets) via 172.17.2.1. If you do that, your packet goes from my PC to the IPFire, gets redirected to ClearOS to the OpenVPN road warrior and back from the warrior to ClearOS. From ClearOS it gets lost as it went out on a redirect. I didn't check if it came back to my PC as I don't run wireshark on it, but it did exit the ClearOS interface. I assume it then went straight to my PC which rejected it as it was expecting a response via IPFire. To get round this I added an SNAT rule, effectively "iptables -I NAT_SOURCE -t nat -s 172.17.2.0/24 -d 172.17.0.0/23 -j SNAT to-source 172.17.2.254". 172.17.2.254/24 is the Green0 LAN. This way the packet leaves my PC hits IPFire where it has its source changed to IPFire then goes to ClearOS -> Roadwarrior -> ClearOS, then crucially, because of the SNAT, back to IPFire which then sends it back to me. Does this make sense or should I have done it differently? Roadwarrior to IPFire LAN is fine as ClearOS NAT's all inbound OpenVPN to the ClearOS LAN IP.
Regards,
Nick
-Michael
Regards,
Nick
-
Adolf Belka -
Bailey Calder -
Michael Tremer -
Nick Howitt