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

> 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