Hi,
i have enabled monitoring on red, green and orange.
Before this update, I could only disable IPS on the orange interface and the connections in the DMZ worked again. Since this update, I also have to disable monitoring on the red interface.
Is this necessary as a result of the new implementation or is this a bug?
It seems like something have changed indeed.
I have a couple of websites running in a DMZ on ORANGE, with DMZ pinholes to GREEN hosts. Since CU189, the IPS stops this traffic if activated on GREEN (it has never been active on ORANGE). DMZ pinholes are ignored for IPS and it’s unclear if this is a bug or a change in operation. The solution for me as of now was to whitelist my DMZ subnet in the IPS screen.
This new behavior was very unexpected and led to hours of downtime, first until I had the time to fix it and then finding the actual error (as I’m also running a reverse proxy, which also got updated with disastrous results, so the IPS being the culprit was not really my first guess – I was blaming nginx).
Sounds like a similar problem to me, as the assignment of the interfaces is no longer respected.
This actually looks to me as if a logic error has occurred in the new implementation.
I also experienced trouble with IPS on CU189.
I have a webserver running in DMZ with a pinhole to MySQL in Green.
IPS is enabled on red, orange and blue.
After upgrading to CU189 the webserver in DMZ was no longer able to contact the MySQL DB in Green.
After a few hours of checking firewall rules, logs, tcpdump etc… I somehow accidentally bumped in the Intrusion Detection webUI page, and tried unchecking monitoring orange…
And suddenly the webserver could again contact MySQL.
So now I had to disable IPS on orange
There where changes made per the blog.
https://www.ipfire.org/blog/ipfire-2-29-core-update-189-released
We know that. That is the reason why I spoke of “new implementation”. But as you can see, the changes result in considerable problems that are probably not intended and do not make sense.
BTW, this also applies to OpenVPN connections, and (I’m guessing) IPSec: incoming connections for (e.g.) MySQL are now dropped by the IPS. This is a pretty major change in operation. Was it intentional?
No change in operation of the interfaces with regard to IPS was intended with the change other than not leaving ports open if suricata was crashed and allowing IPS scanning of IPSec interfaces which was not available before.
so far so good 
luckily we get the additional info:
confirms that the changeblog annotation
is not related to the new-behaviour
reported by sx and mg 
i also have the same issue but if i disable SYN Flood Protection on all rules IPS work as expected is there relation ?
after disabling SYN Flood Protection sometime it need to restart firewall (/etc/rc.d/init.d/firewall restart) and ips (/etc/init.d/suricata restart) to work as expected again
I’m sure that wasn’t the intention, but the fact is that something has been changed that completely overrides the previous logic of interface assignment.
Unfortunately, I have no understanding of how the whole thing works and is implemented. I can only report that it no longer works correctly.
I may not have explained it in enough detail. Do you need more information to understand the problem in order to address the issue?
The question was asked if something had been deliberately changed to make that difference.
That was not done but of course a bug could have been created.
Please follow this link
https://www.ipfire.org/docs/devel/bugzilla
please take not of the section titled
“Where not to report bugs”
I’m not sure this is “fixable” or even a bug – indeed, one could certainly argue that this new way of treating IPSec and OpenVPN and Orange as “outside green”, from the IPS viewpoint, is more philosophically correct.