Suricata is blocking LAN and WAN IPs
-
Starting on Feb 5th Suricata started blocking internal LAN IPs as well as the external WAN IP. I have gone into the interface settings for each interface and verified both networks are in the pass list. I have also looked in the Suricata logs and can see where it loaded the pass list. I have rebooted pfSense several times and even reinstalled the Suricata package, but it still seems to keep blocking these IPs. At this point I've had to completely disable Suricata to keep my network alive. Any ideas what could be going on?
I did update from 4.1.6_1 to 4.1.6_3 on Feb 3. I didn't notice this issue until yesterday the 5th, but I for sure was not having the issue prior to the update.
-
@zachtywebb Wouldn't be those IPs normally in the Home Net ( Services>Suricata>Edit Interface Settings ), why a pass list?
-
@Bob-Dig Yes, this is true but they are also listed in the pass list by default as well. So, in reality they are listed in both places but are somehow getting blocked. Obviously I'd want the external IPs blocked when a rule triggers, but for obvious reasons blocking my internal IPs and WAN IP causes some over blockage.
-
@zachtywebb said in Suricata is blocking LAN and WAN IPs:
@Bob-Dig Yes, this is true but they are also listed in the pass list by default as well. So, in reality they are listed in both places but are somehow getting blocked. Obviously I'd want the external IPs blocked when a rule triggers, but for obvious reasons blocking my internal IPs and WAN IP causes some over blockage.
Most likely you have a zombie Suricata process still running and not honoring the Pass List. If possible without too much interruption, just reboot your firewall.
If you don't want to do that, try these steps.
-
Stop Suricata on all interfaces using the icon on the INTERFACES tab.
-
Open a CLI session on the firewall and issue this command
ps -ax | grep suricata
-
Look for any active Suricata processes. You see should none.
-
If you see any Suricata process, note the PID and then run the following command to kill it. Do this for all Suricata instances that may be showing.
kill -9 <pid>
- Return to the GUI and start Suricata on all configured interfaces again.
-
-
@bmeeks I have seen posts with people having this zombie process issue and have rebooted several times. This doesn't seem to resolve my issue. Right now I am trying a hard remove of the Suricata package with it removing all settings and doing a completely fresh install and setup.
-
You should also check in the
suricata.log
file to see if any kinds of errors are being posted. Might be that something is corrupt in your default pass list. You can view the log files for an interface by going to the LOGS VIEW tab.Note that the
suricata.log
file is overwritten each time Suricata starts, so to catch an error you will need to look at the file before restarting Suricata. -
@bmeeks After a fresh install and completely setting everything back up, I am still seeing pass list and home net IPs getting blocked. Here is my suricata.log file if it helps, but I'm not seeing anything concerning. suricata.log.txt
-
@bmeeks Here is a line item from the block log from one of these instances:
02/07/2020-14:17:02.668595 [Block Src] [] [1:2007994:21] ET INFO Suspicious User-Agent (1 space) [] [Classification: Unknown Traffic] [Priority: 3] {TCP} 192.168.1.139:55537
02/07/2020-14:17:02.668595 [Block Dst] [] [1:2007994:21] ET INFO Suspicious User-Agent (1 space) [] [Classification: Unknown Traffic] [Priority: 3] {TCP} 172.217.3.195:80And here is the corresponding line item from the http log:
02/07/2020-14:17:02.668595 connectivitycheck.gstatic.com[]/generate_204[][]<no referer>[]HEAD[]HTTP/1.1[]204[]0 bytes[]192.168.1.139:55537 -> 172.217.3.195:80
-
Post up what your default pass list contains. You can view and copy/paste its contents by going to the INTERFACE SETTINGS tab for an interface and clicking the View button beside the Pass List drop-down selector towards the bottom of the page.
Suricata's internal pass list engine for the firewall interfaces appears to be working properly as evidenced by these lines from
suricata.log
showing the firewall's interface IP addresses being added to the internal automatic pass list.7/2/2020 -- 13:52:30 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:30 - <Info> -- alert-pf -> deleted address 192.168.1.1 from automatic firewall interface IP Pass List. 7/2/2020 -- 13:52:30 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:30 - <Info> -- alert-pf -> deleted address 10.10.10.1 from automatic firewall interface IP Pass List. 7/2/2020 -- 13:52:34 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:34 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List. 7/2/2020 -- 13:52:34 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:34 - <Info> -- alert-pf -> added address 10.10.10.1 to automatic firewall interface IP Pass List. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> deleted address 192.168.1.1 from automatic firewall interface IP Pass List. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> deleted address 10.10.10.1 from automatic firewall interface IP Pass List. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> added address 192.168.1.1 to automatic firewall interface IP Pass List. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> Received notification of IP address change on interface em0. 7/2/2020 -- 13:52:39 - <Info> -- alert-pf -> added address 10.10.10.1 to automatic firewall interface IP Pass List.
You should see the network for your LAN listed in the default pass list (for example, 192.168.1.0/24 or something similar). Do you see that?
BTW, it is curious that in the
suricata.log
you can see this parsing of firewall interfaces happening twice. It's like your interfaces bounced again as Suricata was starting. What's up with that? The engine monitors the firewall interface IPs using a subscription to pfSense (FreeBSD) routing messages. -
@bmeeks I do see that listed. Below is what is in my default pass list:
10.10.10.1/32
192.168.0.0/24
192.168.1.0/24
xxx.xxx.240.1/32
xxx.xxx.243.208/32
127.0.0.1/32
2001:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:e430/128
2601:xxxx:xxxx:xxxx::/64
::1/128
fe80::1/128
fe80::1:1/128
fe80::xxxx:xxxx:xxxx:a244/128I saw the interface parsing twice as well and thought that was weird, but wasn't really sure if that was an issue or not. As far as I'm aware my interfaces didn't bounce.
-
The logs you posted are all for physical interface em0. Are there any VLANs defined on that interface or just a single LAN?
Also, have you verified that the IP address 192.168.1.139 is showing on the BLOCKS tab?
I'm thinking it must be something within your configuration because if this were a widespread problem I would expect to see a lot of posts recently about this.
-
@bmeeks There are no defined VLANs; just a single LAN. And yes, I see the 192.168.1.139 IP listed on the block tab and can confirm it does in fact stop working once placed on the block tab.
I am not willing to retest at the moment, but the configuration on my WAN interface was blocking my external WAN IPv4 address causing my entire internet to get blocked, which is how I stumbled into this gem of an issue. Took me a while to track down what was causing my internet to not work. The only thing that has changed recently is that I updated the Suricata package 2 days before I stumbled into the WAN IP being blocked.
-
I am unable to reproduce your problem. Here is a test I did using a pfSense virtual machine running the current Suricata-4.1.6_3 package.
I have a Kali Linux virtual machine on the same network as the pfSense VM. I used
nmap
on the Kali Linux machine to scan the WAN IP address of the pfSense virtual machine. That WAN IP is 192.168.10.21 in the images that follow. 192.168.10.23 is the Kali Linux virtual machine.Here are the alerts on the WAN interface from pfSense that resulted from the Kali Linux scan:
And here are the results from the BLOCKS tab showing the Kali Linux host being blocked but not the pfSense firewall's WAN IP.
And finally, here is the Default Pass List existing on the pfSense virtual machine. Notice the WAN IP is listed and that IP is not blocked in the scan alerts while the IP of the Kali Linux malicious host is blocked. Everything is working as designed on my end.
-
@bmeeks Alright, well I guess at least it's for sure not an issue with the update. I am out of ideas at the moment, but will keep poking at it. Thanks for all your help.
-
@zachtywebb said in Suricata is blocking LAN and WAN IPs:
@bmeeks Alright, well I guess at least it's for sure not an issue with the update. I am out of ideas at the moment, but will keep poking at it. Thanks for all your help.
Those extra lines in your
suricata.log
file about adding the firewall interface IPs to the automatic internal pass list are strange. Normally those lines should appear just once in the log unless an interface IP changes sometime later after startup has completed. Usually that only happens due to a DHCP release/renew cycle or a PPPoE connection dropping and then being re-established.When Suricata starts, the custom blocking plugin on pfSense grabs all the existing firewall interface IP addresses and puts them in the internal automatic pass list. It also subscribes to kernel routing messages so that it can see any future interface IP changes. So that first set of log messages about adding IP addresses to the automatic internal pass list are expected and normal.
In your log, however, there is another cycle interface IPs being removed and then added back just a second or two after the initial startup scan was completed. That is unusual. I would focus my investigations there to determine why that is happening. What is making your interfaces essentially come up and then go down and then come up again with a few seconds?
-
@bmeeks So, I did find this line in my pfBlockerNG IP block log and I do have kill states enabled on there. Not sure if this is related but the timestamp on this is directly between the initial start of Suricata in the previous log and the interface reset. This is on the WAN so it would be weird for it to be the cause of the LAN (em0) to bounce.
Feb 7 13:52:17,1770007928,igb0,WAN,block,4,6,TCP-S,194.26.69.105,xxx.xxx.243.208,58964,2431,in,RU,pfB_Top_v4,194.26.69.0/24,pfB_Top_v4,Unknown,wan,null,+
-
@bmeeks I may have figured this one out. Not sure how this issue just popped up but I saw another of your posts where something similar was happening to someone else and I checked some settings that you had suggested and I had not disabled hardware checksum offloading. After doing this and rebooting I am not seeing home net or pass list IPs being blocked. I will keep an eye on it but so far this seems to have done the trick.
-
@zachtywebb said in Suricata is blocking LAN and WAN IPs:
@bmeeks I may have figured this one out. Not sure how this issue just popped up but I saw another of your posts where something similar was happening to someone else and I checked some settings that you had suggested and I had not disabled hardware checksum offloading. After doing this and rebooting I am not seeing home net or pass list IPs being blocked. I will keep an eye on it but so far this seems to have done the trick.
That's strange. Glad it's working for you now, but I would not have expected that to make a difference in blocking HOME_NET or not blocking it.
-
@bmeeks Yeah, I was thinking the same thing and was expecting it to not work, but at that point I was grasping at straws. I am still not convinced that was the root cause, but I am no longer showing the duplicate weirdness in the Suricata logs and none of the pass list IPs are being blocked. What I am thinking actually happened is whatever was making Suricata upset finally cleared on this most recent reboot.
-
I have the exact same problem. Suricata blocks my LAN IPs.
With SNORT i don't have this strange problem and i don't know why.
Already tried to reboot, to stop suricata on each interface and check for zombies processes but nothing.
I have a setup with legacy blocking and Block on Drop only (even without block on drop only i have this problem) and i have VLAN on ix0 interface (but i only have the lan in suricata) . I really don't know what to do .Here my default passlist and the suricata.log and block.log
10.10.10.1/32 10.10.20.0/24 10.10.20.254/32 10.39.156.0/25 WANIP/32 127.0.0.1/32 172.168.69.0/24 192.168.1.0/24 192.168.57.0/24 192.168.70.0/24 192.168.100.0/24 195.43.166.12/32 ::1/128 fe80::92e2:baff:fe4c:c1b4/128 fe80::e9d:92ff:fe5b:cab5/128 fe80::e9d:92ff:fe5b:cab6/128
suricata.log alerts.log blocks.log
P.s. i don't find any similar type of logs in snort, maybe it could
-
That's a newer suricata.log.lan made after a fresh install of suricata.
Update: just set up the wan on suricata with legacy block-block on drop only-block both SRC&DST and with this interface i don't have problems with passlist! It blocks only the external IPs!
suricata.log.wan -
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
I have the exact same problem. Suricata blocks my LAN IPs.
With SNORT i don't have this strange problem and i don't know why.
Already tried to reboot, to stop suricata on each interface and check for zombies processes but nothing.
I have a setup with legacy blocking and Block on Drop only (even without block on drop only i have this problem) and i have VLAN on ix0 interface (but i only have the lan in suricata) . I really don't know what to do .Here my default passlist and the suricata.log and block.log
10.10.10.1/32 10.10.20.0/24 10.10.20.254/32 10.39.156.0/25 WANIP/32 127.0.0.1/32 172.168.69.0/24 192.168.1.0/24 192.168.57.0/24 192.168.70.0/24 192.168.100.0/24 195.43.166.12/32 ::1/128 fe80::92e2:baff:fe4c:c1b4/128 fe80::e9d:92ff:fe5b:cab5/128 fe80::e9d:92ff:fe5b:cab6/128
suricata.log alerts.log blocks.log
P.s. i don't find any similar type of logs in snort, maybe it could
From the
suricata.log
file accompanying your post --30/9/2021 -- 10:36:16 - <Info> -- alert-pf -> Pass List /usr/local/etc/suricata/suricata_13894_ix0/passlist parsed: 0 IP addresses loaded.
So Suricata did not load any local IP addresses into the passlist. Notice the "0 IP addresses loaded" part. The other entries in the log where it mentions "automatic IP interface Pass List" are not the same thing. Those are actual firewall interface IPs. The regular Pass List is where LAN hosts would reside.
So in this instance, blocking of local LAN hosts would certainly occur.
-
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
That's a newer suricata.log.lan made after a fresh install of suricata.
Update: just set up the wan on suricata with legacy block-block on drop only-block both SRC&DST and with this interface i don't have problems with passlist! It blocks only the external IPs!
suricata.log.wanNow look at the
suricata.log
file where it tells you how many IP addresses it loaded from the passed Pass List file:30/9/2021 -- 14:45:47 - <Info> -- alert-pf -> Pass List /usr/local/etc/suricata/suricata_57062_ix0/passlist parsed: 16 IP addresses loaded.
There it found and loaded 16 IP addresses and/or subnets.
-
@bmeeks yes :)
But Suricata still blocks internal IPs on this interface and i really don't know why
On WAN no problems. -
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks yes :)
But Suricata still blocks internal IPs on this interface and i really don't know why
On WAN no problems.Are you running VLANs on that interface? If so, what are all of the VLAN subnets defined on that interface?
Also post the content of this file:
/usr/local/etc/suricata/suricata_57062_ix0/passlist
back here. -
-
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks passlist
Yes i have VLANs on this interface:
192.168.100.0/24 = ix0.100
172.168.69.0/24 = ix0.69
192.168.57.0/24 = ix0.57
LAN = 10.10.20.0/24One other request I should have included previously, but forgot --
Go to the BLOCKS tab and clear all blocks. Remove them all. Then when you experience a new LAN host getting blocked, do this:
Go to DIAGNOSTICS > TABLES and choose the snort2c table from the drop-down list. Screen capture the content of that display of IP addresses in that table and post back here.
Because you have posted just the logs, and the logs don't appear to be time correlated, it's difficult to make heads or tails of what's happening. The content of the snort2c table will always be the current list of what Suricata is blocking. The blocks log will have historical data, and because of the timestamp issues I don't know which blocks were from the run where Suricata loaded zero IP addresses from the Pass List, and which blocks are from the run where it loaded 16 IP addresses from the list.
I would dearly love to find out what is going on as I've had a few users report this behavior over the years. Not a lot, but certainly some. However, I have never in all my testing since I created the Suricata package, been able to duplicate this problem in my test systems. Not once. So if I can't duplicate it, that makes it very hard to troubleshoot, and even harder to actually fix.
-
@bmeeks
i will do all you want! i really want to help you to fix this :) so no problem at all!
suricata alerts
snort2cp.s. i have all the networking offloads disabled but checksum and hardware vlan tagging on this ix0 interface.
-
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks
i will do all you want! i really want to help you to fix this :) so no problem at all!
suricata alerts
snort2cAnd just to be clear, is this the same running instance where the
suricata.log
said it had loaded 16 IP addresses from the passlist file?It's important that Suricata logs that it actually read IP addresses from the passlist file when starting up. You had two posted
suricata.log
files where one showed zero IP addresses loaded, and the other showed 16 IP addresses loaded. Does thesuricata.log
file for this interface currently contain a line saying IP addresses were loaded from the file/usr/local/etc/suricata/suricata_57062_ix0/passlist
? -
@bmeeks
yes i can confirm! the old istance is gone
suricata.log -
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks
yes i can confirm! the old istance is gone
suricata.logThanks for the confirmation. I've got an idea, but it will take me a day or so to test it. Still not sure I can reliably reproduce the problem, but I think I see a place in the custom blocking plugin binary code where a section of structure union data could get misinterpreted. I need to figure out a sequence of events and data that reliably trigger the problem to be sure that's really the problem.
-
@bmeeks i'll try to reproduce also on my friend's network in 1 or 2 hours .
I'll put here the results.
Thank you so much :) -
done! also on my friend's network suricata blocks the internal IPs on the LAN interface!
His network topology
LAN = 10.10.30.0/24 = em0 interface (WAN on igb0)
VLANs are:
192.168.69.0/24 = em0.69
10.10.100.0/24 = em0.100[In reply to Sam Sepiol]
/usr/local/etc/suricata/suricata_37556_em0/passlist10.10.10.1/32
10.10.30.0/24
10.10.30.254/32
10.10.100.0/24
WANIP
127.0.0.1/32
192.168.1.0/24
192.168.69.0/24
195.43.166.12/32
::1/128
fe80::b62e:99ff:fe62:28ea/128
fe80::b62e:99ff:fe62:28eb/128
suricata.log.lan
suricata.log.wanTomorrow i'll also share the snort2c log when suricata will be triggered and i'll also post a screenshot from the Alerts page with the exact time.
-
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
done! also on my friend's network suricata blocks the internal IPs on the LAN interface!
His network topology
LAN = 10.10.30.0/24 = em0 interface (WAN on igb0)
VLANs are:
192.168.69.0/24 = em0.69
10.10.100.0/24 = em0.100[In reply to Sam Sepiol]
/usr/local/etc/suricata/suricata_37556_em0/passlist10.10.10.1/32
10.10.30.0/24
10.10.30.254/32
10.10.100.0/24
WANIP
127.0.0.1/32
192.168.1.0/24
192.168.69.0/24
195.43.166.12/32
::1/128
fe80::b62e:99ff:fe62:28ea/128
fe80::b62e:99ff:fe62:28eb/128
suricata.log.lan
suricata.log.wanTomorrow i'll also share the snort2c log when suricata will be triggered and i'll also post a screenshot from the Alerts page with the exact time.
Thank you for the additional info. I will duplicate this IP setup in my VMware virtual machine and see if I can replicate the problem. I've made a change in my test system that "might" have an impact, but it would be much more reassuring to have a test case that reliably fails, and then works after my patch is applied.
There was a new Suricata package update posted this afternoon. It addresses another issue with VLANs and I don't expect it to fix your problem, but it would not hurt to test it out just to verify.
-
Sadly I have thus far been unable to replicate this problem yet again. So it must be something in my test environment that is preventing the problem from happening (blocking a Pass List IP address).
One problem I have in my current test setup is that I don't have enough, nor the right types, of hardware to configure real VLANs. I don't have a managed switch. Just have never needed one here at home. Probably need to get one eventually. I also don't have a bunch of extra base metal hardware either. I usually test with VMware Workstation and multiple VMs configured in there. But I can't get VLANs working in VMware Workstation. The instant I put a VLAN on one of the virtual interfaces of a VM, it stops passing traffic to any other VM.
I did configure an interface to use all of your IP address subnets, though, and still don't get blocks of addresses on the Pass List. I'm stumped about what the cause might be. At this point I wonder if it might be a multithread concurrent access issue. But if so, I really can't imagine what problem that would cause since the threads are only reading from the Pass List table. Once startup is complete, nothing writes to the Pass List again.
I will build a debug version of Suricata and step through the blocking module code line-by-line to see if something presents itself.
-
@bmeeks maybe we can try with another volunteer here on the forum that have a baremetal pfSense box. I really want to help you!
If you need anything else let me know
When I'll be home tonight I'll post the other files. -
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks maybe we can try with another volunteer here on the forum that have a baremetal pfSense box. I really want to help you!
If you need anything else let me know
When I'll be home tonight I'll post the other files.I have an idea of what might be happening. If I am correct, it is a multiple thread concurrent access problem when checking and/or updating the Pass List.
Will you check your
suricata.log
file for the interfaces where LAN hosts are getting blocked and see if there are instances of IP addresses being added and removed for firewall interfaces? These will be tagged with some text similar to either "...added address xxxx to automatic firewall interface IP Pass List..." or "...deleted address xxxx from automatic firewall interface IP Pass List...". I'm curious if the timestamps logged for any of these messages correspond with the timestamps of any LAN host blocks.It may be that the Pass List table in memory is being updated by one thread at the same time another thread is trying to read from it. That could cause a problem where an IP that is actually on the Pass List is getting reported back as not being in the list. This would also explain why I have trouble duplicating the bug because my VM is stable after coming up, and no firewall interface IPs change nor do the interfaces themselves cycle up and down. And my traffic load is very light. So I would likely not have the conditions to trigger the bug.
I noticed in your previously posted logs that some firewall interface IPs were logged as changing. It looked like maybe an interface cycled, or perhaps it's a VPN tunnel coming up and down ???
-
@bmeeks said in Suricata is blocking LAN and WAN IPs:
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks maybe we can try with another volunteer here on the forum that have a baremetal pfSense box. I really want to help you!
If you need anything else let me know
When I'll be home tonight I'll post the other files.I have an idea of what might be happening. If I am correct, it is a multiple thread concurrent access problem when checking and/or updating the Pass List.
Will you check your
suricata.log
file for the interfaces where LAN hosts are getting blocked and see if there are instances of IP addresses being added and removed for firewall interfaces? These will be tagged with some text similar to either "...added address xxxx to automatic firewall interface IP Pass List..." or "...deleted address xxxx from automatic firewall interface IP Pass List...". I'm curious if the timestamps logged for any of these messages correspond with the timestamps of any LAN host blocks.I've quickly check my first suricata.log and i see 10.10.10.1 and 10.10.20.254, both are VIP, one from dnsbl and the other is the haproxy VIP. But these IPs weren't blocked by suricata.
I'll check from my desktop when I'll be home. -
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks said in Suricata is blocking LAN and WAN IPs:
@xm4rcell0x said in Suricata is blocking LAN and WAN IPs:
@bmeeks maybe we can try with another volunteer here on the forum that have a baremetal pfSense box. I really want to help you!
If you need anything else let me know
When I'll be home tonight I'll post the other files.I have an idea of what might be happening. If I am correct, it is a multiple thread concurrent access problem when checking and/or updating the Pass List.
Will you check your
suricata.log
file for the interfaces where LAN hosts are getting blocked and see if there are instances of IP addresses being added and removed for firewall interfaces? These will be tagged with some text similar to either "...added address xxxx to automatic firewall interface IP Pass List..." or "...deleted address xxxx from automatic firewall interface IP Pass List...". I'm curious if the timestamps logged for any of these messages correspond with the timestamps of any LAN host blocks.I've quickly check my first suricata.log and i see 10.10.10.1 and 10.10.20.254, both are VIP, one from dnsbl and the other is the haproxy VIP. But these IPs weren't blocked by suricata.
I'll check from my desktop when I'll be home.It's a bit more complicated than those particular IPs getting blocked. I've received your PM with your email address and will respond there with some more details when I send the test package.
-
With the new version I wanted to give it another try. But hell no, Suricata is still blocking me.
I also wouldn't mind some progress here.