New features (IPFire Roadmap)

Community
1

Hello, I’m glad I found IPFire. After comparing different alternatives, it came out and installed the best.

I’d still like to post the few unique desired features that I found missing. Implementing them could make IPFire even more outstanding in the future. Maybe you already have some of them on the roadmap?

  • Option to let ipfire run-from-RAM, i.e. fast, wear-out-less, power-outage safe. (Customizable like Alpine linux in “diskless” mode)

  • Reducing system footprint (smaller codebase / security / diskless operation / not 1,8GB system disk requirement)

  • 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)

  • 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](https://firehol.org/#firehol).)

I guess you can see that I think it is interesting to combine flexible, compact system things AND the good pre-configuration and UI (of IPFire).

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. (Even if you’d not like to actually build from the Alpinelinux aports, the path taken by Adelelinux ([faq item](https://www.adelielinux.org/about/faq.html#start)) could still provide a good example.)

2

All ready small .img file to run from flash.
Not sure but it probably is running from ram disk depending on addons.
  • 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](https://firehol.org/#firehol).)
1 Like
3

Hello, let me say that I found IPFire is already working great. I can’t point out any real flaws, really. There are only some gaps to be the ideal firewall thing :slight_smile: .

The flash image you linked is the image that I used. It’s 1,8GB uncompressed. After booting, it is using all the partitions (mounted), so the system can’t be on read-only storage for example.

IPFire’s firewall grouping feature is certainly one of the best (and really, it is even OK after having used firehol, but imagine the IPFire group UI would write its lines to (and read them from) a firehol.conf… (quick-change form editing and comfy complex text file configuration editing combined).

4

Yep. not read only.
Would be interesting. For some basic firewall. like OpenWRT that would work.
But not here. IPfire is very much into their internal proxy.(Squid).
Much like other open source firewalls/routers. their is a corporate interest.
If you drop the PSB based routers OSes and talk Linux. this is the most user friendly Firewall
OS. I wish their was more interest in supporting IPfire. But that is not the case.
So we hare few options. No man power and cash to support multiple flavors of IPfire.
Like ARM and i386. Hello people i386 is dead. When 2GB of ran in 64 bit os eats 32 bit
Performance in the same hardware it is over.
Sorry for the rant.
Glad you like IPfire.

5

My concern wasn’t strictly (only) an all-read-only system. Having a writable cache and data partition (like the alpine “data disk” mode) is good, could even be mounted noexec. Thought more about guaranteed power-outage and hot-plug resistance, or upgrading of the read-only system disk and reboot.

6

Hi,

welcome to the IPFire community. :slight_smile:

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… :slight_smile:

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. smtp) in /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. :expressionless:

Anyway, thank you for your suggestions. I hope IPFire is good enough to be used by you today. :slight_smile:

Thanks, and best regards,
Peter Müller

6 Likes
7

Hello, and best wishes for the holidays,

I agree. As you write, IPFire actually is “good enough” for me today. I’d like it to run from a used 2GB mSATA SSD on espressobin hardware, with an image backup on sdcard. Though, I am not yet that sure about tomorrow, as it has to run in our closet, and experience says, over the year there is always someone to pull the power cord or something that burns a fuse, etc. So I’m concerned if IPFire can always reboot without intervention, so it will work even if only part of the family is home.

With the “selfhost” distros that are available now, and better suited, and the virtualization, I think the desire to have additional user services running on the firewall isn’t there that much anymore, these days.

But ok, it’s ok not to make best use of the good work of more distro maintainers. If everyone wants to keep IPFire on the same road as in the past years.

Sorry, my writing was misleading, yes, firehol does not do package inspection, it only features admin friendly iptables management (similar to IPFire).

It’s hard to gauge from my user/admin perspective. But if you were once building from a heavily customized fork of a very generic distro, I can imagine the diffs kept growing and harder to maintain over time. And that there were no new usefull router and firewall feature updates coming in from LFS and IPCop.

From my user view it clearly looked as if it could ease the work of the IPFire team, if it were relatively easy to make IPFire build from a nicely matching and maintained router distro. (Especially, after reading Adelie seems to do well by working with APORTS tree patches.)

Personally, I was pleasantly surprised from the alpine linux routing and SBC-boards support with the “lighter” musil C; it’s not only the broader plattform support, as well as the diskless and (/var) data disk mode, besides the regular sys disk mode install.

https://wiki.alpinelinux.org/w/index.php?search=router

I even saw a Web Configuration Framework said to be well suitable also for small systems Alpine Configuration Framework Design - Alpine Linux

Also my wish for firehol, for example, may at first only have been just me not wanting to re-write my current firewall rules from firehol on OpenWRT in the IPFire web frontend. However, as the IPFire approach has incredible similarities, maybe it could actually make things easier to maintain in the long run, if migrating the web frontend to just configure the tried and proven firehol backend (“apk add firehol” is also already maintained in alpine, and it already supports IPv6 and ships with many service definitions out of the box, and IPFire won’t have to migrate alone to the nftables backend in the future).

Kind regards, and thank you for the elaborate response that you have written. It’s appreciated.

PS: Concerning the current “icon view”, the IPFire mascot might rather become a tux firefighter, that can control and extinguish the fire, with an ability to run upstream and inspire to become a firefighter, instead of running dizzy and catching fire :slight_smile: .

8

Unfortunately, I can’t confirm this. Because, here, it is currently, running from an USB stick and every config page (re)load takes long, while the LED on the stick is flashing until the page appears.

9

Config files are usually read at configuration only. This mode is run at small part of time.
If you know system components reading config files repeatedly, the devs ( including me ) are interested in this. We should change that an behaviour. On the the other side I do not believe ( from experience ) there are such parts. I am running my IPFire system for many years from a CF card now.

10

Hello,
thank you for your reply.

I don’t know how I could identify the IO generating component. What I see is the LED blinking and the delay on config page requests, so I’d just guess it could be something like the webserver or script interpreter reading a script.

I admit though, that the read access and a delay when loading config pages only bother a little.

What I’m afraid of being more of a blocker is, when the system can not reboot after the power got interrupted (home closet here, not data center).

Recovery boot problems seem to be a known problem, I found one post, but it has no solution, yet. Does somebody have a solution or some explaination?

11

If you selected ext3 or ext4 as the filesystem choice when you installed IPFire then your filesystem is journalled. This means that in the majority of cases of an uncontrolled shutdown when the computer restarts it will recognise the dirty shutdown and will replay the journal to fix your filesystem.

You can tell if you have a filesystem with a journal if you run:-

dumpe2fs /dev/sdax | grep features

replace the x in the partition specification with the partition number of your / and /boot partitions.

If you have journalling then under Filesystem features: you should find has_journal

This is what mine shows:-

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Journal features:         journal_64bit journal_checksum_v3

It can happen that corruption from a power loss is great enough that the journalling cannot fix it or the journal itself is damaged. In this case you would need to run fsck with a repair option interactively so you would need console access to do that. This really should not be done automatically because it can cause more damage than it fixes. It must never be done with a mounted filesystem as it can damage your files - the opposite of what you want to achieve.

The only real protection against power loss is to have a UPS (Uninterruptible Power Supply). Of course that has a cost attached to it and you have to balance that against the “costs” associated with a power loss, including the likely frequency etc.

12

Thanks, I see, since my sdcard is not detected for now a journal would actually be possible on a HDD/SSD and could help.

There is another common real protection of systems against power loss though (e.g. common battery buffered devices) I think “day-to-day” it’s using a read-only system partition (and runs from ramdisk or overlay). An example: The Alpine install with disk mode=“data”. Then “only” the separated read/write caches and logs etc. are at risk to get shortened (depending on fs guarantees), but the system should generally always be able to boot.

13

Running a OS “From” and USB stick, or other same type non error correcting flash device is not wise, with teh exception of so called live distros that create a ram disk which IPFire is not will wear out quickly with many writes, need to install on a standard hard disk or use NAND flash with error correction, SSD, type solid state drives. Can have standard SATA type connections for larger types or M.2 SSD for system boards that utilize those as well.

1 Like
14

I agree. Only took the USB flash drive, because currently lacking a propper USB device as system disk for testing (and the espressobin sdcard reader seems not to be supported by the ipfire kernel yet).

The ramdisk method is so common, that I found there even seems to be support for it in the default uboot environment.