From: Stefan Schantl <stefan.schantl@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: IPFire meets Suricata - Call for tester
Date: Mon, 18 Feb 2019 14:09:47 +0100 [thread overview]
Message-ID: <99013cc160a0dcac6c4447e11607e13491d08a07.camel@ipfire.org> (raw)
In-Reply-To: <28BE7DED-AB1F-411B-8158-60DEF034AB53@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 4395 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2019-02-18 13:09 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 19:43 Stefan Schantl
2018-12-11 20:53 ` Peter Müller
2018-12-12 20:54 ` Peter Müller
2018-12-16 20:28 ` Peter Müller
2018-12-17 14:21 ` Stefan Schantl
2018-12-17 17:05 ` Michael Tremer
2018-12-17 19:08 ` Stefan Schantl
2018-12-19 16:30 ` Michael Tremer
2018-12-20 13:03 ` Stefan Schantl
2018-12-20 14:05 ` Michael Tremer
2018-12-21 16:03 ` Tim FitzGeorge
2018-12-25 19:17 ` Stefan Schantl
2018-12-25 21:56 ` Michael Tremer
2018-12-25 19:03 ` Stefan Schantl
2019-01-01 13:32 ` Stefan Schantl
2019-01-02 15:54 ` Michael Tremer
2019-02-06 8:58 ` Stefan Schantl
2019-02-14 14:28 ` Stefan Schantl
2019-02-14 15:20 ` ummeegge
2019-02-14 18:01 ` Matthias Fischer
2019-02-14 21:49 ` Stefan Schantl
2019-02-14 23:16 ` Matthias Fischer
2019-02-14 23:36 ` Mentalic
2019-02-15 7:51 ` Stefan Schantl
2019-02-15 0:03 ` Mentalic
2019-02-15 7:54 ` Stefan Schantl
2019-02-17 11:58 ` Stefan Schantl
2019-02-17 12:59 ` Michael Tremer
2019-02-17 19:57 ` Stefan Schantl
2019-02-18 11:44 ` Michael Tremer
2019-02-18 13:09 ` Stefan Schantl [this message]
2019-03-03 11:37 ` ummeegge
2019-03-03 18:48 ` Stefan Schantl
2019-03-04 6:28 ` ummeegge
2019-02-18 13:16 ` Stefan Schantl
2019-02-18 22:11 ` Mentalic
2019-02-19 11:33 ` Stefan Schantl
2019-02-19 22:12 ` Mentalic
2019-02-19 23:22 ` Mentalic
2019-02-20 7:55 ` Stefan Schantl
2019-02-21 21:56 ` Mentalic
2019-02-22 10:21 ` Michael Tremer
2019-02-22 11:08 ` Stefan Schantl
2019-02-22 10:59 ` Stefan Schantl
2019-02-22 18:40 ` Mentalic
2019-02-20 7:19 ` Stefan Schantl
2019-03-03 14:39 ` Stefan Schantl
2019-03-03 17:33 ` Mentalic
2019-03-04 19:54 ` Mentalic
2019-03-05 9:31 ` Michael Tremer
[not found] <E1gf64O-0003zJ-Kt@smtprelay03.ispgateway.de>
2019-01-06 13:26 ` IPFire meets Suricata - Call for Tester Stefan Schantl
[not found] <79FF884C-B36B-42F5-A620-F2636E3706FC@gmail.com>
2019-02-06 9:57 ` IPFire meets Suricata - Call for tester Stefan Schantl
2019-02-06 10:43 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99013cc160a0dcac6c4447e11607e13491d08a07.camel@ipfire.org \
--to=stefan.schantl@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox