Can confirm that this works now for me... > On 17 Feb 2019, at 19:57, Stefan Schantl 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 >>> 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-full-core128.iso >>> >>> 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