yahoo-eng-team team mailing list archive

[Swaminathan Vasudevan <souminathan@xxxxxxxxx>]

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