welcome to the IPFire community.
Option to let ipfire run-from-RAM, i.e. fast, wear-out-less, power-outage safe. (Customizable like Alpine linux in “diskless” mode)
This is unfortunately not possible as IPFire has to write some (database) files sooner or later. Besides, it is usually very handy to have a paper trail of your firewall, especially when it comes to firewall or IPS hits.
From my point of view, running IPFire as a live system does not make it faster, since there are almost no real-time dependencies to the disk (apart from proxy caching and similar things) as of today.
Reducing system footprint (smaller codebase / security / diskless operation / not 1,8GB system disk requirement)
We are already squeezing out every kilobyte we can. Trust me, it does not get much smaller, especially not if you want to preserve the feature set currently offered by IPFire.
Besides, have you looked at other distributions? They tend to be much bigger…
ISP-fallback options if internet access (ISP) is down. For example, having a second ISP, WWAN stick, or neighbors WLAN configured. (Configuratin examples as in Alpine/Multi_ISP)
At least for dial-up connections, it is possible to configure a WAN fallback (please refer to the documentation for further information). For other connection setups, failover/fallback is currently not implemented indeed.
Adding protocol-level firewall rules (not only packet level rules). (Package Firehol allows to supports these concise, simple, and well organized rules, see example rule-set.)
Their documentation looks like they are just looking up the protocol string you provided (e. g.
/etc/services and replace it with the port number they find in there.
I could not spot anything suggesting they are detecting protocols for every traffic stream encountered - which is, by the way, very slow, error-prone (how do you detect what is inside a TLS connection? HTTP? SMTP? something else?) and, depending on your implementation, risky: An attacker could bypass that filter by making his/her traffic look like something legitimate and common.
To be honest, IPFire is relatively compact for the functionality provided by it already. Aside from that, we do not want to be too flexible, since this is usually (ab)used by users to run additional services on a firewall. IPFire is not indented to provide a silver-bullet platform for all the services you want to run on a network.
Building IPFire on the work of Alpinelinux would seem like one option, but even if not, maybe a future major IPFire release could also become more accessible by re-using selected known dev tools.
This is unlike to happen. In the early days of IPFire 2.x, we were based on IPCop and Linux from Scratch. Today, there are no dependencies to other distributions, and - if I may speak for other core developers here - we intend to keep it that way.
The build procedure of IPFire 2.x is not very intuitive indeed. For IPFire 3.x, we have a completely new build system ready, but are unfortunately lacking time for development at the moment.
Anyway, thank you for your suggestions. I hope IPFire is good enough to be used by you today.
Thanks, and best regards,