Hi,
since Core Update 187 i get no local access to our webserver in dmz. I figured out, when i exclude our local network in IPS, everything is fine again. Access from the internet/wan-side to the webserver works perfectly. I got Surricata on Green, Red and Orange working. We are using Split-DNS for local Acess…
thx for response.
Edit: Worth mentioning, SSH-access is not blocked by IPS, though there are no FW-rules for ssh. For webserver there are portforwarding rules tcp 80/443 of course.
Hi Kuni,
is your webserver at 192.168.10.120 and is the DMZ orange network?
I am not familiar with the newest release 187 with Suricata 7 but think in the recent past the same Suricata 6 rules that you listed “Suricata Stream” were considered a “nuisance” and I think there were some users that just disabled them in one of the yaml files.
I have this same Fault
Found it was blocking my Jellyfin server.
White listed Jellyfin client for now.
Yes.
Problem exists since Core Update 187, with Core Update 186 everyhting was fine with the same rules (without the need of putting the whole local network in the exception list).
I read about editing the yaml files, but if i read correctly, these files will be overwritten on suricata udpates, right?
Ok, so I’m not alone with this problem.
Hoping of possibility to exclude those builtin-default rules of suricata.
Suricata 7 was released in Core Update 185
Posted a link to this post over here.
Don’t know if it’s related?
In the past my Jellyfin clients have had the same Suricate fault but did not block my server.
Yeah strange, I always thought that priority 3 entries in IPS logs means informative and that doesn’t leads to blocking. But as seen in firewall-log I got these drop_ctinvalid entries and I’m not sure, what that means exacly.
Ty.
has flagged packets up as not belonging to any established connection and has therefore marked the packets as invalid.
Hm, the problem is, is this a following symptom or the root cause for dropping the packets.
I had to say, that when I tried to reach the webserver, my browser got no answer and keeps trying to reach the server. This looks like packets are droped and not blocked (rejected), right?
Yes, that would be my interpretation.
I checked the problem again with CU188, but i still need to exclude the client-network in ids-page. Still the same entries in ids- and firewall-log.
I think i found the problem:
When i enable the SYN Flood protection on the corrospending port-forwarding rule for my webserver together with suricata enabled on green network, then i couldn’t reach the webserver.
I had to do one of the 3 things to get access again:
Again, this only occurs on access from green to webserver in dmz (orange). And i have no clue, why this only is a problem in this combination.
Then again i looked at my port forwarding rule and thought, if there is something wrong?
Edit: I want to add, that I got no entries in suricata-log since last core update. I think that has to do with disabling the “noisy” rules?
