[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840959#comment-13840959 ]
Will Stevens commented on CLOUDSTACK-5278: ------------------------------------------ Great thanks. I will test the patch in my environment in the morning... > 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 > > > 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#6144)