ICMP traffic remains allowed despite Incoming IP BLOCK while an existing Outgoing LAN state is active Environment

[cmauro607]

Portmaster: 2.2.1
OS: Windows 10 Pro 22H2
Protocol: IPv4 ICMP
Portmaster host: 192.168.1.10
LAN peer: 192.168.1.25
Force Block Incoming Connections: OFF
Network: Same LAN / Peer-to-Peer
Configuration
Global Outgoing Rules: LAN, localhost → PERMIT
Global Incoming Rules: 192.168.1.25 → BLOCK

The objective is to prevent 192.168.1.25 from initiating ICMP traffic toward 192.168.1.10.

Expected behavior
With:
Incoming:
192.168.1.25 → BLOCK
an ICMP Echo Request originating from: 192.168.1.25 → 192.168.1.10 should be blocked.
This works correctly when no existing Portmaster connection state is present.

Initial state — Incoming ICMP is correctly blocked

Before creating any outbound communication from the Portmaster host:
192.168.1.25 → 192.168.1.10
ICMP Echo Request is blocked.
There is no Echo Reply from 192.168.1.10.
Therefore, the Incoming rule works as expected.

Reproduction

From the Portmaster host (192.168.1.10), send exactly one ICMP packet to the LAN peer:
ping -n 1 192.168.1.25
This creates an outbound ICMP communication.
Portmaster displays the resulting activity as:
LAN
Scope: LAN Peer-to-Peer Outgoing
Reason: allowed by rule: scope matches Localhost,LAN

Applied Setting:
Outgoing Rules from Global Settings
After this single outbound packet, the LAN peer (192.168.1.25) can immediately send ICMP traffic back to 192.168.1.10, despite the explicit Incoming rule:
192.168.1.25 → BLOCK
Wireshark observation
Before the outbound packet is generated:
192.168.1.25 → 192.168.1.10
ICMP Echo Request has no response.

After executing:
ping -n 1 192.168.1.25 from the Portmaster host, Wireshark immediately shows bidirectional ICMP traffic.
For example: 192.168.1.10 → 192.168.1.25 ICMP Echo Request
192.168.1.25 → 192.168.1.10 ICMP Echo Reply

When the mobile continuously pings the Portmaster host, the ICMP traffic remains successful while the corresponding Outgoing connection state remains visible in Portmaster Network Activity.

Important finding: changing the Incoming rule does not affect the existing state
While the Outgoing connection remains present in Network Activity, I changed the Incoming rule:
192.168.1.25 → BLOCK to: 192.168.1.25 → ALLOW
and then back to: 192.168.1.25 → BLOCK
The ICMP traffic continues uninterrupted.

In other words:
INCOMING .25 = BLOCK
↓
existing OUTGOING state
↓
ICMP traffic continues

Changing the Incoming rule does not appear to cause the existing state to be re-evaluated against the Incoming IP rule.
Important control test: changing Outgoing does affect the existing state
With the same existing connection still visible in Network Activity, I changed:
Outgoing LAN = ALLOW to: Outgoing LAN = BLOCK
The ICMP communication immediately stopped.

I then changed it back:
Outgoing LAN = ALLOW
The ICMP communication immediately resumed.
This occurred without waiting for the existing Network Activity entry to disappear.
Therefore, the existing state is responsive to the Outgoing policy, but changing the Incoming IP rule does not appear to affect the existing state.

This is an important distinction.

State expiration

After stopping the ICMP traffic, I waited until the existing connection disappeared from Portmaster Network Activity.
The observed duration was approximately 10–12 minutes.
Once the previous state disappeared, a new ICMP Echo Request was initiated from:
192.168.1.25 → 192.168.1.10
At this point Portmaster correctly classified the traffic as:
Scope: LAN Peer-to-Peer Incoming
Reason: denied by rule: IP matches 192.168.1.25
Applied Setting: Incoming Rules from Global Settings
The ICMP request was blocked as expected.

Reproduction summary

The complete behavior can be summarized as follows:

1. No existing state
   .25 → .10 ICMP → BLOCKED
2. .10 sends one ICMP packet to .25
   .10 → .25 → ALLOWED by Outgoing LAN rule
3. Existing state is created
4. .25 → .10 ICMP → ALLOWED while existing state remains active
5. Change Incoming .25:
   BLOCK → ALLOW → BLOCK → NO EFFECT on existing ICMP traffic
6. Change Outgoing LAN:
   ALLOW → BLOCK → ICMP immediately stops
7. Change Outgoing LAN:
   BLOCK → ALLOW → ICMP immediately resumes
8. Wait for existing state to disappear → approximately 10–12 minutes
9. New .25 → .10 ICMP connection → correctly classified as Incoming → BLOCKED by IP rule

Question / Possible issue

The key question is whether this behavior is intentional.
Specifically:
¿Should an explicit Incoming Rule blocking 192.168.1.25 be able to override or terminate reverse ICMP traffic associated with an existing Outgoing connection that was previously allowed?

The observed behavior suggests that the existing ICMP state is primarily governed by the original Outgoing verdict.

In particular:
Outgoing LAN = ALLOW
↓
existing ICMP state
↓
reverse traffic from .25 → .10 remains allowed
↓
Incoming .25 = BLOCK has no effect

Whereas:
Outgoing LAN = BLOCK
↓
existing traffic immediately stops

This appears asymmetric between the Outgoing and Incoming policies.
Why this is particularly interesting for ICMP

ICMP does not have a TCP-style connection establishment sequence.

The observed behavior therefore raises the question of how Portmaster represents and tracks an ICMP "connection" and how it determines that:

192.168.1.25 → 192.168.1.10

is return traffic associated with:

192.168.1.10 → 192.168.1.25
rather than a new Incoming communication that should be evaluated against:

Incoming:
192.168.1.25 → BLOCK

Additional information
Portmaster's Network Activity provides the following information for the state created by the outbound packet:
Scope: LAN Peer-to-Peer Outgoing
Reason: allowed by rule: scope matches Localhost,LAN
Applied Setting: Outgoing Rules from Global Settings

After the state expires, the same peer is correctly evaluated as:
Scope: LAN Peer-to-Peer Incoming
Reason: denied by rule: IP matches 192.168.1.25
Applied Setting: Incoming Rules from Global Settings

This strongly suggests that the behavior is related to the lifetime and reuse of the existing connection/verdict state rather than a permanent failure of the Incoming rule.

Expected clarification from the developers

Could you please clarify whether this is the intended behavior of Portmaster?

In particular:
Are Incoming Rules evaluated only when an incoming connection is initially established?
Is reverse ICMP traffic considered part of an existing Outgoing connection?
Should an explicit Incoming IP BLOCK override such reverse traffic?
Should changing an Incoming Rule from ALLOW → BLOCK invalidate/re-evaluate an existing state?
Is the observed behavior specific to ICMP, or is it expected for other protocols as well?

Conclusion

The Incoming rule itself is demonstrably working for new connections.
The issue/behavior occurs only while an existing Outgoing LAN state remains active.
The most significant observation is:

Incoming .25 = BLOCK
+
Existing Outgoing state = ALLOW
↓
Reverse ICMP traffic = ALLOWED

Changing the Incoming rule does not affect this existing state, while changing the Outgoing LAN policy immediately does.
Once the existing state expires, the same traffic is correctly blocked by the Incoming rule.
This appears to be a state/verdict interaction rather than a simple failure of the Incoming firewall rule.

[github-actions]

Greetings and welcome to our community! As this is the first issue you opened here, we wanted to share some useful infos with you:

• 🗣️ Our community on Discord is super helpful and active. We also have an AI-enabled support bot that knows Portmaster well and can give you immediate help.
• 📖 The Wiki answers all common questions and has many important details. If you can't find an answer there, let us know, so we can add anything that's missing.