Consider the following setup:
- VPC 1 exposes 10.0.1.0/24, no NAT
- VPC 2 exposes public prefix 10.0.10.0/24 (masqueraded) to VPC 1
- VPC 3 exposes public prefix 10.0.10.0/24 (masqueraded) to VPC 1
- There's a flow VPC 1 <-> VPC 2: 10.0.1.1 <-> 10.0.10.1
- There's a flow VPC 1 <-> VPC 3: 10.0.1.1 <-> 10.0.10.1
Then a config update happens. If the genid bump happens between the flow table lookup and the flow-filter processing for reply traffic for the two flows, the connection may break.
This is because currently, if we detect that the flow is outdated, we try to re-validate the flow with a flow-filter table lookup. But there are colliding entries: in the destination-lookup table, both exposed prefixes created entries for the reply traffic with source VPC: VPC 1, and destination prefix: 10.0.10.1. Only the first matching entry in the table is returned; one of the two flows will get the wrong destination VPC id, which will not match the data in the flow info for the packet, and will lead to the packet being dropped and the flow invalidated.
Reported by Daniel.
Consider the following setup:
Then a config update happens. If the genid bump happens between the flow table lookup and the flow-filter processing for reply traffic for the two flows, the connection may break.
This is because currently, if we detect that the flow is outdated, we try to re-validate the flow with a flow-filter table lookup. But there are colliding entries: in the destination-lookup table, both exposed prefixes created entries for the reply traffic with source VPC: VPC 1, and destination prefix: 10.0.10.1. Only the first matching entry in the table is returned; one of the two flows will get the wrong destination VPC id, which will not match the data in the flow info for the packet, and will lead to the packet being dropped and the flow invalidated.
Reported by Daniel.