Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flow: Add test for excluding pkt recursion from flow #1597

Conversation

coledishington
Copy link
Contributor

Add tests for verifying matching packet flows when including and excluding pkt recursion from flow matching.

Bug: #6260

Redmine ticket:
https://redmine.openinfosecfoundation.org/issues/6260

Add tests for verifying matching packet flows when including and
excluding pkt recursion from flow matching.

Bug: #6260
@catenacyber
Copy link
Collaborator

Looks good to me with the suricata PR

@jufajardini
Copy link
Contributor

I see that IPS mode is mentioned in the README, but didn't see a test that simulated ips mode. Shouldn't there be one, or isn't that relevant for the changes?

@coledishington
Copy link
Contributor Author

I see that IPS mode is mentioned in the README, but didn't see a test that simulated ips mode. Shouldn't there be one, or isn't that relevant for the changes?

IPS simulation shouldn't make a difference as this feature is related to stitching traffic together when one side is detected before tunnel encapsulation and the other side is detected before tunnel decapsulation. e.g. For an ipv6 tunnel
request: IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP]
reply: <- |IPS| <- IPv6]IPv4]ICMP]

This is relevant when the IDS/IPS is also the tunnel terminator.

@jufajardini As both IDS and IPS mode would work in this scenario, I am happy to enable --simulate-ips if it makes more sense.

@jufajardini
Copy link
Contributor

I see that IPS mode is mentioned in the README, but didn't see a test that simulated ips mode. Shouldn't there be one, or isn't that relevant for the changes?

IPS simulation shouldn't make a difference as this feature is related to stitching traffic together when one side is detected before tunnel encapsulation and the other side is detected before tunnel decapsulation. e.g. For an ipv6 tunnel request: IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP] reply: <- |IPS| <- IPv6]IPv4]ICMP]

This is relevant when the IDS/IPS is also the tunnel terminator.

@jufajardini As both IDS and IPS mode would work in this scenario, I am happy to enable --simulate-ips if it makes more sense.

[Sorry for the very late answer] considering that it should work for both, I think that ideally we would have tests for both scenarios :P

@coledishington
Copy link
Contributor Author

coledishington commented Oct 8, 2024

I see that IPS mode is mentioned in the README, but didn't see a test that simulated ips mode. Shouldn't there be one, or isn't that relevant for the changes?

IPS simulation shouldn't make a difference as this feature is related to stitching traffic together when one side is detected before tunnel encapsulation and the other side is detected before tunnel decapsulation. e.g. For an ipv6 tunnel request: IPv4]ICMP] -> |IPS| -> IPv6]IPv4]ICMP] reply: <- |IPS| <- IPv6]IPv4]ICMP]
This is relevant when the IDS/IPS is also the tunnel terminator.
@jufajardini As both IDS and IPS mode would work in this scenario, I am happy to enable --simulate-ips if it makes more sense.

[Sorry for the very late answer] considering that it should work for both, I think that ideally we would have tests for both scenarios :P

Thanks for the comments, I have addressed them in #2081.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
requires suricata pr Depends on a PR in Suricata
Development

Successfully merging this pull request may close these issues.

3 participants