Hello Michael,
thanks for the feedback, nice to hear, that this issue is fixed now.
Best regards,
-Stefan
Can confirm that this works now for me...
On 17 Feb 2019, at 19:57, Stefan Schantl <stefan.schantl@ipfire.org
wrote:
Hello Michael,
thanks for your feedback.
Hello Suricata Testing Community, Hello Stefan,
I just installed the “rc2” image on my production system on my desk.
I am afraid that I can confirm that no new connections are possible any more after Suricata is being started. I suppose this is due to some of the latest changes to the suricata configuration file. The iptables chains look fine and some other traffic continues to pass.
Not sure what I can do about this now.
Finally I figured out, why this happened to you and Wayne (which also reported this issue) and I was not able to reproduce that.
During development we have got this issue one, because of SNAT used the default mark of "1" to mark it's packets. This internal mark will be increased by each interface, so if you are using blue or orange too, the mark "2" (which currently is used by suricata) also is in use.
If all 4 possible interfaces are present, the mark "3" also is in use for SNAT.
Snip from "iptables -L -v -n -t nat"
Chain NAT_DESTINATION_FIX (1 references) pkts bytes target prot opt in out source destination 0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x1 to:192.168.xxx.xxx 728 83711 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x2 to:192.168.xxx.xxx 0 0 SNAT all -- * * 0.0.0.0/0 0.0.0.0/0 mark match 0x3 to:192.168.xxx.xxx
So we have at least to use "4" to mark the packets which are inspected by suricata - which worked on the testmachine with full interface configuration.
But what happened if OpenVPN or IPsec is also in use and clients are connected ? Will there be spawned any additional rules with marks and we ran into the same issue again ? What would be a good mark default for suricata to prevent from this ?
Thanks in advance,
-Stefan
I found that this is a bug: https://bugzilla.ipfire.org/show_bug.cgi?id=12002
-Michael
On 17 Feb 2019, at 11:58, Stefan Schantl < stefan.schantl@ipfire.org
wrote:
Hello list,
a short note from suricata development. I've uploaded the second release candidate, which fixes several issues and bugs.
Now, the "services.cgi" will correctly show the IPS as running, and logrotate and collectd will handle the correct service.
The new tarball (i586 for 32bit-systems, and x86_64) can be found here:
https://people.ipfire.org/~stevee/suricata/
To start testing download the tarball and place it on your IPFire system. Extract the tarball and launch the install (install.sh) script.
If you already have installed a previous test version or image, with the same steps as noted above you can update the the new version.
As always, if you prefer a fresh installation, the latest image can be grabbed from here:
https://nightly.ipfire.org/next-suricata/latest/x86_64/
Direct link for downloading the ISO image:
https://nightly.ipfire.org/next-suricata/latest/x86_64/ipfire-2.21.x86_64-fu...
Thanks for downloading and testing. There are no known bugs so far, as usual please file any bugs to our bugtracker ( https://bugzilla.ipfire.org) and share your feedback on the list.
Best regards,
-Stefan