Bug #6690
closed
SURICATA IPS Issue - Kills VLANS & Traffic Shaper
0%
Description
Strips 802.1q tagged traffic from an interface when running inline IPS mode.
Traffic shapper no longer works as one single interface can use up the whole upstream bandwidth.
Updated by Jim Thompson over 8 years ago
- Category set to Suricata
- Assignee set to Luiz Souza
- Target version set to 2.4.0
- Affected Version set to 2.3.x
- Affected Architecture All added
- Affected Architecture deleted (
)
Updated by Sandeep K V over 8 years ago
Hi Steven Kreitzer and Jim Thompson isn't this the expected way the IPS has to work?
Updated by Steven Kreitzer over 8 years ago
Sandeep K V wrote:
Hi Steven Kreitzer and Jim Thompson isn't this the expected way the IPS has to work?
No, and it definitely shouldn't be stripping 802.1q traffic. I know it uses netcap and it may be an error on netcaps side.
Updated by Kill Bill about 8 years ago
There's already #6023 for netmap + shaping.
Updated by Kill Bill almost 8 years ago
In general, I'd say people who wish to use Snort/Suricata as IPS should look into divert sockets instead. The netmap thing is super-broken, hardware limited and in general not getting anywhere AFAICT.
Updated by Jim Thompson almost 8 years ago
Steven Kreitzer wrote:
Sandeep K V wrote:
Hi Steven Kreitzer and Jim Thompson isn't this the expected way the IPS has to work?
No, and it definitely shouldn't be stripping 802.1q traffic. I know it uses netcap and it may be an error on netcaps side.
My guess is that Suricata is stripping the tags. Likely the queue info is getting lost somewhere in that path as well.
Updated by Jim Thompson almost 8 years ago
Kill Bill wrote:
There's already #6023 for netmap + shaping.
"Shaping" is a hack that shouldn't have happened.
Updated by Jens Leinenbach over 7 years ago
Jim Thompson wrote:
Steven Kreitzer wrote:
Sandeep K V wrote:
Hi Steven Kreitzer and Jim Thompson isn't this the expected way the IPS has to work?
No, and it definitely shouldn't be stripping 802.1q traffic. I know it uses netcap and it may be an error on netcaps side.
My guess is that Suricata is stripping the tags. Likely the queue info is getting lost somewhere in that path as well.
A VLAN tag bug was fixed with Suricata version 3.2.1 that is available for pfSense. Can somebody please verify if this bug still exists as I think I had this issue with version 3.2.1.
https://redmine.openinfosecfoundation.org/issues/1780
Updated by Luiz Souza over 7 years ago
- Target version changed from 2.4.0 to 2.4.1
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.1 to 2.4.2
Updated by Jim Pingle about 7 years ago
- Target version changed from 2.4.2 to 2.4.3
Updated by Jim Pingle almost 7 years ago
- Status changed from New to Feedback
- Target version changed from 2.4.3 to 2.4.4
Still waiting on feedback/new testing on current versions of pfSense and suricata
Updated by Anonymous over 6 years ago
- Status changed from Feedback to Closed
- Target version deleted (
2.4.4)
Marking this closed due to lack of feedback. If you believe this should be reopened, please let us know.
Updated by Tenzen Tunkman almost 5 years ago
This issue is still not solved - Inline filtering will break traffic shaping as well as for example traffic graph functionality
Updated by Bill Meeks almost 5 years ago
Tenzen Tunkman wrote:
This issue is still not solved - Inline filtering will break traffic shaping as well as for example traffic graph functionality
This may actually be a limitation inherent in the way netmap works and not really a bug that is easily fixable. Netmap is a somewhat radically different "plumbing method" for routing network traffic, and as such is likely to break other ancilary features like limiters that rely on the more conventional kernel-based network plumbing.
If a user has a strong need for limiters, it may be better to put Suricata on a different hardware platform either upstream of downstream of the firewall such that the limiter can run on the firewall with conventional networking while the inline IPS executes on a different box where the unconventional netmap re-mapping of the network plumbing won't impact limiters or traffic graphing. I get this is not as attractive as a one-box solution, but with some technologies there are tradeoffs.