[
https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13834941#comment-13834941
]
Will Stevens commented on CLOUDSTACK-5278:
------------------------------------------
Thanks for the response...
Quote: "Case: 'deny' :
The global deny rules is not added because for VR and SRX the default egress is
DENY. So extra rule is not required."
If this was true, then it would not add an explicit deny rule ever. The
behavior though is that it does NOT create a 'deny' rule when the network is
created HOWEVER, it DOES add the deny rule when the first user defined egress
rule is added. Why would it add this rule at that point and not add it at
network creation time? Basically, if a device allows egress by default and
someone specifies 'deny' as the default, the configuration on the device is
wrong until a user defines an egress rule. At that point, both the network
wide 'deny' rule which was not created at network creation gets added as well
as the user created 'allow' rule. I still think this is a bug...
Quote: "The clean up of default egress rules is not needed for VR when we
destroy the network.
For other network providers it has to be implemented in the shutdown network of
the Firewall Provider resource base."
This is not the way that Ingress firewall rules work and it is also not the way
that user defined Egress firewall rules work. If there are user defined egress
firewall rules or ingress rules when a network is deleted, CloudStack will
attempt to remove those rules before deleting the network. The provider does
not have to do anything special to handle those cases. Why should system
generated egress rules be handled differently than those other cases?
Quote: "I think the rule ID case is specific to palo alto. Changes can be made
to fix the issue."
I don't think this is a Palo Alto specific case because the 'id' field is
already defined in the rule before the Palo Alto has any control over the rule.
The Palo Alto is only using the 'id' which has been given to the rule. The
fact that two rules in two different networks can have the same ID is a bug
IMO...
Cheers,
Will
> Many Egress Firewall Bugs
> -------------------------
>
> 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)
