I’ve just updated to 182 from 181.
Where is the new “block outgoing port 25” controlled - I’ve been all through the menus and I cannot find it. Or it it always on ??
Regards,
Dave
1 Like
It is for new builds only, not updates. Per the Blog “Existing installations won’t see any changes.”
And I believe it is always enabled - no WebGUI. But I have not reviewed the code.
see:
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=726c4b0f4ab6cc53ccf0b756b585681591226966
EDIT: I may be wrong. I kinda looks like a Firewall Rule. Hopefully @pmueller can add some light!
4 Likes
I have the same question.
Where can I deactivate this option?
Or what needs to be done to make it work again?
We have a real mail server behind the orange network. What do I have to configure so that it still works as before after the update?
Create a firewall rule that allows outgoing port 25?
If you have just done an upgrade from CU181 to CU182 it won’t affect you. It only applies to fresh installations of CU182.
I would suspect if you need to overcome it on a fresh installation then you would create an outgoing firewall rule that allows smtp port 25 to occur from orange to red and that rule would be placed in the appropriate custom chain in firewall.local
but it would be good if @pmueller could confirm.
3 Likes
I am curious about this too!
The new default blocking rule makes sense for typical installs but there should be documented override rule(s).
A common usage scenario is an Email server in the Orange DMZ
Incoming email (portfw SMTP) from an upstream SPAM filter or Relay and Outgoing email to an upstream SMTP Relay server - both directions using TCP port 25.
Once I figure out how it works, then I can document it in the Wiki. Still waiting for @pmueller to respond.
1 Like
The comments and questions being raised here are reasonable ones to make.
It is a shame that they weren’t raised when the Core Update 182 Testing announcement was issued. That had the same wording in it.
Then the improvements being discussed could have been made as part of the Testing evaluation and would have been in place for the Full Release.
2 Likes
Why is such a stupid rule being introduced? All ISPs block outgoing 25 anyway, and this is completely obsolete nowadays as most SMTP server will accept SSL ports (which are typically NOT blocked by ISPs). So for end users, their ISP will block the port, for us running IPFire in a corporate setting this is unwanted and unneeded, and it will likely make zero persons happy. Who makes these decisions?
No they don’t all do that.
As the announcement says
We have recently seen that some installations have infected systems that send out large amounts of spam, resulting in unhappy consequences like having your firewall appear on blocklists and trouble logging into online banking.
so clearly there have been problems out there.
2 Likes
If you are running a mail server in orange with port 25 access on an existing system then NOTHING WILL CHANGE. This will only apply to new installations.
Yes there should be some info in the wiki for how to bypass it for users with real port 25 access needs, however that would have been much better to have flagged up on December 5th onwards when the Testing announcement was issued rather than waiting till the full release was made after reported issues had been fixed.
1 Like
I’ve updated several corporate installs to release 182 and email on DMZ servers is functioning normally, as expected.
The direct server to server email connections (ESMTP STARTTLS on standard port 25) are restricted by firewall rules I set in the WUI.
ISPs in my area block most incoming ‘server’ ports and some outgoing ports on residential plans, but on corporate internet plans ports are not filtered.
Due to the processing order of iptables chains/rules, the new default port 25 blocking rule cannot be overridden from the WUI.
So all that is needed is a brief explanation of where in the processing order the block happens and how to override it when needed in firewall.local using the CLI for those who need it.
Or better yet, another option for a future release, would be to add a radio button toggle (defaulted to ON) in the WUI under Firewall Options → Firewall Options for RED interface, similar to the the hostile networks option.
3 Likes
I maybe a minority in this but I would like this option on my existing firewall.
I do not run a mail server so this should not effect me.
A infected device on my LAN could.
2nd this idea.
2 Likes
Just create a DROP rule for outgoing port 25 TCP then.
As the rule has been put in as a default rule then the WUI comes after that so the normal WUI firewall rule cannot overrule that, from my understanding.
Therefore a custom chain would be needed and would have to be placed in firewall.local as per the wiki.
The points being made are all valid ones about how to bypass it if you run an outgoing smtp server or to turn it on for existing installations that don’t have smtp port 25 access required.
My annoyance is with the situation that none of this was flagged up or raised in some way during the Testing Release but has been left until the full release has been made.
3 Likes
Sorry, but I disagree. If you make such a drastic change that generally blocks a port, I naturally assumed that this would be added as an option in the firewall options, like blocking malicious networks. The fact that there are still mail servers behind fixed IP addresses (especially in business installations) is not uncommon. There’s no need to mention that.
The fact that this change does not occur during updates, but only during new installations, was also not mentioned anywhere. It would also be interesting to know why this is the case? I had previously assumed that an update creates the same software version as a new installation.
Please don’t get me wrong, I think this option makes perfect sense. It is particularly useful for private and non-professional installations. In particular, when I look at some spam waves, they usually come from private dynamic IP addresses, which suggest that infected clients/mobile phones are behind them.
Here is the quote from the Core Update 182 Testing and Core Update 182 release notifications.
Existing installations won’t see any changes.
This wording is at the end of the section entitled
New Default Policy: Blocking Email Spammers
IPFire Developers are human (they are also volunteers spending a lot of their personal time supporting this project as they all have day jobs) and mistakes can happen or are not thought about from all the potential user situations.
That is where the Testing phase comes in to flag these things up before something is fully released.
As I am obviously getting a bit wound up about this then I firstly apologise if I have upset anyone, secondly encourage everyone to read the Testing Releases and hopefully do some Testing and thirdly will stop responding to this post thread.
5 Likes
I am also a software developer and I can understand that you get annoyed when you don’t get any notes on basic things that you have overlooked yourself during a test phase. But above all, I’m annoyed with myself that such simple mistakes happen to me. And yes, it’s human.
That’s why we can talk about it here and do better. I believe and hope that it is not a big effort to include this option in the WUI as an option.
3 Likes
It’s all good, I don’t see any problems or mistakes here. 
In a future release (maybe 183) the new rule will need to be put into the Pakfire upgrade path (which then will affect production IPFire installations with email servers)
and before that time there should be a documented way to override the rule for the installations so affected.
Up to this point there was nothing to test (unless users want do a new 182 install and write their own ‘allow port 25’ rules in the CLI).
The users (with email servers) on this thread know they will be affected and are just asking about that override.
I think it is just a ‘timing’ thing and I am sure the devs will come up with an easy override option before this goes into production (Pakfire).
For most IPFire users this change will be an uneventful, additional baseline hardening of their firewall.
IPFire is awesome, as are the developers and the community. All the work that goes into this capable and reliable firewall is greatly appreciated. Thanks and cheers!
2 Likes