Portmaster & Firewalls: Optimizing WFP Driver Cooperation

Jan 15, 2026 by Editorial Team 58 views

Hey guys, let's dive into a cool topic: how firewalls, specifically Portmaster, can play nice together using the Windows Filtering Platform (WFP). I've been checking out some interesting discussions about Portmaster's WFP driver, and I figured we could chat about some design choices and how to potentially make things even better. This is especially relevant if you're curious about network security and how different firewall solutions can coexist. So, let's get started!

The Core Question: Why Terminating Actions?

The heart of the matter lies in how Portmaster's WFP driver handles filter actions. As you mentioned, the driver uses FWP_ACTION_CALLOUT_TERMINATING for both FWP_ACTION_BLOCK and FWP_ACTION_PERMIT. Now, this is a super solid approach when blocking traffic. By terminating the action, Portmaster ensures no other firewall can override the block. It's like saying, "Nope, this packet ain't going anywhere!"

However, the use of FWP_ACTION_CALLOUT_TERMINATING with FWP_ACTION_PERMIT creates a "force allow" scenario. Once Portmaster says "permit," no lower-weight firewall can step in and block the traffic. It's as if Portmaster is giving the green light, and that's the final say. This design choice is critical in understanding how Portmaster interacts with other firewalls and it has implications for its overall security posture and how it integrates with other security tools you might be running. This is the crux of the design decision we're investigating.

Understanding the Implications of Force Allow

So, why does Portmaster use this "force allow" behavior? It might be intended to prioritize its own rules and ensure specific connections are always allowed, regardless of what other firewalls might dictate. This could be crucial for applications that are designed to always have a reliable network connection. The driver's design assumes it knows best and that it should be able to override any other potentially conflicting decisions. By ensuring that any decision made in favor of allowing traffic is strictly enforced, the goal is often to prevent accidental blocking of approved traffic by other security components or even by the operating system itself. It's a trade-off, really: increased control for potential compatibility issues.

The downside is that it can limit the flexibility and cooperation of firewalls. If you're running multiple firewalls, each with its own set of rules, the "force allow" behavior might cause unexpected behavior and conflicts. Imagine one firewall blocks a connection, but Portmaster's rule permits it. The result? You might still see the connection. This can be confusing and makes it trickier to troubleshoot network issues. The implications of this are that any other firewall has to be installed first to make sure they can block anything that Portmaster may later allow. This can cause compatibility issues and problems.

Exploring Alternative Approaches for Firewall Cooperation

Now, let's explore possible solutions, especially if we want Portmaster to play more nicely with other firewalls. The goal here is to give other firewalls a chance to weigh in, even if Portmaster has already given the "permit" verdict. We'll look into two potential approaches:

Option 1: Cooperative Permitting with `FWP_ACTION_CALLOUT_UNKNOWN`

This first approach aims to provide more cooperation with other firewalls. Here's how it would work:

Filter Action: FWP_ACTION_CALLOUT_UNKNOWN. This is important because it tells the WFP that the driver is not making a final decision. Instead, it is asking for the WFP to keep processing and consulting other layers.
No Flag: Don't use FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT. This flag is the one that forces the action. By not setting it, Portmaster allows other layers to make their own decisions.
Possible Callout Verdicts: FWP_ACTION_BLOCK, FWP_ACTION_PERMIT. This means Portmaster can still block traffic, which is a key function. However, if Portmaster permits traffic, it doesn't force it through. Other firewalls or WFP layers can still block the traffic if they have a reason to.

In this model, the block is still final. The permit becomes more of a "continue" signal. It tells WFP to keep processing and consult other filters before allowing the traffic. This lets other firewalls have a say, enhancing cooperation. This approach increases the collaboration between security layers, allowing for a more layered and comprehensive security approach. This also reduces potential conflicts between different firewall applications.

Option 2: Force Allow with `FWP_ACTION_CALLOUT_UNKNOWN`

If the "force allow" behavior is critical, this option offers a way to maintain it while still allowing a degree of cooperation:

Filter Action: FWP_ACTION_CALLOUT_UNKNOWN
Use Flag: FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT
Possible Callout Verdicts: FWP_ACTION_BLOCK, FWP_ACTION_PERMIT, FWP_ACTION_CONTINUE

In this version, FWPM_FILTER_FLAG_CLEAR_ACTION_RIGHT is set. This means that if Portmaster permits the traffic, it is a final decision and the traffic is allowed. If Portmaster blocks the traffic, that's final too. However, the FWP_ACTION_CONTINUE verdict is where the cooperation comes in. If Portmaster chooses to continue, it's not making a final decision, and other layers can still block the traffic. It still allows Portmaster to do a force allow when needed but introduces the option to allow other layers to participate.

This second option is useful when you want to make sure your important traffic gets through. You can still set the rule to permit traffic. This would act as a force allow, making sure that your traffic goes through. However, you also have the ability to make Portmaster more cooperative. The FWP_ACTION_CONTINUE verdict makes it so you can be more flexible.

Making the Right Choice: Balancing Security and Flexibility

So, which solution is better? It depends on the specific priorities. If the "force allow" behavior is critical for Portmaster's functionality, then the second option offers a good balance. It provides the option to force allow when needed while still providing more flexibility.

If the goal is to make Portmaster more cooperative and allow other firewalls to participate in decision-making, the first option might be the best route. This approach would require a bit of rethinking of how Portmaster handles permit actions, but it could lead to better compatibility with other security tools. In the end, it boils down to making a well-informed decision that fits your security goals and requirements.

Conclusion: Looking Ahead

Whether to use the FWP_ACTION_CALLOUT_TERMINATING approach or one of the alternatives, we're all about improving network security. By considering different filter action choices, we can build more powerful and flexible firewalls that can work together to keep our networks safe. Whether it is through a collaborative approach or a more decisive one, the possibilities are exciting.

This is just a starting point for discussions on firewall design. It's a fascinating area to explore, and I hope this sparks some interesting conversations and insights. I am excited to hear your thoughts and to keep the discussions going.