[
https://issues.apache.org/jira/browse/CLOUDSTACK-5278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
