Bug 12010 - suricata causes that on-demand IPsec VPNs no longer trigger
Summary: suricata causes that on-demand IPsec VPNs no longer trigger
Status: CLOSED FIXED
Alias: None
Product: IPFire
Classification: Unclassified
Component: --- (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: Will affect an average number of users Major Usability
Assignee: Stefan Schantl
QA Contact:
URL:
Keywords:
Depends on:
Blocks: SURICATA
  Show dependency treegraph
 
Reported: 2019-02-27 15:12 UTC by Michael Tremer
Modified: 2019-03-03 18:52 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Tremer 2019-02-27 15:12:48 UTC
I have pretty much all my IPsec VPNs set up in on-demand mode. Sometimes they are down because the firewall shuts them down after some inactivity.

When suricata is enabled, they will no longer automatically be triggered to start again any more. This is a really huge problem and I needed to disabled suricata because of this.

I tried to deactivate rules because it might have been that this was hit. However, none of the rules seems to match any traffic unexpectedly. Even with all rules deactivated, the VPNs won't come up.

When suricata is disabled, the VPN is up within a second.
Comment 1 Michael Tremer 2019-02-28 14:22:53 UTC
Update from today: When suricata is started, new connections through the IPsec tunnels won't function. Restarting a single tunnel does not work, the whole IPsec stack has to be restarted with "ipsec restart".

The IPsec connection however is triggered and coming up. All packets leave the RED interface (which is dangerous and should absolutely not happen - we even have a firewall chain against this which does not match any more).

It does not look like it is the marking, but I am not sure about that.
Comment 2 Michael Tremer 2019-02-28 19:39:05 UTC
https://patchwork.ipfire.org/patch/2121/
Comment 3 Stefan Schantl 2019-03-03 18:52:02 UTC
Thanks for the patch - merged.