> What is the bypass mark for? At least that should be set to nothing
> instead of one, because that will again conflict with the SNAT fix
> rule.
> 
> Best,
> -Michael
> 
Hello Michael,

taken from the official suricata.yaml documentation:

bypass mark and mask can be used to implement NFQ bypass. If bypass
mark is set then the NFQ bypass is activated. Suricata will set the
bypass mark/mask on packet of a flow that need to be bypassed. The
Nefilter ruleset has to directly accept all packets of a flow once a
packet has been marked.

In my commit, I've disabled the bypass options to exactly prevent from
any issuse again with the SNAT packet mark.

Best regards,

-Stefan

> > On 17 Dec 2018, at 14:21, Stefan Schantl <stefan.schantl(a)ipfire.org
> > > wrote:
> > 
> > Am Sonntag, den 16.12.2018, 21:28 +0100 schrieb Peter Müller:
> > > Hello Stefan,
> > > 
> > > to be a bit more precise about the NAT issue:
> > > 
> > > My setup is the IPFire Suricata test VM running in KVM, with
> > > two clients (Debian and OpenBSD) directly attached to it.
> > > 
> > > The Debian machine is located in GREEN, OpenBSD in ORANGE.
> > > RED interface is connected via bridge to my actual testing LAN;
> > > for the first testing, any outgoing traffic to the internet
> > > was allowed (I will test upstream proxy behaviour later).
> > > 
> > > While GREEN was using IPv4 range 192.168.100.0/24, with IPFire
> > > as 192.168.100.1, enabling Suricata caused packets coming from
> > > GREEN not to be NATted anymore: Instead of using the firewall's
> > > RED IP for destination, it was the internal GREEN IP.
> > > 
> > > Let me know whether is is useful or not. :-)
> > > 
> > > Thanks, and best regards,
> > > Peter Müller
> > > 
> > > > Hello Stefan,
> > > > 
> > > > back again. :-)
> > > > 
> > > > The new IDS WebUI looks quite good so far - enabling/disabling
> > > > Suricata works as well as selecting the rule source and the
> > > > operation mode (IDS/IPS).
> > > > 
> > > > I was also able to download the "Snort/VRT Community" ruleset.
> > > > Trying to switch to the "Emerging Threats" ruleset is possible,
> > > > but downloading its ruleset afterwards is not: The GUI simply
> > > > stalls, printing a message that "Snort (!) is performing a
> > > > task".
> > > > 
> > > > The WebUI services page still shows IDS status for each
> > > > interface,
> > > > which does not seem to work anymore (everything is stopped, but
> > > > Suricata was active on RED and GREEN).
> > > > 
> > > > Further, a client located in GREEN behind the test firewall
> > > > instance is unable to browse the internet as soon as Suricata
> > > > is
> > > > enabled. If disabled, downloading ET rulesets work as well as
> > > > internet traffic. At the moment, I am flying blind here, but it
> > > > looks
> > > > like packets are not NATted anymore if Suricata is active.
> > > > 
> > > > Any outgoing connection is in state "SYN_SENT" if Suricata is
> > > > active.
> > > > 
> > > > A portscan against the firewall (GREEN interface) is not
> > > > detected,
> > > > even though ET SCAN ruleset is enabled (used nmap with NSE
> > > > active).
> > > > 
> > > > Especially the outgoing connection/NAT/? issue mentioned above
> > > > breaks things in my scenario. Anything else are minor issues
> > > > (of
> > > > course, a portscan should be detected, this needs further
> > > > investigation
> > > > indeed). WebUI works fine so far.
> > > > 
> > > > Thanks again for your work; I hope the feedback can appreciate
> > > > it
> > > > somehow. :-)
> > > > 
> > > > Let me know if there are questions.
> > > > 
> > > > Thanks, and best regards,
> > > > Peter Müller
> > > > 
> > Hello Peter,
> > 
> > thanks for testing and your feedback.
> > 
> > I've setup a test environment and was able to re-produce your NAT
> > issue
> > very easy. After some research and help of Michael, we were able to
> > find the real issue.
> > 
> > It was located in a identical mark on the packets which already
> > have
> > been scanned by suricata and packets which should be modified for
> > SNAT
> > in the "Mangle" table of the routing logic by the kernel.
> > 
> > The changes can be found in my git repository:
> > 
> > https://git.ipfire.org/?p=people/stevee/ipfire-2.x.git;a=commit;h=f5ad510e3c0f416a1507999f5ad20ab171df9c07
> > 
> > I'll upload a fixed image very soon - please keep on testing.
> > 
> > Best regards,
> > 
> > -Stefan