From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: IPFire meets Suricata - Call for tester Date: Mon, 18 Feb 2019 11:44:18 +0000 Message-ID: <28BE7DED-AB1F-411B-8158-60DEF034AB53@ipfire.org> In-Reply-To: <5e337fe8b5f9b059de6b7510aa897635a6cbf5d9.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2903490995720410538==" List-Id: --===============2903490995720410538== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Can confirm that this works now for me... > On 17 Feb 2019, at 19:57, Stefan Schantl wrot= e: >=20 > Hello Michael, >=20 > thanks for your feedback. >> Hello Suricata Testing Community, >> Hello Stefan, >>=20 >> I just installed the =E2=80=9Crc2=E2=80=9D image on my production system o= n my desk. >>=20 >> 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. >>=20 >> Not sure what I can do about this now. >=20 > Finally I figured out, why this happened to you and Wayne (which also > reported this issue) and I was not able to reproduce that. >=20 > 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. >=20 > If all 4 possible interfaces are present, the mark "3" also is in use > for SNAT. >=20 > Snip from "iptables -L -v -n -t nat" >=20 > Chain NAT_DESTINATION_FIX (1 references) > pkts bytes target prot opt > in out source destination =20 > 0 0 SNAT all =20 > -- * * 0.0.0.0/0 0.0.0.0/0 mark match > 0x1 to:192.168.xxx.xxx > 728 83711 SNAT all =20 > -- * * 0.0.0.0/0 0.0.0.0/0 mark match > 0x2 to:192.168.xxx.xxx > 0 0 SNAT all =20 > -- * * 0.0.0.0/0 0.0.0.0/0 mark match > 0x3 to:192.168.xxx.xxx >=20 > 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. >=20 > 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 ? >=20 > Thanks in advance, >=20 > -Stefan >=20 >>=20 >> I found that this is a bug:=20 >> https://bugzilla.ipfire.org/show_bug.cgi?id=3D12002 >>=20 >> -Michael >>=20 >>> On 17 Feb 2019, at 11:58, Stefan Schantl >>> wrote: >>>=20 >>> Hello list, >>>=20 >>> a short note from suricata development. I've uploaded the second >>> release candidate, which fixes several issues and bugs. >>>=20 >>> Now, the "services.cgi" will correctly show the IPS as running, and >>> logrotate and collectd will handle the correct service. >>>=20 >>> The new tarball (i586 for 32bit-systems, and x86_64) can be found >>> here: >>>=20 >>> https://people.ipfire.org/~stevee/suricata/ >>>=20 >>> To start testing download the tarball and place it on your IPFire >>> system. Extract the tarball and launch the install (install.sh) >>> script. >>>=20 >>> 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. >>>=20 >>> As always, if you prefer a fresh installation, the latest image can >>> be >>> grabbed >>> from here: >>>=20 >>> https://nightly.ipfire.org/next-suricata/latest/x86_64/ >>>=20 >>> Direct link for downloading the ISO image: >>>=20 >>> https://nightly.ipfire.org/next-suricata/latest/x86_64/ipfire-2.21.x86_64= -full-core128.iso >>>=20 >>> 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. >>>=20 >>> Best regards, >>>=20 >>> -Stefan --===============2903490995720410538==--