Public bug reported: This was seen in Rocky.
When network, subnet, router and a VM instance created with a FloatingIP before attaching FireWall rules to the router, causes the Firewall rules not to be applied to the 'rfp' port for north-south routing when using Firewall-as-Service in legacy 'iptables' mode. After applying the Firewall rules to the Router, it is expected that the router-update would trigger adding the Firewall rules to the existing routers, but the logic is not right. Any new VMs added to the subnet on a new compute host, gets the Firewall rules applied to the 'rfp' interface. So the only way to get around this problem is to restart the 'l3-agent'. Once the 'l3-agent' is restarted, the Firewall rules are applied again. This is also true when Firewall rules are removed after the VM and routers are in place, since the update is not handled properly, the firewall rules may stay there until we reboot the l3-agent. How to reproduce this problem: This is FWaaS v2 with legacy 'iptables': 1. Create a Network 2. Create a Subnet 3. Create a Router (DVR) 4. Attach the Subnet to the router. 5. Assign the gateway to the router. 6. Create a VM on the given private network. 7. Create a FloatingIP and associate the FloatingIP to the VM's private IP. 8. Now the VM, router, fipnamespace are all in place. 9. Now create Firwall rules neutron firewall-rule-create --protocol icmp --action allow --name allow-icmp neutron firewall-rule-create --protocol tcp --destination-port 80 --action deny --name deny-http neutron firewall-rule-create --protocol tcp --destination-port 22 --action allow --name allow-ssh 10. Then create firewall policy neutron firewall-policy-create --firewall-rules "allow-icmp deny-http allow-ssh" policy-fw 11. Create a firewall neutron firewall-create policy-fw --name user-fw 12. Check if the firewall was created: neutron firewall-show user-fw 13. If the firewall was created after the router have been created, based on the documentation you need to manually update the router. $ neutron firewall-update —router <router-1-id> —router <router-2-id> <firewall-name> 14. After the update we would expect that all existing router-1 and router-2 to have the firewall rules. But we don't see if configured for the router-1 that was created before the firewall was created. And so the VM is not protected by the Firewall rules. ** Affects: neutron Importance: Undecided Assignee: Swaminathan Vasudevan (swaminathan-vasudevan) Status: Confirmed ** Tags: fwaas l3-dvr-backlog ** Changed in: neutron Assignee: (unassigned) => Swaminathan Vasudevan (swaminathan-vasudevan) ** Changed in: neutron Status: New => Confirmed ** Summary changed: - DVR: FWaaS rules created for a router after the FIP and VM created not applied to routers rfp port + DVR: FWaaS rules created for a router after the FIP and VM created, not applied to routers rfp port on router-update -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1845557 Title: DVR: FWaaS rules created for a router after the FIP and VM created, not applied to routers rfp port on router-update Status in neutron: Confirmed Bug description: This was seen in Rocky. When network, subnet, router and a VM instance created with a FloatingIP before attaching FireWall rules to the router, causes the Firewall rules not to be applied to the 'rfp' port for north-south routing when using Firewall-as-Service in legacy 'iptables' mode. After applying the Firewall rules to the Router, it is expected that the router-update would trigger adding the Firewall rules to the existing routers, but the logic is not right. Any new VMs added to the subnet on a new compute host, gets the Firewall rules applied to the 'rfp' interface. So the only way to get around this problem is to restart the 'l3-agent'. Once the 'l3-agent' is restarted, the Firewall rules are applied again. This is also true when Firewall rules are removed after the VM and routers are in place, since the update is not handled properly, the firewall rules may stay there until we reboot the l3-agent. How to reproduce this problem: This is FWaaS v2 with legacy 'iptables': 1. Create a Network 2. Create a Subnet 3. Create a Router (DVR) 4. Attach the Subnet to the router. 5. Assign the gateway to the router. 6. Create a VM on the given private network. 7. Create a FloatingIP and associate the FloatingIP to the VM's private IP. 8. Now the VM, router, fipnamespace are all in place. 9. Now create Firwall rules neutron firewall-rule-create --protocol icmp --action allow --name allow-icmp neutron firewall-rule-create --protocol tcp --destination-port 80 --action deny --name deny-http neutron firewall-rule-create --protocol tcp --destination-port 22 --action allow --name allow-ssh 10. Then create firewall policy neutron firewall-policy-create --firewall-rules "allow-icmp deny-http allow-ssh" policy-fw 11. Create a firewall neutron firewall-create policy-fw --name user-fw 12. Check if the firewall was created: neutron firewall-show user-fw 13. If the firewall was created after the router have been created, based on the documentation you need to manually update the router. $ neutron firewall-update —router <router-1-id> —router <router-2-id> <firewall-name> 14. After the update we would expect that all existing router-1 and router-2 to have the firewall rules. But we don't see if configured for the router-1 that was created before the firewall was created. And so the VM is not protected by the Firewall rules. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1845557/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp