OPNsense Forum

English Forums => 24.7, 24.10 Legacy Series => Topic started by: Mindflayer on November 26, 2024, 10:35:18 AM

Title: OPNsense cannot block ICMP replies?
Post by: Mindflayer on November 26, 2024, 10:35:18 AM
Hello everyone,

i would kindly ask for help to understand some behavior of OPNsense here. (This is all for learning purposes)

I created a small network:


In OPNsense I created two V-LANs "vlan0.10" and "vlan0.20", both having the LAN Interface as parent.
I assigned vlan0.10 as Interface I_10_Test and gave the Interface the static IP 192.168.10.1/24.
I assigned vlan0.20 as Interface I_20_Test and gave the Interface the static IP 192.168.20.1/24.

On Host B I tried to ping 192.168.10.2. Does not work, as expected.

Now I created a First Match Firewall rule in Interface I_20_Test:


Now Host B can ping Host A. But to my understanding, the ICMP reply of Host A should not reach back to Host B.

My first thought was that there is an automatic NAT rule, allowing the ICMP reply to reach back to Host B. So I set Firewall > NAT > Outbound > Disable outbound NAT rule generation (outbound NAT is disabled). But the ICMP replies could still reach back to Host B.

Next I tried to create a First Match rule on I_10_Test:


But even with that, Host B can still receive the ICMP replies of Host A.

As a last try, I disabled the automatically created rule "Default allow LAN to any rule" on the LAN Interface, but still no success in blocking the ICMP replies.

Could you please help me to understand what I am doing wrong or whats my misconception here?

Thank you.
Title: Re: OPNsense cannot block ICMP replies?
Post by: Patrick M. Hausen on November 26, 2024, 11:03:16 AM
Quote from: Mindflayer on November 26, 2024, 10:35:18 AM
Now Host B can ping Host A. But to my understanding, the ICMP reply of Host A should not reach back to Host B.

pf and consequently OPNsense is a stateful firewall. It operates on "connections" or "flows", not individual packets.

So if an ICMP echo request in one direction is allowed, then automatically the matching reply is allowed, too, because anything else would not make much sense.

The very first generation of packet filters in the nineties did not track connections. So for e.g. TCP you had to unconditionally permit every packet in with the ACK flags set. In Cisco IOS that was done by the "established" keyword in access-list statements. For UDP the gaps you had to open were even wider.

Today once a client "iniside" your firewall sends a TCP SYN packet to e.g. a web server on the Internet, and that is permitted by the rules, OPNsense sets up a state for the complete TCP connection in both directions. Once the final FIN packet passes the firewall the state is deleted again. In case the connection is never correctly torn down, a timeout is applied.

Hope that clears it up a bit,
Patrick
Title: Re: OPNsense cannot block ICMP replies?
Post by: Mindflayer on November 26, 2024, 01:14:37 PM
Quote from: Patrick M. Hausen on November 26, 2024, 11:03:16 AM
Quote from: Mindflayer on November 26, 2024, 10:35:18 AM
Now Host B can ping Host A. But to my understanding, the ICMP reply of Host A should not reach back to Host B.

pf and consequently OPNsense is a stateful firewall. It operates on "connections" or "flows", not individual packets.

So if an ICMP echo request in one direction is allowed, then automatically the matching reply is allowed, too, because anything else would not make much sense.

The very first generation of packet filters in the nineties did not track connections. So for e.g. TCP you had to unconditionally permit every packet in with the ACK flags set. In Cisco IOS that was done by the "established" keyword in access-list statements. For UDP the gaps you had to open were even wider.

Today once a client "iniside" your firewall sends a TCP SYN packet to e.g. a web server on the Internet, and that is permitted by the rules, OPNsense sets up a state for the complete TCP connection in both directions. Once the final FIN packet passes the firewall the state is deleted again. In case the connection is never correctly torn down, a timeout is applied.

Hope that clears it up a bit,
Patrick

Yes! I have read into the Firewall States and played around with them. Now it makes sense. Thank you.