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(a)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(a)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-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