cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-5278) Egress Firewall rules clarifications
Date Tue, 10 Dec 2013 09:03:07 GMT

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

Mime
View raw message