Messages

I wonder if it is possible to get this information to the developers as it seems like a bug or security hole

No it isn't, as already explained in this thread. No need to cross post this...

I do not agree. There is a case where the firewall confuses ICMP traffic generated by network B to A as response traffic from A to B making any blocking rules useless. This behavior is easily reproducible and independent of particular implementations of the OPNSense machine. It probably has deeper origins in how FreeBSD's PF (Packed Filter) works, but it still represents a problem, if only because it makes PING unreliable in testing the rules, unless you know exactly what to expect.

I would add that I have worked with other firewalls including the glorious Microsoft TMG which in a similar scenario were able to manage ICMP traffic without any confusion

Hello all,

Just getting started with OPNsense and trying to make sense of something I am seeing. I am sure this is just a misunderstanding on my part, but I would like to make sure I do not have something set up wrong.

My setup has LAN (192.168.10.*), GUEST (192.168.20.*), IoT (192.168.30.*), and NoT_CAM (192.168.40.*) networks set up with nothing other than the automatically generated rules and the allow LAN to any rules on the LAN network.

Using IoT as an example (all non-LAN networks have this behavior, though), If I first ping from IoT to LAN, I get no return, as would be expected. If I then ping from LAN to IoT I get responses, also as expected. Now, if I immediately go back to IoT and ping LAN I get responses. This is what I was not expecting to happen. If I let the connection sit idle for about 30 seconds, and try the ping from IoT to LAN again, I get no responses.

So, I think this has to do with the stateful nature of the firewall, but I am not sure. Could someone please clarify what is going on here? Also, is there any way to keep this from happening?

Thanks in advance for helping out a newbie.

This is exactly what happens to me in a similar scenario.
Open a console Ping -t from IoT to LAN all fail as expected, but if I ping even once from LAN to IoT then the ping-t flow from IoT to LAN activates and remains active until I close the state.
An additional traffic blocking rule from IoT to LAN is also ignored.
Analyzing the logs shows that OPNSense sees this as ping return traffic from LAN to IoT even though it originated from IoT. So you can't block it with any rule that references IoT as the source.

I wonder if it is possible to get this information to the developers as it seems like a bug or security hole

Therefore althought its always a possiility due to misconfiguration i think its unlikely?

Only one statement CAN be true: You discovered a major security bug/flaw in PF and/or OPNSense OR you have issues in your virtual environment, network topology, firewall config etc.

Because your issue is quite simple, allowing ICMP echo request / reply between two interfaces, I suggest you create a more simple setup to debug and report on with a basic and easy to understand topology and ruleset. Your virtual so deploying an extra VM should be an easy task for such a potential high impact security bug/flaw (not only impacting OPNSense).

So a default setup with LAN + WAN and after that creating an extra OPT interface to introduce a second LAN segment. Keep EVERYTHING default just configure the interface IP's and DO NOTHING else. To make it super transparent, don't mess with VLAN interfaces YET. If you need just create static mappings between your OPNSense interfaces and your existing VLANs by creating VLAN port groups in vSphere VDS or Open vSwitch on KVM or whatever you are using.

Now if you can confirm that in this DEFAULT setup you can ping from a host in the OPT network to a host in the LAN network it's time to get scared. The other way around, ping from _DEFAULT_ LAN network to OPT network, will work as explained in previous posts.

I couldn't bother to plow through your ruleset (too much noise), but I did check your statement at a system here with ten's of raw interfaces, bridges and VLANs (both LAGG and non-LAGG) and couldn't reproduce it on any.

From my perspective a misconfiguration is VERY likely, but I'm eager to hear about the issues you find in the above "test" setup.

I agree it would be good to get to the bottom of this.

Really busy day at work so have not had the chance to do the test you asked yet. But I did some thinkering and think I figured it out. I need another pair of eyes to confirm if this is the case.

VLAN190 has permit all rule
VLAN160 has NO rule

If i start the ping from vlan190 to vlan160 (vlan190 has permit all statement) it works ok (as expected).

If i reboot both PCs and the firewall so there is no established connection as far as the firewall is concerned and try to ping from vlan160 (which does not have any firewall statements), it fails (as expected).

So far the firewall does what its expected.

However, the point it gets unexpected is as follows:

After the reboot all connections states is cleared. so if i start the ping from vlan160 to vlan190, it fails as expected.
However, I noticed the second i start pinging from vlan190 back to vlan160 naturally vlan190 works ok, but because the firewall now has established an open state between this two IP Addresses it allows vlan160 to ping back vlan190.

if i stop the ping from vlan190 and reset the state table the ping stops which supports my findings?

Whats is your take on this please?
Please see the attached screenshot.

This is exactly what happens to me in a similar scenario.
Open a console Ping -t from vlan160 to vlan 190 all fail as expected, but if I ping even once from vlan 190 to vlan160 then the ping-t flow from vlan160 to vlan 190 activates and remains active until I close the state.
An additional traffic blocking rule from vlan160 to vlan 190 is also ignored.
Analyzing the logs shows that OPNSense sees this as ping return traffic from vlan 190 to vlan160 even though it originated from vlan160. So you can't block it with any rule that references vlan160 as the source.

I wonder if it is possible to get this information to the developers as it seems like a bug or security hole