[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13843495#comment-13843495 ]
Will Stevens commented on CLOUDSTACK-5278: ------------------------------------------ Sorry for the delay getting back to you. I had some issues getting my dev environment back up and running after pulling the latest 4.3 branch. Yes, I have tested your diff with my code and the latest code on 4.3 and everything works fine in my plugin. I will be posting a bug for my plugin with my patch to fix it a little later this afternoon. Thanks for the hard work, Will > Egress Firewall rules clarifications > ------------------------------------ > > Key: CLOUDSTACK-5278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Affects Versions: 4.3.0 > Reporter: Will Stevens > Assignee: Jayapal Reddy > Priority: Critical > Fix For: 4.3.0 > > Attachments: diff.txt, diff.txt > > > These issues may also exist in the 4.2 branch, but I am currently > testing/working on the 4.3 branch. > I believe these bugs were introduced with the change to the Network Service > Offering to add the 'Default egress policy' dropdown. > https://issues.apache.org/jira/browse/CLOUDSTACK-1578 > I am trying to resolve the bugs this change introduced in the Palo Alto > plugin. > There are two types of Egress rules (from what I can tell). > - FirewallRule.FirewallRuleType.System : this appears to be set up by the > system on network creation to correspond to the global network default > allow/deny egress rule. > - FirewallRule.FirewallRuleType.User : any rule that a user creates through > the UI will get this type. > There are bugs associated with both of the options in the dropdown (allow and > deny). > Case: 'deny' > - When the network is setup, it does not try to create the global deny rule > for the network, but it appears to register that it exists. Instead, when > the first egress rule is created by a user, the system sees both the 'system' > and 'user' rules, so it will create both rules then. > Case: both 'allow' and 'deny' > - The clean up of the network global 'system' egress rules are never done. > So when a network is deleted, it will leave an orphaned egress rule > associated with the previous network's cidr. This is bound to cause many > issues. > - Even worse, it appears that the ID for the network global 'system' egress > rule is hardcoded to '0'. Every time I try to spin up a new network it will > attempt to create a rule with a '0' ID, but since one already exists with > that ID, there is a config collision. In my case (Palo Alto), the second > rule with the same ID gets ignored because it checks to see if the rule > exists and it gets a 'yes' back because the previous network has an egress > rule with that ID already. > Let me know if you have additional questions... -- This message was sent by Atlassian JIRA (v6.1.4#6159)