security groups iptables can block legitimate traffic as INVALID
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Kevin Benton | ||
Juno |
Fix Released
|
Undecided
|
Unassigned | ||
Kilo |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
The iptables implementation of security groups includes a default rule to drop any INVALID packets (according to the Linux connection state tracking system.) It looks like this:
-A neutron-
This is placed near the top of the rule stack, before any security group rules added by the user. See:
https:/
https:/
However, there are some cases where you would not want traffic marked as INVALID to be dropped here. Specifically, our use case:
We have a load balancing scheme where requests from the LB are tunneled as IP-in-IP encapsulation between the LB and the VM. Response traffic is configured for DSR, so the responses go directly out the default gateway of the VM.
The results of this are iptables on the hypervisor does not see the initial SYN from the LB to VM (because it is encapsulated in IP-in-IP), and thus it does not make it into the connection table. The response that comes out of the VM (not encapsulated) hits iptables on the hypervisor and is dropped as invalid.
I'd like to see a Neutron option to enable/disable the population of this INVALID state rule, so that operators (such as us) can disable it if desired. Obviously it's better in general to keep it in there to drop invalid packets, but there are cases where you would like to not do this.
Changed in neutron: | |
status: | Confirmed → In Progress |
Changed in neutron: | |
importance: | Undecided → Medium |
milestone: | none → liberty-rc1 |
Changed in neutron: | |
status: | Fix Committed → Fix Released |
tags: | added: kilo-backport-potential |
tags: | added: juno-backport-potential |
Changed in neutron: | |
milestone: | liberty-rc1 → 7.0.0 |
This is also an issue in Juno. We have a different use case than the original (sctp instead of IP-IP), but the same underlying issue is causing valid SCTP packets to be dropped.