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.
This function call is the culprit for DVR routers.
https:/
The DVR routers are scheduled always to the network node but the routers on the compute hosts are created based on the requirement.