[jira] [Comment Edited] (CLOUDSTACK-5278) Egress Firewall rules clarifications

["Will Stevens (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13840237#comment-13840237 ] 

Will Stevens edited comment on CLOUDSTACK-5278 at 12/5/13 4:31 PM:
-------------------------------------------------------------------

1. Great, I think that is a good solution.  I have developed a work around for this for my plugin and I will be submitting it probably tomorrow, but I think this solution is the best way to handle this.

2. Since the rule is not in the DB, I took the approach of just removing it from the firewall on deletion because I am not sure that is persists in CS once the network is deleted.  If it does, I am not cleaning up that orphaned rule in CS, only on my appliance right now.  Not sure if this is a valid solution, but it appears to work.

One other thing that I have noticed which is not a bug, but is something to consider.  The user has no way to know if they are creating 'allow' or 'deny' rules when they create egress rules because there is no way for the user to know what the default rule is.  Ideally the default rule would be in the database and would show in the UI, but be grayed out and not editable by the user.  This way the user would have a mechanism to know if the rules they add are allow or deny rules...


was (Author: wstevens):
1. Great, I think that is a good solution.  I have developed a work around for this for my plugin and I will be submitting it probably tomorrow, but I think this solution is the best way to handle this.

2. Since the rule is not in the DB, I took the approach of just removing it from the firewall on deletion because I am not sure that is persists in CS once the network is deleted.  If it does, I am not cleaning up that orphaned rule in CS, only on my appliance right now.  Not sure if this is a valid solution, but it appears to work.

On other thing that I have noticed which is not a bug, but is something to consider.  The user has no way to know if they are creating 'allow' or 'deny' rules when they create egress rules because there is no way for the user to know what the default rule is.  Ideally the default rule would be in the database and would show in the UI, but be grayed out and not editable by the user.  This way the user would have a mechanism to know if the rules they add are allow or deny rules...

> 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
>
>
> 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)