Security group mismatch for floating IP
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
DragonFlow |
New
|
High
|
Omer Anson |
Bug Description
Scenario:
1. Create two separate private networks, two separate routers, and connect the private networks (separately) to the public network
2. Define two VMs on the separate private networks
3. Assign each VM a floating IP.
4. (optional) Modify security groups to allow ICMP ingress from *ALL* IPs and verify ping succeeds, then remove this rule.
5. Modify security group to allow ICMP ingress from the other VMs security group (if same security group, put the current security group)
6. See that ping fails.
Expected scenario:
Ping succeeds in point 6.
Analysis:
The security rules installed match by the original IP address. However, the
packet arrives with its floating IP as source. Therefore, the match fails.
Additional Tasks:
* Revert https:/
description: | updated |
Changed in dragonflow: | |
assignee: | nobody → Omer Anson (omer-anson) |
I think the best plan of attack would be to test against source port IDs (reg6) rather than IP addresses. This raises the problem that reg6 must always be set to the correct value. This is mostly correct, except for a few apps:
* Tunneling
* dNAT
* Provider network
* SFC
For dNAT and provider network, we can infer reg6 from the incoming packet by source IP and network or source IP and MAC.
For SFC, we should have all the information available, we just need to re-set reg6 once the packet finished the SFC flow.
For tunneling, there are two options:
1. Infer all routable addresses to the network, and then infer from source IP and network. (preferred)
2. Do the routing both on the source and destination node. The packet sent through the tunnel will be the original tunnel (before routing), and routing will be done again on the destination node (routing will be done twice!)
3. Encode the reg6 value somewhere on the packet, e.g. source MAC address, and then (optionally) re-encode the correct MAC on the destination node.
Option 1 is preferred, because it is the only option allowing full interoperability (option 3 won't work if the tunnel source is an e.g. DVR compute node).
Action Items:
1-4. Update dNAT app
1-4. Update provider network app
1-4. Update SFC app
1-4. Update tunnelling app
5. Update SecGroup
This solution only works for 'ingress' rules. For 'egress' rules, we may want to move them to a point where we know the destination port (reg7) and then match by port and not by IP as well.