"
Hello everyone,
After upgrading from OPNSense v24 to v25, I've encountered an issue with ICMP handling that wasn't present in the previous version.
Observed Behavior in v24
When multiple internal hosts send ICMP echo requests (ping) to the same external destination (e.g., 1.1.1.1) using the same ICMP identifier, the state table shows separate entries for each host. For example:
In this scenario, all hosts get responses from 1.1.1.1 as expected.
Observed Behavior in v25
After upgrading to version 25, only one host at a time receives a response. Here's an example of the state table now:
The behavior is that the first ping to arrive gets an entry in the state table, and the others time out. Once I cancel the ping from the active host, a few seconds later one of the other hosts starts receiving responses.
Windows hosts usually send pings with ID 1 by default. You can force the same ID on all pings from Linux machines using
What I've Tried So Far
Flushing the State Table: Using pfctl -F state clears the state table, but the problem persists when new pings are initiated.
Comparing Outbound Behavior: I've noticed that in other networks behind the same OPNSense instance, even when pings use the same ICMP identifier, the firewall randomizes the ICMP ID on the outgoing packet—effectively avoiding collisions. However, on this particular network, the outgoing ICMP packet retains its original ID, leading to the state collision.
My Suspicions
It appears that something in the new version is affecting how PF (and by extension, NAT and scrub rules) handles ICMP sessions. In v25, it seems that PF is not randomizing the ICMP identifier for this network, or perhaps a rule is different from what we had in v24. With ICMP lacking a port number, PF relies solely on the identifier to track sessions. If two hosts use the same identifier, the first to establish a state "wins" and the others are merged into (or blocked by) that state, causing the observed behavior.
Questions / Request for Guidance
1. Intended Behavior Change?
Is this a known or intended change in how OPNSense (or PF on FreeBSD) handles ICMP state tracking and NAT between versions 24 and 25?
2. Configuration Adjustments:
• Are there new or modified scrub/NAT options in v25 that affect ICMP identifier randomization?
• Should I look for differences in the outbound NAT configuration (e.g., static-port settings) or in the scrub rules applied to this network compared to others that behave as expected?
3. Workaround Recommendations:
What configuration changes can be made in OPNSense (or directly on the FreeBSD shell) to restore behavior similar to v24, where multiple hosts with the same ICMP ID can receive responses?
I appreciate any insights or recommendations from the community or maintainers regarding this issue.
Thanks in advance for your help!
After upgrading from OPNSense v24 to v25, I've encountered an issue with ICMP handling that wasn't present in the previous version.
Observed Behavior in v24
When multiple internal hosts send ICMP echo requests (ping) to the same external destination (e.g., 1.1.1.1) using the same ICMP identifier, the state table shows separate entries for each host. For example:
Code Select
pfctl -ss
all icmp 1.1.1.1:1 <- 10.3.0.92:1 0:0
all icmp 1.1.1.1:1 <- 10.3.0.94:1 0:0
all icmp <wan-ip>:33788 -> 1.1.1.1:33788 0:0
all icmp <wan-ip>:30580 (10.3.0.92:1) -> 1.1.1.1:30580 0:0
all icmp <wan-ip>:18146 (10.3.0.94:1) -> 1.1.1.1:18146 0:0In this scenario, all hosts get responses from 1.1.1.1 as expected.
Observed Behavior in v25
After upgrading to version 25, only one host at a time receives a response. Here's an example of the state table now:
Code Select
pfctl -ss
all icmp 1.1.1.1:8 <- 10.255.255.23:1 0:0
all icmp 1.1.1.1:8 <- 10.255.255.10:1 0:0
all icmp <wan-ip>:1 (10.255.255.23:1) -> 1.1.1.1:8 0:0The behavior is that the first ping to arrive gets an entry in the state table, and the others time out. Once I cancel the ping from the active host, a few seconds later one of the other hosts starts receiving responses.
Windows hosts usually send pings with ID 1 by default. You can force the same ID on all pings from Linux machines using
Code Select
ping -e 1 1.1.1.1What I've Tried So Far
Flushing the State Table: Using pfctl -F state clears the state table, but the problem persists when new pings are initiated.
Comparing Outbound Behavior: I've noticed that in other networks behind the same OPNSense instance, even when pings use the same ICMP identifier, the firewall randomizes the ICMP ID on the outgoing packet—effectively avoiding collisions. However, on this particular network, the outgoing ICMP packet retains its original ID, leading to the state collision.
My Suspicions
It appears that something in the new version is affecting how PF (and by extension, NAT and scrub rules) handles ICMP sessions. In v25, it seems that PF is not randomizing the ICMP identifier for this network, or perhaps a rule is different from what we had in v24. With ICMP lacking a port number, PF relies solely on the identifier to track sessions. If two hosts use the same identifier, the first to establish a state "wins" and the others are merged into (or blocked by) that state, causing the observed behavior.
Questions / Request for Guidance
1. Intended Behavior Change?
Is this a known or intended change in how OPNSense (or PF on FreeBSD) handles ICMP state tracking and NAT between versions 24 and 25?
2. Configuration Adjustments:
• Are there new or modified scrub/NAT options in v25 that affect ICMP identifier randomization?
• Should I look for differences in the outbound NAT configuration (e.g., static-port settings) or in the scrub rules applied to this network compared to others that behave as expected?
3. Workaround Recommendations:
What configuration changes can be made in OPNSense (or directly on the FreeBSD shell) to restore behavior similar to v24, where multiple hosts with the same ICMP ID can receive responses?
I appreciate any insights or recommendations from the community or maintainers regarding this issue.
Thanks in advance for your help!
