Default behavior

I know ipfire3 is supposed to come … but I’m waiting for it for years. (It’s like waiting for Godot).
Until then, some improvement on ipfire2’s WebUI might ease the strongest pain:

  1. /cgi-bin/logs.cgi/firewalllog.dat
    It would be helpful if for the local (192.168.0.0; 172.16.0.0; 10.0.0.0) hosts the corresponding hostname from /cgi-bin/hosts.cgi would be displayed there. This does not require an elaborate DNS query.
    Also a possibility to filter by address and/or firewall rule would be helpful here.
  2. in the same place:
    If you click an address in the source column and are directed to the whois page, there is a << link at the very bottom of that page. But this does not jump you back to the firewall log but redirects you to the ipfire WebUI home page. (Wtf)
  3. at the proxy settings /cgi-bin/proxy.cgi in the paragraph Destination ports, are two fields ‘Allowed standard ports’ and ‘Allowed SSL ports’ After I have read a lot in the wiki and in the forum it appears to me so that the designation ‘Proxy’ and ‘Transparent proxy’ would be clearer.
  4. oh what here could still be 123 improvement requests …

I am aware that the creation of a FW-WebUI is a lot of work, (for which I lack not only the time, but also the ability) but I think that ipfire deserves a (much) better WebUI.
I think it makes more sense to create a better administration environment for ipfire than to keep adding new features whose administration is then squeezed back into this horrible WebUI. (Working with it is really no fun. And that again lowers the security).

Translated with DeepL Translate: The world's most accurate translator (free version)

Unfortunately the developers that are able to work on it can be counted on the fingers of one hand. All of them have day jobs that are needed to pay their bills.
At the same time if there are security/privacy/major bug problems that need to be resolved on IPFire 2.x then those must be resourced and worked on by those same developers.
IPFire3 is being very significantly worked on. Just look at the commits being done in the IPFire 3.x git repository.
https://git.ipfire.org/?p=ipfire-3.x.git;a=shortlog

There have been around 450 commits so far this year and significant progress is being made.

However, yes you are right it is not here yet.

This might be something that I could take a look at. These things always sound much easier than they end up being due to the historic nature of the WUI coding that has built up with bits added on over a couple of decades. (Hence why IPFire 3.x is a from the ground up build). I will put it on my todo list.

This sounds like a bug to me. Please raise a bug report against this so it is recorded.

SSL based ports are also specified and needed for Conventional mode so the labelling I believe is correct as it is.

You can always support with a donation.
https://blog.ipfire.org/post/changes-to-our-donation-process

3 Likes

Where is the correct place to raise a bug?

Maybe … I struggled with this labelling …

I have done this month / years before … but waiting for ipfire3 until today :wink:

https://wiki.ipfire.org/devel/bugzilla

Your IPFire People email address and password will work as credentials for logging into the IPFire Bugzilla.

1 Like

bugid: 13081

1 Like