Automatically generated rules - is the reason I stopped migrating to OPNSense

[newjohn]

Thank you everyone for your input and support.

I tested this scenario with Pfsense as well and got the same results. I have not tested other firewalls. But two firewalls behaving in the same way kind of support the idea that this is normal.

In the end i like what I am seeing on Opnsense, so I am sticking with it even through the title says othwerwise

[netnut]

I tested this scenario with Pfsense as well and got the same results. I have not tested other firewalls.

Well, that's rather funny don't you think, looking at your initial statement   

But two firewalls behaving in the same way kind of support the idea that this is normal.

That's because the underlaying issue is still there (it's _not_ normal), did you test with hardware offloading disabled as mentioned in my last post ?

[newjohn]

I tested this scenario with Pfsense as well and got the same results. I have not tested other firewalls.

Well, that's rather funny don't you think, looking at your initial statement   

But two firewalls behaving in the same way kind of support the idea that this is normal.

That's because the underlaying issue is still there (it's _not_ normal), did you test with hardware offloading disabled as mentioned in my last post ?

===============
Yeap, it is funny . I originally thought the auto generated rules were the cause, but since they are not, its not relevant anymore.

As for testing with the hardware offloading disabled, I think this is disabled by default, so any tests carried out had this disabled by default.

Also, if this is not normal and confirmed by more than one user, isnt this a priority issue?

I am now back again sitting on the fence on whether we should be concerned about this or not?

[netnut]

Also, if this is not normal and confirmed by more than one user, isnt this a priority issue?

Because it isn't an OPNSense issue, which you already discovered after installing an alternative fw.

Your problem is visible in the Wireshark capture screenshot where you can see _all_ your ICMP echo/reply's with "id=0x0001". There are no states in ICMP, but to decide/relate which reply matches which echo is normally based on this unique id. So your pings from the OPT network should have an other id than the initial ping from LAN.

For some reason there isn't much creativity in the uniqueness of this id, so all ICMP echo/reply will match. Could be a client NIC, driver, bad or inferior hardware  (Realtek?), funky IP stack, etc

[CrazyMac]

As a new OPNsense user, and recently retired developer/system architect, I fully thank the OPNsense crew for putting the bare minimum of protection in place so we can then move on to adjust/create/demolish what we want from that point. Random new users have no idea what to do first and the generated rules gets us setup and then we can screw ourselves up all we want, but that is not your fault.

Again, thank you!

[athisesanr]

Hi Team,

Adding my problems to here, that every opnsense action such as route , interface or rules edits gives gui/ping loss and suspecting that automatically rules are plays to deny the traffic. Therefore post pfctl -d cmd execute that allow to another changes.

Is any one help here that why every action on opnsense trigger pf enables and loss the gui/pings drops. Is there way to delete the automatically rules from opnsense.

I'm using opnsense as vm on kvm.

Thanks,
Athisesan

[netnut]

Adding my problems to here...

Don't do that, if you have an question or issue open a topic in a relevant sub forum

...and suspecting that automatically rules are plays to deny the traffic...

Suspecting ? This is a five page topic explaining that whichever "problem" you (can) have with OPNsense it's NOT RELATED to "Automatically Generated Rules". So what makes you think or suspect these rules do ?

Besides an (industry standard) _last_ match deny any/any rule _nothing_ is blocked in this ruleset. These rules are there to help you to give you at least an initial reasonable firewall default. Ok, it's also blocking all traffic on port 0, which shouldn't happen anyway (again to help you). They're even nicely commented.

Make it your mantra: Automatically generated rules aren't my problem! You could even hum in "Wolf of Wallstreet" style while repeating this!

I'm using opnsense as vm on kvm.

Wild guess (99,9% sure), check your (virtual) topology & configuration.

[mimugmail]

Hi Team,

Adding my problems to here, that every opnsense action such as route , interface or rules edits gives gui/ping loss and suspecting that automatically rules are plays to deny the traffic. Therefore post pfctl -d cmd execute that allow to another changes.

Is any one help here that why every action on opnsense trigger pf enables and loss the gui/pings drops. Is there way to delete the automatically rules from opnsense.

I'm using opnsense as vm on kvm.

Thanks,
Athisesan

Sounds you are connected via WAN and everytime you change rules you get kicked out cause of missing accept rule and need to pfctl again.

100% your setup, not a general issue

[GrilliIAL]

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

[netnut]

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...

[GrilliIAL]

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

[netnut]

I do not agree.

You are free to have your own opinion...

You got redirected multiple times to a thread (this particular one) that explains what's happening which has nothing to do with a "security" issue, confusion or what so ever. If you refuse to read that thread (or trying to understand the underlying cause), it's not about freedom anymore but just ignorance.