OPNsense cannot block ICMP replies?

[Mindflayer]

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:

• Host A (192.168.10.2) - All traffic arrives at the LAN Interface in OPNsense with V_LAN tag 10
• Host B (192.168.20.2) - All traffic arrives at the LAN Interface in OPNsense with V_LAN tag 20
• Host C running OPNsense
• A managed switch, connecting all 3, taking care of the VLAN-tagging

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:

• Action: Pass
• Direction: IN
• TCP/IP Version: IPv4
• Protocol: any
• Source: I_20_Test net
• Destination: I_10_Test net

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:

• Action: Block
• Direction: IN
• TCP/IP Version: IPv4
• Protocol: any
• Source: I_10_Test net
• Destination: any

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.

[Patrick M. Hausen]

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

[Mindflayer]

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.