Restore old Portmaster Incoming Rules behavior

[Arcitec]

The recent change to how incoming connections work have broken Portmaster for me:

https://docs.safing.io/portmaster/settings#filter/blockInbound

I have lots of system features such as KVM Virtual machines which I cannot "just allow the application, bruh" for because Portmaster just sees them as Network Noise without application association.

Before your change, Portmaster was perfect. I allowed the exact ports I needed to have open incoming in the global rules. Everything worked perfectly. And the "block everything" setting even worked perfectly, by disallowing my incoming rules while on untrusted public networks like WiFi.

After your change, I see that all incoming global rules are totally ignored and pointless, and that all connections are always blocked systemwide now, and that the intended way is to allow certain apps to have incoming connections per app. The global incoming rules have no purpose anymore since you have killed the feature.

The only thing I can do is to disable your global blocking and set a default rule of "block everything else". But you helpfully decided to make Portmaster nag if I do that.

I am annoyed that the change wasn't better thought through and was pushed and broke systems without warning.

There are plenty of applications that Portmaster will never identify, and with your new system there is no way to allow their incoming connections. They will forever be blocked. Since Portmaster never allows so-called "Network Noise" connections anymore.

Please revert the change and think about a better solution. A change like this will only work if you can figure out the "Network Noise" problem of how to classify traffic with an unknown app. And since you are unlikely to figure that out (for obvious reasons), there is no way that your new "block all traffic not associated with any apps" will ever be a good idea or ever work. Having a per-app "allow/disallow all incoming connections" feature is very good, but you ALREADY HAD THAT. It was ALREADY possible to go to each app and just allow that entire app. You didn't have to break your Global Incoming Rules feature! This change was so shoddy that if there is no revert or improvement of this breaking change then I am gonna uninstall Portmaster and switch back to firewalld. I lost a lot of confidence in Portmaster after seeing such a sloppy change. It should be very obvious to you too that blocking all traffic is a bad idea when so much traffic is identified as "Network Noise" and therefore no longer possible to allow/unblock via your new system.

Edit: Alternatively, change the whole code of the "block everything" flag so that the Global Incoming Rules override it. Because the whole issue is that it thinks that it knows better than the global rules, and just blindly blocks everything even if global rules have been added. That behavior is of course a relic from the fact that you have repurposed the "lockdown all rules on unsafe networks" feature, which made sense as a feature on unsafe networks, but makes no sense on trusted home networks where users WANT to have their global Incoming Rules.

It looks like you have just repurposed the "ignore global rules and block everything while on untrusted networks" feature into "block on home networks too", which was an improper change. This doesn't just break professionals. Plenty of consumer apps break.

Example: I am sure that Boxes virtual machines on GNOME will no longer work either, since they use KVM internally. Now all of their connections are helpfully blocked by Portmaster, due to being "Network Noise" at the kernel level, and therefore all your VMs will not have any internet connection anymore.

Furthermore: Because you decided to permanently block incoming connections and removed the Global Rules feature, you have now made it impossible to secure your computer on unsafe networks. Everything is now permanently allowed on all networks if you go into an app and just allow all of its connections. So this was such a bad change on so many levels.

TL;DR: Portmaster was already perfect. Users could already do a combination of Global Incoming Rules for all apps, or selecting specific apps and choosing "Allow All Incoming" for specific apps without having to write rules if they didn't want to. So it makes no sense why you basically just deleted the Global Incoming Rules feature even though tons of network connections are never gonna be identified as belonging to apps in Portmaster, and are therefore permanently blocked now. Systems have broken as a result of this, and if the change stays, I am out of here and will stop recommending Portmaster. Yes it's that serious. Portmaster is no longer a serious firewall.

Sorry for not holding back my words. It probably hurts to read this. But it also hurt that I have wasted hours migrating to Portmaster and setting it up perfectly and was loving the app and recommending it to so many people, but then suddenly getting a severely broken machine thanks to a very badly implemented change. That is a serious issue for a firewall, and I hope that you look at the two proposed solutions. Either reverting the change (best since it was done for no good reason, broke Incoming Rules, broke Network Noise traffic, and broke Unsafe Network Blocking), or at least make rules take precedence over the silly, repurposed "lock down all rules" checkbox which no longer works intuitively and was broken for no reason, since Portmaster already had the exact feature you tried to implement. You already HAD the ability to allow all connections per app with a simple toggle without having to write any rules.

Your reaction will determine whether I uninstall Portmaster and apologize to everyone that I recommended it to, or if faith in your company can be restored.

[dhaavi]

Hey there, thanks for voicing your concerns and thoroughly documenting your case.

I am very sorry this broke your use case and has been frustrating for you! This is not what we intended.

such as KVM Virtual machines which I cannot "just allow the application, bruh" for because

Let me start by pointing out that you are using Portmaster outside of the currently officially supported use cases: #166.

Portmaster just sees them as Network Noise without application association.

Network Noise holds incoming connections that no process is listening for.
You should not be needing to allow anything in there, as it would have no effect.
If real connections land in there, please open a bug.
(In some edge cases it would also get incoming connections that failed to attribute.)

Before your change, Portmaster was perfect.

I believe it still is.

I allowed the exact ports I needed to have open incoming in the global rules. Everything worked perfectly. And the "block everything" setting even worked perfectly, by disallowing my incoming rules while on untrusted public networks like WiFi.

Adapting to different environments will be solved in a different way in the future.

After your change, I see that all incoming global rules are totally ignored and pointless, and that all connections are always blocked systemwide now, and that the intended way is to allow certain apps to have incoming connections per app. The global incoming rules have no purpose anymore since you have killed the feature.

The global incoming rules still apply. You just have to disable Force Block Incoming Connections on the apps where you need it.

The only thing I can do is to disable your global blocking and set a default rule of "block everything else". But you helpfully decided to make Portmaster nag if I do that.

Yes, this is helpful for most people. Please elaborate on your use case how you intend to use this feature.

I am annoyed that the change wasn't better thought through and was pushed and broke systems without warning.

Portmaster is still in "Alpha", even if it feels that way. This lets us move forward quickly. There was a migration warning on the upgrade to make you aware of the change.

There are plenty of applications that Portmaster will never identify, and with your new system there is no way to allow their incoming connections. They will forever be blocked. Since Portmaster never allows so-called "Network Noise" connections anymore.

Can't follow here. Please elaborate.
You can allow "Network Noise" connections, but it will have no effect, as explained earlier.

sloppy change

We actually took a decent amount of time to think about and think this change will benefit a lot of users who are not technically adept enough to easily understand how rules work.

It looks like you have just repurposed the "ignore global rules and block everything while on untrusted networks" feature into "block on home networks too", which was an improper change. This doesn't just break professionals. Plenty of consumer apps break.

Consumer apps and most professional apps do not need incoming connections.

Example: I am sure that Boxes virtual machines on GNOME will no longer work either, since they use KVM internally. Now all of their connections are helpfully blocked by Portmaster, due to being "Network Noise" at the kernel level, and therefore all your VMs will not have any internet connection anymore.

Referencing #166 again.

Furthermore: Because you decided to permanently block incoming connections and removed the Global Rules feature, you have now made it impossible to secure your computer on unsafe networks. Everything is now permanently allowed on all networks if you go into an app and just allow all of its connections. So this was such a bad change on so many levels.

I believe it actually makes using these features a lot more secure, as it is harder to misuse them. If you allow one app to have incoming connections, this is what you want. If the app is LAN only, just flip the Force Block Internet Access switch. This is a lot easier to do than using rules and will make most users make more secure settings.

But it also hurt that I have wasted hours migrating to Portmaster and setting it up perfectly

I'm sorry this has been a frustrating experience for you. We had hoped that our prominent use of the "Portmaster is in Alpha" label would have created more caution for such cases.

Your reaction will determine whether I uninstall Portmaster and apologize to everyone that I recommended it to, or if faith in your company can be restored.

If you take a moment to reflect on that, you will quickly realize that this is a childish threat and we don't owe you shit. Neither do you owe us shit. If Portmaster is not a good fit for you anymore, this is unfortunate. I'm sure your friends can evaluate this themselves.

In Closing: This change was done to help non-technical users to more easily work with Portmaster and improve their experience, ultimately making them safer and more private, which is our dedicated goal. We are sorry this change has negatively affected you.

[Arcitec]

1. It is easy to forget that Portmaster is Alpha since it was so polished before this change. I realize that you have the right to break things in alphas. I still think that the change is very bad and I'll explain why.
2. This is not about trying to make the host be the firewall for VMs or their traffic. It's about trying to have VMs whatsoever. VMs on Linux (KVM), i.e. Boxes, Virt-Manager, and probably others, work by assigning an extra IP to the host machine, and then the VMs connect to it. In the case of KVM (the kernel-based virtual machine that Boxes etc uses), it means that your host gets IP 192.168.122.1 and becomes the gateway for all VMs internet traffic. From the perspective of the guest, the VM is browsing the internet with 192.168.122.1 as its router. And from the perspective of the host, they are receiving incoming connections from 192.168.122.0/24. This is classified as Network Noise by Portmaster. If it's blocked on the host, the VMs don't get routed onto the internet and they can't even contact the host either for features such as folder sharing. With the new Portmaster change, this is blocked as Network Noise. I can go in and enable incoming connections for ALL Network Noise, sure, but that lowers security by indiscriminately allowing all unclassified (non-app) traffic to get through the firewall no matter what.
3. It is also about the fact that Network Noise is unavoidable. Some things will never be properly attributed to a process by Portmaster. So the simplistic "per-app toggle without any global rules" doesn't fit there.
4. Yes, I realize that global rules that apply for all apps is less secure in some ways, since any app can then listen on ports allowed by the global rules. But on the other hand, that's normal and is how all other firewalls work: You set port ranges that you want to allow and then block the rest, so that you don't get unexpected attempts to hammer port 23 (SSH), 80 (HTTP) etc. The fact that unintended applications could then use your allowed incoming ports isn't a serious concern. A firewall is more about preventing unexpected traffic on default daemons that you didn't want to expose globally. Which app listens on the open ports is a much smaller concern.
5. In fact, the per-app "allow everything" toggle you're aiming for might be easy for newbies, but it's also less secure, because you're allowing every port for that application, as mentioned. It might not be what you want. I'd say the security concern is similar to the one you voiced about "global rules". It's not good to get unexpected listening ports via blanket "allow every port for this application" toggles.
6. Regarding the different-networks security zones, it's good to hear that you are planning to implement that a different way. It was a good feature.

Here's a proposal for a way to fix the Network Noise problem, and to get the best of both worlds (both toggles and rules):

1. Keep the per-app Force Block Incoming Connections. Make it stronger than PER-APP RULES. But weaker than GLOBAL RULES.
2. Delete the global Force Block Incoming Connections toggle and have it always enabled internally, so that you always block everything by default in all applications.
3. Make the global Force Block Incoming Connections weaker than Global Rules. This way, global incoming rules such as 192.168.122.0/24 can be added so that virtual machines can connect to the internet, by always allowing traffic that comes from the virtual machines. Being able to write global rules, like all other firewalls, is also way easier than trying/hoping that Portmaster finds your apps and trying to find them in the list and adding exceptions for them. It's very tedious to have to wait for apps to show up in the per-app list. I exclusively use global rules since I am not interested in per-app incoming rules, since it's way more hassle to look up the configured rules or edit things that way.
4. If there are any global incoming rules, display a text-notice on all per-application pages to say/show that "the following global rules are always active: 80/TCP, etc...", since the global rules have precedence over per-app rules/blocking.

Here's how I was using Portmaster: For incoming connections, I only used global rules. For outgoing connections, I used per-app blocking of certain domains to prevent certain apps calling home, but I only did that for 1 app, so it was manageable.

With the proposed system, people could enjoy both workflows: Go into an app and do a blanket "allow all incoming connections" if they want. Go into an app and add specific rules if they want. Or go global and write global incoming rules that apply to the entire system if they prefer working the way all other firewalls do (that's me). Looks like win-win in my opinion.

Do you have any other solutions except the one I just proposed, which would achieve the same solution of making it easy to manage "Network Noise" and allowing port/IP traffic in a proper fashion?

Since this is Alpha software, there needs to be iterations on the design. The new system doesn't feel good at all. It's very limiting and clunky. A system which allows global and per-app rules to co-exist and allows global rules to be truly global (always active) would be the best solution. That way, Portmaster is both a normal firewall (global rules) and an application-level firewall (per-app blocking).

It's clear that the new design needs iterations and reworking until it's convenient. At the moment, Portmaster is too much of a hassle.

By the way, I know that my tone was bad in my original message, and I apologize. But calling it a "childish threat and we don't owe you shit" and brushing off the situation as "you're using it wrong" didn't help restore any faith. Perhaps you just misunderstood what the issue is. What did help though, is that you tried to give a detailed reply, so I'll say overall I haven't gained or lost any faith in Safing. I'll wait and see if this can be solved in any way with your new system. For now, I'll disable Portmaster and enable firewalld again, but I've kept the app and config if there will be a way to fix it.

[Arcitec]

@dhaavi Here's a look at my global Incoming Rules. It was an elegant way to configure Portmaster. I only used the per-app clunkiness when blocking outgoing connections from specific applications (exactly what an application-level firewall is useful for).

The rules, especially the * */1025-65535, are intentional. It's exactly how firewalld is configured by default on Fedora Workstation and Red Hat Enterprise Linux.

Upon further reflection, I realize that it will probably take a long time for Portmaster to resolve the concepts of a traditional global firewall vs per-application toggles and rules, and which should have priority over which, etc. The old system you had worked really well. But the new state is a mess, with global rules basically being dead.

Perhaps the easiest solution would be to allow professionals to do the following:

1. Disable the global Force Block Incoming Connections without being nagged about it.
2. Adding a "default block" global incoming rule to get back the old pre-change behavior.

I think those two steps would restore the behavior of previous Portmaster versions... I am going to try it now.

[Arcitec]

Alright, I am trying the following. Hopefully this brings back the great old system where global rules took effect for all applications, and per-application rules were added after the global rules to allow per-app changes.

If this works, then the only remaining awful thing is the weekly nagging.

Edit: This seems to work. It may be killing per-app incoming rules since the Block * global rule matches globally and drops the connection. Whether per-app rules work depend on whether those rules are allowed to override connections that already matched a global rule. For example, if Portmaster checks per-app rules before it checks Global rules, then a per-app "allow port X" rule would take precedence over the global Block * rule. I don't know if that is how it works. But since I only write rules globally, this is fine for me even if it might break per-app incoming rules... The only thing I do per-app is to write outgoing rules.

[dhaavi]

1. It is easy to forget that Portmaster is Alpha since it was so polished before this change.

We realize that and there will be a change in the near future.

I realize that you have the right to break things in alphas. I still think that the change is very bad and I'll explain why.

I'm ready to listen (or read, in this case).

2. This is not about trying to make the host be the firewall for VMs or their traffic. It's about trying to have VMs whatsoever. VMs on Linux (KVM), i.e. Boxes, Virt-Manager, and probably others, work by assigning an extra IP to the host machine, and then the VMs connect to it. In the case of KVM (the kernel-based virtual machine that Boxes etc uses), it means that your host gets IP 192.168.122.1 and becomes the gateway for all VMs internet traffic. From the perspective of the guest, the VM is browsing the internet with 192.168.122.1 as its router. And from the perspective of the host, they are receiving incoming connections from 192.168.122.0/24. This is classified as Network Noise by Portmaster. If it's blocked on the host, the VMs don't get routed onto the internet and they can't even contact the host either for features such as folder sharing. With the new Portmaster change, this is blocked as Network Noise. I can go in and enable incoming connections for ALL Network Noise, sure, but that lowers security by indiscriminately allowing all unclassified (non-app) traffic to get through the firewall no matter what.

I understand. Thank you for elaborating.
There are many ways how VMs handle this - most of which just bypass current Portmaster architecture by default.
An alternative workaround could be to change the network integration type of your VMs, if possible.
If you can get them to use the iptables forward chains, this would currently simply bypass Portmaster. I'm not sure why this isn't the case with you, as it seems the host is only forwarding traffic and not the source of it - but I'm not expert in VM technologies.

3. It is also about the fact that Network Noise is unavoidable. Some things will never be properly attributed to a process by Portmaster. So the simplistic "per-app toggle without any global rules" doesn't fit there.

The toggles set the scene, the rules specify the details.

4. Yes, I realize that global rules that apply for all apps is less secure in some ways, since any app can then listen on ports allowed by the global rules. But on the other hand, that's normal and is how all other firewalls work: You set port ranges that you want to allow and then block the rest, so that you don't get unexpected attempts to hammer port 23 (SSH), 80 (HTTP) etc. The fact that unintended applications could then use your allowed incoming ports isn't a serious concern. A firewall is more about preventing unexpected traffic on default daemons that you didn't want to expose globally. Which app listens on the open ports is a much smaller concern.

Well. I think finding out which ports an app needs is a lot of work for non-technical people. They can just use the toggle and whatever port the app needs is allowed.
Daemons that should not be exposed will never mistakenly allow connections, as the rules are bound to the binary.

This is just thinking about the problem the other way around. And yes, it is different that other firewalls. But we're not building yet another boring firewall after all. ;)

5. In fact, the per-app "allow everything" toggle you're aiming for might be easy for newbies, but it's also less secure, because you're allowing every port for that application, as mentioned. It might not be what you want. I'd say the security concern is similar to the one you voiced about "global rules". It's not good to get unexpected listening ports via blanket "allow every port for this application" toggles.

I see we have different opinions on this.

Here's a proposal for a way to fix the Network Noise problem, and to get the best of both worlds (both toggles and rules):

1. Keep the per-app Force Block Incoming Connections. Make it stronger than PER-APP RULES. But weaker than GLOBAL RULES.

This breaks with the model how all these settings are inherited and will be very confusing.

2. Delete the global Force Block Incoming Connections toggle and have it always enabled internally, so that you always block everything by default in all applications.

Yes, this would be a nice thing to do, but we currently don't have a way to do that easily.
(Also, this would break your other attempt below.)

3. Make the global Force Block Incoming Connections weaker than Global Rules. This way, global incoming rules such as 192.168.122.0/24 can be added so that virtual machines can connect to the internet, by always allowing traffic that comes from the virtual machines. Being able to write global rules, like all other firewalls, is also way easier than trying/hoping that Portmaster finds your apps and trying to find them in the list and adding exceptions for them. It's very tedious to have to wait for apps to show up in the per-app list. I exclusively use global rules since I am not interested in per-app incoming rules, since it's way more hassle to look up the configured rules or edit things that way.

If you are configured your rules just for the VMs, can't you just add them all to the "Network Noise" app, as their connections will never be attributed anyway?

4. If there are any global incoming rules, display a text-notice on all per-application pages to say/show that "the following global rules are always active: 80/TCP, etc...", since the global rules have precedence over per-app rules/blocking.

As stated before, this breaks the inheritance model and would cause confusion.

Here's how I was using Portmaster: For incoming connections, I only used global rules. For outgoing connections, I used per-app blocking of certain domains to prevent certain apps calling home, but I only did that for 1 app, so it was manageable.

With the proposed system, people could enjoy both workflows: Go into an app and do a blanket "allow all incoming connections" if they want. Go into an app and add specific rules if they want. Or go global and write global incoming rules that apply to the entire system if they prefer working the way all other firewalls do (that's me). Looks like win-win in my opinion.

Do you have any other solutions except the one I just proposed, which would achieve the same solution of making it easy to manage "Network Noise" and allowing port/IP traffic in a proper fashion?

I think what you described below is a good solution.
I also still think that unticking "Force Block Incoming Connections" on the few apps that need it is still a good barrier to cross to make handling secure. I understand though, that you don't feel like this.

Since this is Alpha software, there needs to be iterations on the design. The new system doesn't feel good at all. It's very limiting and clunky. A system which allows global and per-app rules to co-exist and allows global rules to be truly global (always active) would be the best solution.

Global rules are active, but the force blocks still serve as an override or safeguard.

By the way, I know that my tone was bad in my original message, and I apologize. But calling it a "childish threat and we don't owe you shit" and brushing off the situation as "you're using it wrong" didn't help restore any faith. Perhaps you just misunderstood what the issue is. What did help though, is that you tried to give a detailed reply, so I'll say overall I haven't gained or lost any faith in Safing. I'll wait and see if this can be solved in any way with your new system. For now, I'll disable Portmaster and enable firewalld again, but I've kept the app and config if there will be a way to fix it.

I did not mean to "brush off the situation" - sorry if this is what you interpreted. I did and am still trying to get to the bottom of the issue.
To be honest, demanding change with an "or else I will do this" does have a very childish vibe. I'm sorry if I interpreted this wrong, but this is what I saw in there. An "Oh no, you broke my use case, can I have it back, please?" is very different in tone.

Perhaps the easiest solution would be to allow professionals to do the following:

1. Disable the global Force Block Incoming Connections without being nagged about it.
2. Adding a "default block" global incoming rule to get back the old pre-change behavior.

I think this is a good approach.
I can offer to disable the warning notification when the UI Mode is set to "Developer Interface" in the settings (not just in the current view).

Alright, I am trying the following. Hopefully this brings back the great old system where global rules took effect for all applications, and per-application rules were added after the global rules to allow per-app changes.

Correct. This will effectively get you the behavior from before the change.

[Arcitec]

@dhaavi

I understand. Thank you for elaborating.
There are many ways how VMs handle this - most of which just bypass current Portmaster architecture by default.
An alternative workaround could be to change the network integration type of your VMs, if possible.
If you can get them to use the iptables forward chains, this would currently simply bypass Portmaster. I'm not sure why this isn't the case with you, as it seems the host is only forwarding traffic and not the source of it - but I'm not expert in VM technologies.

By default, KVM creates a virtual network adapter called a "Bridge", and creates a DHCP+NAT server on that adapter, which the guests then use as "their router". This is done for security, since it means that the guests cannot connect directly to the physical network. Everything is translated via NAT so that the guest is isolated and cannot be seen or talk to the real network, and can only access the internet (via the host translating things for the guest). :) In Portmaster, that's what shows up as "Network Noise" on the 192.168.122.0/24 network.

Here's the bridge adapter KVM uses (on the host):

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.122.1  netmask 255.255.255.0  broadcast 192.168.122.255
        ether 52:54:00:95:66:e1  txqueuelen 1000  (Ethernet)

The only alternative is to still use a bridge adapter, but removing the NAT/DHCP server, and instead bridging it directly onto the physical network, so that the guest talks directly to the real router and is visible to all real machines on your real network. Doing that might bypass Portmaster's rules, but I am not sure about that. It's undesirable though, since it breaks guest isolation and opens up risks. So I'll stick with the default NAT bridge. :)

Well. I think finding out which ports an app needs is a lot of work for non-technical people. They can just use the toggle and whatever port the app needs is allowed. Daemons that should not be exposed will never mistakenly allow connections, as the rules are bound to the binary.

This is just thinking about the problem the other way around. And yes, it is different that other firewalls. But we're not building yet another boring firewall after all. ;)

That's true... when I think about it more, you have a point that writing rules is difficult for people who don't know much about networking. Which is probably why Fedora/RedHat Enterprise Linux ships with that * */1025-65535 rule by default anyway, so that all apps "just work" and the only thing that needs special configuration is anything using service ports 1-1024 (and only if it isn't already enabled by default; since they allow a lot of service ports by default too).

I realize that this is just the first version of several steps towards an easier firewall for most people. I overreacted because my system broke pretty severely and it took hours to figure out that it was from Portmaster... so I was in a terrible mood. But I can see uses for your ideas too, and I think that your design ideas will appeal to a lot more people than the ones who want a "professional firewall" like me. :P

Furthermore, since we have figured out a workaround, it looks like I can still stay with Portmaster and just configure it in "pro mode". :)

Perhaps the easiest solution would be to allow professionals to do the following:

1. Disable the global Force Block Incoming Connections without being nagged about it.
2. Adding a "default block" global incoming rule to get back the old pre-change behavior.

I think this is a good approach. I can offer to disable the warning notification when the UI Mode is set to "Developer Interface" in the settings (not just in the current view).

Yes, please! That would help a lot. Getting system notifications to "disable your rules please" once a week would annoy me so much. ;)

Speaking of the Developer Interface mode, I'm not sure if it's fixed now, but I'll just casually mention that there were a lot of problems with switching modes when I first installed Portmaster (2 months ago now, I guess). The issue was as follows:

• Go to "Global Settings: Core: User Interface".
• Change "User Interface" to "Developer Interface".
• The dropdown in the top right of the screen would always?/sometimes? stay in the old mode. And your user interface change didn't apply, so you didn't see the new settings you should be setting, until you also went to the top right of the screen and changed that dropdown to the new mode too.

Anyway, back to the topic... :)

Alright, I am trying the following. Hopefully this brings back the great old system where global rules took effect for all applications, and per-application rules were added after the global rules to allow per-app changes.

Correct. This will effectively get you the behavior from before the change.

That is great news! I have tried it and the VMs got their internet connection back. The global rules are active. I like it!

I have a few small concerns:

1. The Block * rule must be placed at the end of the list by the user, which is unintuitive. If the user places it anywhere else in the list, it matches "early" and all other rules below it are ignored. Could this be improved by special-casing Block * in your code so that Portmaster internally re-orders that rule in its brain (regardless of where it physically sits in the list on-screen), to always run the "block everything else" rule at the end of the chain? Because it doesn't make any sense to have a Block * at the top of a rule list and therefore making Portmaster ignore all rules below it. It's also a lot of hassle to constantly have to remember to move that rule to the bottom of the physical list so that it runs last. I would personally want to put the Block * at the top of the list so that it just sits up there and doesn't have to be manually re-ordered every time I add more entries to the rules list. :)
2. I don't personally use it, but it's also possible to set an Allow * rule in the list. It would probably be necessary to internally process such a rule last too, because users may want to do something like Allow *, Block X, Block Y which should mean "Block X or Y, but allow everything else".
3. In both situations above, I am also very concerned about this workaround of adding a global Block * rule possibly breaking per-app rule processing. I don't personally use per-app rules for anything except outgoing rules, as mentioned. BUT, either way I think it make sense to do something like this: Process per-app rules first, before processing global rules. The reason is that your per-app rules could contain something like Allow FOO, and we need to be sure that such a rule is active and isn't prohibited by a global Block * rule, or any other "general global rule". For example, you might do a per-app Allow 200.100.100.100 and a global Block 200.* (just as an example of how per-app rules should matter more to allow finetuning of global rules on a per-app level).
4. In fact, speaking of point 3 in relation to point 1-2, I think the optimal processing chain would be as follows: First match per-app rules, then match per-app catch-all rules (Block * and Allow *), then match the global rules, and finally match global catch-all rules (Block * and Allow *). Hopefully that gives the optimal signal flow to ensure that all rules work logically and that per-app rules all work properly even with the existence of global rules. Per-app rules are more specific, so it makes sense for those to have higher priority than global rules.
5. If the solution in point 4 is good, it should also allow all apps to coexist with the "Force block all incoming connections" (both the global and per-app versions of it), by simply making that toggle do an internal, hidden Block * equivalent, which is added once for each app, FIRST in the chain, before ALL other rules I talked about in point 4. So the flow would be: Is this app blocked by the state of "Force Block Incoming or P2P" for that app? -> Per-app rules -> Per-app catch-all *-block/allow -> Global rules -> Global catch-all *-block/allow...

Hopefully this architecture (or a similar one) would solve everything. Portmaster could then be "for everyone" and satisfy all needs from basic to advanced...

Edit if you already read the email before my changes: I changed the flow example, to handle the per-app catch-all rules (*) before all global rules, so that it becomes possible to do Block/Allow * on a per-app basis (which would ignore all global rules) if someone wants to do that.

[loldev69]

I'm going to second the request to disable the notification nagging: it's important to remember that Portmaster is just one layer of firewall, and that other layers are likely already applying similar blocks on incoming traffic.

[Arcitec]

I had to uninstall Portmaster yesterday because of the bug where it uses 100% CPU. I've suffered that bug for over a month now (ever since version 1.0.0, and also in version 1.0.2) and across two fully updated versions of Fedora (36 and 37) and I've been unable to fix it. Most of the time I had to kill portmaster-core forcefully to regain desktop responsiveness. I finally decided yesterday that I am probably not a good fit for Portmaster's target audience anyway. I sincerely wish you all the best success with your company and with Portmaster. You seem like great guys all around and I am sure Portmaster will soon dominate the world of beginner-friendly firewalls. :)

[rwjack]

I think it makes sense that if I go into global rules, allow an IP 10.1.2.3 tcp/22, then that IP should be allowed to ssh, but that doesn't work.

It works when I disable force block incoming connections on the app specific rule and allow a single IP there and block everything else. IMHO The current way of doing it seems rather unintuitive.

[Raphty]

This issue has been stale for some time.

Rules and how they will look like in the future is a topic @dhaavi and i are in active conversation about.
For now this seems to not be an issue. Thanks for all the feedback!