[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844103#comment-13844103 ] ASF subversion and git services commented on CLOUDSTACK-5278: - Commit 5c12250deaf1276d74c8ac959c43a507666b05fc in branch refs/heads/master from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5c12250 ] CLOUDSTACK-5278 Fixed cleaning up egress default rules on VR and SRX 1. Egress default policy rules is send to the firewall provider. It is up to the provider to configure the rules. 2. The default policy rules are send for both allow and deny default policy. 3. On network shutdown rules for delete are send. 4. For VR and SRX, by default deny the traffic. So no default rule to deny traffic is required. 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13844111#comment-13844111 ] ASF subversion and git services commented on CLOUDSTACK-5278: - Commit 3caef2b1d50bc44c89811bf61b97cbb2d824d1e6 in branch refs/heads/4.3 from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3caef2b ] CLOUDSTACK-5278 Fixed cleaning up egress default rules on VR and SRX 1. Egress default policy rules is send to the firewall provider. It is up to the provider to configure the rules. 2. The default policy rules are send for both allow and deny default policy. 3. On network shutdown rules for delete are send. 4. For VR and SRX, by default deny the traffic. So no default rule to deny traffic is required. 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839968#comment-13839968 ] Jayapal Reddy commented on CLOUDSTACK-5278: --- We can do the following for egress default rules: 1. While implementing network the default egress rule commands to add for both ALLOW and DENY policy will be send to firewall provider. Also in case of shutdown network send commands to revoke the rule. It is up to the provider to implement add/delete rules for. Ex: in case of VR adding rule for default egress DENY is not needed. So virtual router element returns true. Other providers palo alto will add the rules. 2. The firewallVO/firewall rule for default egress rule can be get from network offering egress_default_policy. 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840237#comment-13840237 ] Will Stevens commented on CLOUDSTACK-5278: -- 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840623#comment-13840623 ] Will Stevens commented on CLOUDSTACK-5278: -- @Jayapal Reddy: I would recommend that we do not attempt to fix this issues in 4.3. I think changing this could cause other providers to potentially break. We can look at this in 4.4. I have been able to work around all of these issues for now, so this is no longer a blocker for me to fully support egress rules in 4.3. I will be submitting a patch to my plugin to fix it tomorrow... 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13839161#comment-13839161 ] Will Stevens commented on CLOUDSTACK-5278: -- I am currently building workarounds for some of these bugs in my provider. How am I supposed to find the default egress firewall rule for my network when I am deleting the network? I can not find functions to get the firewall rules associated with a network. I was considering just calling 'revokeAllFirewallRulesForNetwork' in my provider's resource file, but for some reason this seems wrong. It does not seem right that I have to import a manager into my resource file in order to remove a firewall rule. Also, I think this function will not clean up the default egress rule because of the way it is implemented (ie: its not in the database)... I have not tried that approach yet. What functions should a provider's resource file implement in order to remove the default egress rule? 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13838053#comment-13838053 ] Will Stevens commented on CLOUDSTACK-5278: -- 1. Regarding the default policy with a 'deny' default. - Because all of the devices you have mentioned already have a 'deny' by default policy, this bug does not show up in those implementations. Any device that tries to support the 'deny' by default policy provided by ACS which have allow egress traffic by default at the device level will have problems. This is because the deny rule is not actually created when the network is created, so the device default will be used (which in this case would be 'allow'), so the expected functionality is broken. 2. Not cleaning up system rules. - I still don't like that the cleanup of the system egress rules are not handled by ACS. ACS handles the clean up of all the other types of rules like this. I don't see why each provider should have to implement their own logic to handle the cleanup of these rules. Network restarts and such are bound to complicate things on a per provider basis. 3. The default system egress rules are not in the db. - I think that most of the problems stem from the fact that these rules are not in the DB. - The reason all of the system default rules get the same ID (of 0) is probably because the DB is not being referenced for the next available ID. - The rules would probably get cleaned up correctly if they were in the DB. (point 2) So it is my understanding it that because workarounds for these issues have been implemented for the providers that are currently available, these issues are not considered bugs? Fixing these issues will becoming increasingly difficult as more providers are added and have to build custom logic to handle these issues on a provider by provider basis. If it is expected that the providers should be handling these issues, then there should really be some documentation to describe the additional logic required by the providers to work around these issues. 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836580#comment-13836580 ] Will Stevens commented on CLOUDSTACK-5278: -- Any updates on these bugs? 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)
[jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13836675#comment-13836675 ] Jayapal Reddy commented on CLOUDSTACK-5278: --- 1. In regard default egress policy rules as per my knowledge there is no bug in the router. If you see any issue in functionality please file bug with details. By default router DROP all the egress traffic when default egress policy is deny. Here are the rules when you add first egress rule. Chain FW_EGRESS_RULES (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- * * 10.1.1.0/24 0.0.0.0/0 tcp dpt:22 2. The default egress rule should be cleaned up, In router we may not see issue but other firewall providers it should be cleaned up. 3.The default egress policy rule/system rule is not stored in db. You can list the rules based on the network id. you can use both network id and rule id to configure the rules on the device. 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)
