Re: POLL: ACL default egress policy rule in VPC
Looks like the winner is 3 for devel. Thanks for the participation. Regards René On 11/13/2017 06:47 PM, Rene Moser wrote: > Hi Devs > > The last days I fought with the ACL egress rule behaviour and I would > like to make a poll in which direction the fix should go. > > Short Version: > > We need to define a better default behaviour for acl default egress > rule. I see 3 different options: > > 1. always add a default deny all egress rule. > > This would be super easy to do (should probably also the intermediate > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323) > > > 2. add a deny all egress rule in case if have at least one egress allow > rule. > > A bit intransparent to the user, but doable. This seems to be the > behaviour how it was designed and should have been implemented. > > > 3. use the default setting in the network offering "egressdefaultpolicy" > to specify the default behavior. > > There is already a setting which specifies this behaviour but is not > used in VPC. Why not use it? > > As a consequence when using this setting, the user should get more infos > about the policy of the network offering while choosing it for the tier. > > > Poll: > > 1. [] > 2. [] > 3. [] > 4. [] Other? What? > > > Long Version: > > First, let's have a look of the issue: > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule > would result in a "accept egress all": > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -j ACCEPT > > When an egress (here deny 25 egress) rule (no mather if deny or allow) > gets added the result is a "deny all" appended: > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP > -A ACL_OUTBOUND_eth2 -j DROP > > This does not make any sense and is a bug IMHO. > > > In 4.9 the behaviour is different: > > (note there is a bug in the ordering of egress rules which is fixed by > https://github.com/apache/cloudstack/pull/2313) > > The default policy is kept accept egress all. > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT > > > To me it looks like the wanted behavior was "egress all as default. If > we have allow rules, append deny all". This would make sense but is > quite instransparent. > > But let's poll > >
Re: POLL: ACL default egress policy rule in VPC
Ok, good enough for me. I vote for option 3 as well then. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Rene Moser" > To: "dev" > Sent: Friday, 17 November, 2017 09:22:24 > Subject: Re: POLL: ACL default egress policy rule in VPC > Hi > > On 11/16/2017 11:14 AM, Nux! wrote: >> 4. I think Jayapal's reply deserves more attention. >> >> See below. >> >> -- >> Sent from the Delta quadrant using Borg technology! >> >> Nux! >> www.nux.ro >> >> - Original Message ----- >>> From: "Jayapal Uradi" >>> To: "dev" >>> Sent: Tuesday, 14 November, 2017 05:12:52 >>> Subject: Re: POLL: ACL default egress policy rule in VPC >> >>> Hi Rene, >>> >>> Please look at my inline comments. >>> Let me add some context for the VPC egress/ingress rules behavior. >>> >>> Pre 4.5 (subject to correction) the behavior of VPC acl is as follows. >>> >>> 1. Default egress is ALLOW and ingress is DROP. >>> a. When a rule is added to egress then that particular rule traffic is >>> allowed >>> and rest is blocked in egress. > > This works as designed in 4.5. > > However, from a user perspective, if we have an "allow all" to egress, a > user would add a drop for a single port, but then anything else is also > blocked. The current implementation does not determine, if the rule > added is allow or blocked. > >>> b. When a rule is added to ingress then that particular rule traffic is >>> allowed >>> and rest is blocked in egress. >>> >>> After 4.5 ACL lists and ACL items feature is introduced there we have >>> ‘default >>> allow’ and ‘default deny’ ACLs. User can also >>> create a custom acl. In ACL feature we can add mix of allow and deny rules >>> and >>> the ordering of rules is maintained. > > "default allow" and "default deny" already exists in 4.5 as well. > >>> 1. when ‘default allow’ is selected while creating the vpc tier >>>By default traffic is ALLOWED and rules can be added to ALLOW/DENY the >>> traffic >>> After adding the rules there will be ACCEPT at the end >>> 2. when ‘default deny’ is selected while creating the vpc tier >>>By default traffic is DENY and rules can be added to DENY/ALLOW the >>> traffic. >>> After adding the rules there will be DROP at the end > > Makes sense, > >>> 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there. >>> 4. With custom acl default ingress is DROP and egress is ALLOW. User can add >>> rules for allow/deny rules. > > This works as designed. H > > owever, the issue I see here is that the behaviour for exising rules > changed. This can potentially lead to a security hole. In 4.5 we had an > implicit "block all egress when one rule", after 4.5 we have no such rule. > > One can arg for or against this "behaviour". The choice should be up to > a cloudstack admin, and it would be best if this can be configured. That > is why using the egressdefaultpolicy makes sense. > >>> >>> If you see behavior other than above then there will be bug. >>> >>> Currently in VPC egress behavior is controlled from the ACLs. If include >>> ‘egressdefaultpolicy’ then there will be confusion. > > I don't see why there should be any confusion at all. If you would like > to keep the behaviour currently in 4.9, you just set > egressdefaultpolicy=true. voila. > >>> What I feel is that current VPC ACLs are flexible enough to configure the >>> required behavior. > > It is flexible but the default has changed. a cloudstack admin should > have the choice. > > René
Re: POLL: ACL default egress policy rule in VPC
Hi On 11/16/2017 11:14 AM, Nux! wrote: > 4. I think Jayapal's reply deserves more attention. > > See below. > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > - Original Message - >> From: "Jayapal Uradi" >> To: "dev" >> Sent: Tuesday, 14 November, 2017 05:12:52 >> Subject: Re: POLL: ACL default egress policy rule in VPC > >> Hi Rene, >> >> Please look at my inline comments. >> Let me add some context for the VPC egress/ingress rules behavior. >> >> Pre 4.5 (subject to correction) the behavior of VPC acl is as follows. >> >> 1. Default egress is ALLOW and ingress is DROP. >> a. When a rule is added to egress then that particular rule traffic is >> allowed >> and rest is blocked in egress. This works as designed in 4.5. However, from a user perspective, if we have an "allow all" to egress, a user would add a drop for a single port, but then anything else is also blocked. The current implementation does not determine, if the rule added is allow or blocked. >> b. When a rule is added to ingress then that particular rule traffic is >> allowed >> and rest is blocked in egress. >> >> After 4.5 ACL lists and ACL items feature is introduced there we have >> ‘default >> allow’ and ‘default deny’ ACLs. User can also >> create a custom acl. In ACL feature we can add mix of allow and deny rules >> and >> the ordering of rules is maintained. "default allow" and "default deny" already exists in 4.5 as well. >> 1. when ‘default allow’ is selected while creating the vpc tier >>By default traffic is ALLOWED and rules can be added to ALLOW/DENY the >> traffic >> After adding the rules there will be ACCEPT at the end >> 2. when ‘default deny’ is selected while creating the vpc tier >>By default traffic is DENY and rules can be added to DENY/ALLOW the >> traffic. >> After adding the rules there will be DROP at the end Makes sense, >> 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there. >> 4. With custom acl default ingress is DROP and egress is ALLOW. User can add >> rules for allow/deny rules. This works as designed. H owever, the issue I see here is that the behaviour for exising rules changed. This can potentially lead to a security hole. In 4.5 we had an implicit "block all egress when one rule", after 4.5 we have no such rule. One can arg for or against this "behaviour". The choice should be up to a cloudstack admin, and it would be best if this can be configured. That is why using the egressdefaultpolicy makes sense. >> >> If you see behavior other than above then there will be bug. >> >> Currently in VPC egress behavior is controlled from the ACLs. If include >> ‘egressdefaultpolicy’ then there will be confusion. I don't see why there should be any confusion at all. If you would like to keep the behaviour currently in 4.9, you just set egressdefaultpolicy=true. voila. >> What I feel is that current VPC ACLs are flexible enough to configure the >> required behavior. It is flexible but the default has changed. a cloudstack admin should have the choice. René
Re: POLL: ACL default egress policy rule in VPC
4. I think Jayapal's reply deserves more attention. See below. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Jayapal Uradi" > To: "dev" > Sent: Tuesday, 14 November, 2017 05:12:52 > Subject: Re: POLL: ACL default egress policy rule in VPC > Hi Rene, > > Please look at my inline comments. > Let me add some context for the VPC egress/ingress rules behavior. > > Pre 4.5 (subject to correction) the behavior of VPC acl is as follows. > > 1. Default egress is ALLOW and ingress is DROP. > a. When a rule is added to egress then that particular rule traffic is > allowed > and rest is blocked in egress. > b. When a rule is added to ingress then that particular rule traffic is > allowed > and rest is blocked in egress. > > After 4.5 ACL lists and ACL items feature is introduced there we have ‘default > allow’ and ‘default deny’ ACLs. User can also > create a custom acl. In ACL feature we can add mix of allow and deny rules and > the ordering of rules is maintained. > > 1. when ‘default allow’ is selected while creating the vpc tier >By default traffic is ALLOWED and rules can be added to ALLOW/DENY the > traffic > After adding the rules there will be ACCEPT at the end > 2. when ‘default deny’ is selected while creating the vpc tier >By default traffic is DENY and rules can be added to DENY/ALLOW the > traffic. > After adding the rules there will be DROP at the end > 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there. > 4. With custom acl default ingress is DROP and egress is ALLOW. User can add > rules for allow/deny rules. > > If you see behavior other than above then there will be bug. > > Currently in VPC egress behavior is controlled from the ACLs. If include > ‘egressdefaultpolicy’ then there will be confusion. > > What I feel is that current VPC ACLs are flexible enough to configure the > required behavior. > > Thanks, > Jayapal > > > > > >> On Nov 13, 2017, at 11:17 PM, Rene Moser wrote: >> >> Hi Devs >> >> The last days I fought with the ACL egress rule behaviour and I would >> like to make a poll in which direction the fix should go. >> >> Short Version: >> >> We need to define a better default behaviour for acl default egress >> rule. I see 3 different options: >> >> 1. always add a default deny all egress rule. >> >> This would be super easy to do (should probably also the intermediate >> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323) >> >> >> 2. add a deny all egress rule in case if have at least one egress allow >> rule. >> >> A bit intransparent to the user, but doable. This seems to be the >> behaviour how it was designed and should have been implemented. >> > Currently we can configure the ACLs to get this behavior. >> >> 3. use the default setting in the network offering "egressdefaultpolicy" >> to specify the default behavior. >> >> There is already a setting which specifies this behaviour but is not >> used in VPC. Why not use it? >> >> As a consequence when using this setting, the user should get more infos >> about the policy of the network offering while choosing it for the tier. >> >> >> Poll: >> >> 1. [] >> 2. [] >> 3. [] >> 4. [] Other? What? >> >> >> Long Version: >> >> First, let's have a look of the issue: >> >> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule >> would result in a "accept egress all": >> >> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state >> NEW -j ACL_OUTBOUND_eth2 >> -A ACL_OUTBOUND_eth2 -j ACCEPT >> >> When an egress (here deny 25 egress) rule (no mather if deny or allow) >> gets added the result is a "deny all" appended: >> >> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state >> NEW -j ACL_OUTBOUND_eth2 >> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP >> -A ACL_OUTBOUND_eth2 -j DROP > This is seen because default egress is drop and user added rule to deny port > 25 > traffic. > User has choice of adding allow/deny rules with priority number. >> >> This does not make any sense and is a bug IMHO. >> >> >> In 4.9 the behaviour is different: >> >> (note there is a bug in the ordering of egress rules which is fixed by >> https://github.com/apache/cloudstack/pull/2313) >> >>
RE: POLL: ACL default egress policy rule in VPC
Option 3, makes sense to me. -Rohit From: Paul Angus Sent: Tuesday, November 14, 2017 4:08:51 PM To: dev@cloudstack.apache.org Cc: u...@cloudstack.apache.org Subject: RE: POLL: ACL default egress policy rule in VPC 3 sounds like a winner. [I think that (2) is how non-vpc networks work, I guess the thinking was, that if you are adding allow rules, then you want to deny everything else. But if you didn't care (ie didn't add egress rules) then allow all outbound was ok] Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com<http://www.shapeblue.com> 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue rohit.ya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Simon Weller [mailto:swel...@ena.com.INVALID] Sent: 13 November 2017 20:14 To: dev@cloudstack.apache.org Cc: u...@cloudstack.apache.org Subject: Re: POLL: ACL default egress policy rule in VPC 3 definitely seems to make the most sense. From: Rafael Weingärtner Sent: Monday, November 13, 2017 12:02 PM To: dev@cloudstack.apache.org Cc: u...@cloudstack.apache.org Subject: Re: POLL: ACL default egress policy rule in VPC 3 On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland wrote: > 3 of course ;) > > On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser wrote: > > > Hi Devs > > > > The last days I fought with the ACL egress rule behaviour and I > > would like to make a poll in which direction the fix should go. > > > > Short Version: > > > > We need to define a better default behaviour for acl default egress > > rule. I see 3 different options: > > > > 1. always add a default deny all egress rule. > > > > This would be super easy to do (should probably also the > > intermediate fix for 4.9, see > > https://github.com/apache/cloudstack/pull/2323) > > > > > > 2. add a deny all egress rule in case if have at least one egress > > allow rule. > > > > A bit intransparent to the user, but doable. This seems to be the > > behaviour how it was designed and should have been implemented. > > > > > > 3. use the default setting in the network offering "egressdefaultpolicy" > > to specify the default behavior. > > > > There is already a setting which specifies this behaviour but is not > > used in VPC. Why not use it? > > > > As a consequence when using this setting, the user should get more > > infos about the policy of the network offering while choosing it for the > > tier. > > > > > > Poll: > > > > 1. [] > > 2. [] > > 3. [] > > 4. [] Other? What? > > > > > > Long Version: > > > > First, let's have a look of the issue: > > > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) > > rule would result in a "accept egress all": > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state > > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -j ACCEPT > > > > When an egress (here deny 25 egress) rule (no mather if deny or > > allow) gets added the result is a "deny all" appended: > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state > > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -p tcp -m tcp > > --dport 25 -j DROP -A ACL_OUTBOUND_eth2 -j DROP > > > > This does not make any sense and is a bug IMHO. > > > > > > In 4.9 the behaviour is different: > > > > (note there is a bug in the ordering of egress rules which is fixed > > by > > https://github.com/apache/cloudstack/pull/2313) > > > > The default policy is kept accept egress all. > > > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state > > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -d > > 224.0.0.18/32 -j ACCEPT -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j > > ACCEPT -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT > > > > > > To me it looks like the wanted behavior was "egress all as default. > > If we have allow rules, append deny all". This would make sense but > > is quite instransparent. > > > > But let's poll > > > > > > > > > -- > Daan > -- Rafael Weingärtner
RE: POLL: ACL default egress policy rule in VPC
3 sounds like a winner. [I think that (2) is how non-vpc networks work, I guess the thinking was, that if you are adding allow rules, then you want to deny everything else. But if you didn't care (ie didn't add egress rules) then allow all outbound was ok] Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Simon Weller [mailto:swel...@ena.com.INVALID] Sent: 13 November 2017 20:14 To: dev@cloudstack.apache.org Cc: u...@cloudstack.apache.org Subject: Re: POLL: ACL default egress policy rule in VPC 3 definitely seems to make the most sense. From: Rafael Weingärtner Sent: Monday, November 13, 2017 12:02 PM To: dev@cloudstack.apache.org Cc: u...@cloudstack.apache.org Subject: Re: POLL: ACL default egress policy rule in VPC 3 On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland wrote: > 3 of course ;) > > On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser wrote: > > > Hi Devs > > > > The last days I fought with the ACL egress rule behaviour and I > > would like to make a poll in which direction the fix should go. > > > > Short Version: > > > > We need to define a better default behaviour for acl default egress > > rule. I see 3 different options: > > > > 1. always add a default deny all egress rule. > > > > This would be super easy to do (should probably also the > > intermediate fix for 4.9, see > > https://github.com/apache/cloudstack/pull/2323) > > > > > > 2. add a deny all egress rule in case if have at least one egress > > allow rule. > > > > A bit intransparent to the user, but doable. This seems to be the > > behaviour how it was designed and should have been implemented. > > > > > > 3. use the default setting in the network offering "egressdefaultpolicy" > > to specify the default behavior. > > > > There is already a setting which specifies this behaviour but is not > > used in VPC. Why not use it? > > > > As a consequence when using this setting, the user should get more > > infos about the policy of the network offering while choosing it for the > > tier. > > > > > > Poll: > > > > 1. [] > > 2. [] > > 3. [] > > 4. [] Other? What? > > > > > > Long Version: > > > > First, let's have a look of the issue: > > > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) > > rule would result in a "accept egress all": > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state > > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -j ACCEPT > > > > When an egress (here deny 25 egress) rule (no mather if deny or > > allow) gets added the result is a "deny all" appended: > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state > > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -p tcp -m tcp > > --dport 25 -j DROP -A ACL_OUTBOUND_eth2 -j DROP > > > > This does not make any sense and is a bug IMHO. > > > > > > In 4.9 the behaviour is different: > > > > (note there is a bug in the ordering of egress rules which is fixed > > by > > https://github.com/apache/cloudstack/pull/2313) > > > > The default policy is kept accept egress all. > > > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state > > --state NEW -j ACL_OUTBOUND_eth2 -A ACL_OUTBOUND_eth2 -d > > 224.0.0.18/32 -j ACCEPT -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j > > ACCEPT -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT > > > > > > To me it looks like the wanted behavior was "egress all as default. > > If we have allow rules, append deny all". This would make sense but > > is quite instransparent. > > > > But let's poll > > > > > > > > > -- > Daan > -- Rafael Weingärtner
Re: POLL: ACL default egress policy rule in VPC
Hi Rene, Please look at my inline comments. Let me add some context for the VPC egress/ingress rules behavior. Pre 4.5 (subject to correction) the behavior of VPC acl is as follows. 1. Default egress is ALLOW and ingress is DROP. a. When a rule is added to egress then that particular rule traffic is allowed and rest is blocked in egress. b. When a rule is added to ingress then that particular rule traffic is allowed and rest is blocked in egress. After 4.5 ACL lists and ACL items feature is introduced there we have ‘default allow’ and ‘default deny’ ACLs. User can also create a custom acl. In ACL feature we can add mix of allow and deny rules and the ordering of rules is maintained. 1. when ‘default allow’ is selected while creating the vpc tier By default traffic is ALLOWED and rules can be added to ALLOW/DENY the traffic After adding the rules there will be ACCEPT at the end 2. when ‘default deny’ is selected while creating the vpc tier By default traffic is DENY and rules can be added to DENY/ALLOW the traffic. After adding the rules there will be DROP at the end 3. If no ACL selected for the ACL then Pre 4.5 behavior will be there. 4. With custom acl default ingress is DROP and egress is ALLOW. User can add rules for allow/deny rules. If you see behavior other than above then there will be bug. Currently in VPC egress behavior is controlled from the ACLs. If include ‘egressdefaultpolicy’ then there will be confusion. What I feel is that current VPC ACLs are flexible enough to configure the required behavior. Thanks, Jayapal > On Nov 13, 2017, at 11:17 PM, Rene Moser wrote: > > Hi Devs > > The last days I fought with the ACL egress rule behaviour and I would > like to make a poll in which direction the fix should go. > > Short Version: > > We need to define a better default behaviour for acl default egress > rule. I see 3 different options: > > 1. always add a default deny all egress rule. > > This would be super easy to do (should probably also the intermediate > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323) > > > 2. add a deny all egress rule in case if have at least one egress allow > rule. > > A bit intransparent to the user, but doable. This seems to be the > behaviour how it was designed and should have been implemented. > Currently we can configure the ACLs to get this behavior. > > 3. use the default setting in the network offering "egressdefaultpolicy" > to specify the default behavior. > > There is already a setting which specifies this behaviour but is not > used in VPC. Why not use it? > > As a consequence when using this setting, the user should get more infos > about the policy of the network offering while choosing it for the tier. > > > Poll: > > 1. [] > 2. [] > 3. [] > 4. [] Other? What? > > > Long Version: > > First, let's have a look of the issue: > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule > would result in a "accept egress all": > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -j ACCEPT > > When an egress (here deny 25 egress) rule (no mather if deny or allow) > gets added the result is a "deny all" appended: > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP > -A ACL_OUTBOUND_eth2 -j DROP This is seen because default egress is drop and user added rule to deny port 25 traffic. User has choice of adding allow/deny rules with priority number. > > This does not make any sense and is a bug IMHO. > > > In 4.9 the behaviour is different: > > (note there is a bug in the ordering of egress rules which is fixed by > https://github.com/apache/cloudstack/pull/2313) > > The default policy is kept accept egress all. > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT In 4.9 it is a bug. After accept rules there supposed to DROP all at the end. > > > To me it looks like the wanted behavior was "egress all as default. If > we have allow rules, append deny all". This would make sense but is > quite instransparent. > > But let's poll > > DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any l
Re: POLL: ACL default egress policy rule in VPC
I agree with (3). To achieve backward compatibility, we need to add an egress rule to allow ALL on existing ACLs which do not contain any egress rule. For now almost every one uses integrated network offerings for VPC networks: DefaultIsolatedNetworkOfferingForVpcNetworks DefaultIsolatedNetworkOfferingForVpcNetworksNoLB DefaultIsolatedNetworkOfferingForVpcNetworksWithInternalLB The default egress policy are "Deny" in all network offerings above. -Wei 2017-11-13 18:47 GMT+01:00 Rene Moser : > Hi Devs > > The last days I fought with the ACL egress rule behaviour and I would > like to make a poll in which direction the fix should go. > > Short Version: > > We need to define a better default behaviour for acl default egress > rule. I see 3 different options: > > 1. always add a default deny all egress rule. > > This would be super easy to do (should probably also the intermediate > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323) > > > 2. add a deny all egress rule in case if have at least one egress allow > rule. > > A bit intransparent to the user, but doable. This seems to be the > behaviour how it was designed and should have been implemented. > > > 3. use the default setting in the network offering "egressdefaultpolicy" > to specify the default behavior. > > There is already a setting which specifies this behaviour but is not > used in VPC. Why not use it? > > As a consequence when using this setting, the user should get more infos > about the policy of the network offering while choosing it for the tier. > > > Poll: > > 1. [] > 2. [] > 3. [] > 4. [] Other? What? > > > Long Version: > > First, let's have a look of the issue: > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule > would result in a "accept egress all": > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -j ACCEPT > > When an egress (here deny 25 egress) rule (no mather if deny or allow) > gets added the result is a "deny all" appended: > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP > -A ACL_OUTBOUND_eth2 -j DROP > > This does not make any sense and is a bug IMHO. > > > In 4.9 the behaviour is different: > > (note there is a bug in the ordering of egress rules which is fixed by > https://github.com/apache/cloudstack/pull/2313) > > The default policy is kept accept egress all. > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT > > > To me it looks like the wanted behavior was "egress all as default. If > we have allow rules, append deny all". This would make sense but is > quite instransparent. > > But let's poll > > >
Re: POLL: ACL default egress policy rule in VPC
3 definitely seems to make the most sense. From: Rafael Weingärtner Sent: Monday, November 13, 2017 12:02 PM To: dev@cloudstack.apache.org Cc: u...@cloudstack.apache.org Subject: Re: POLL: ACL default egress policy rule in VPC 3 On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland wrote: > 3 of course ;) > > On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser wrote: > > > Hi Devs > > > > The last days I fought with the ACL egress rule behaviour and I would > > like to make a poll in which direction the fix should go. > > > > Short Version: > > > > We need to define a better default behaviour for acl default egress > > rule. I see 3 different options: > > > > 1. always add a default deny all egress rule. > > > > This would be super easy to do (should probably also the intermediate > > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323) > > > > > > 2. add a deny all egress rule in case if have at least one egress allow > > rule. > > > > A bit intransparent to the user, but doable. This seems to be the > > behaviour how it was designed and should have been implemented. > > > > > > 3. use the default setting in the network offering "egressdefaultpolicy" > > to specify the default behavior. > > > > There is already a setting which specifies this behaviour but is not > > used in VPC. Why not use it? > > > > As a consequence when using this setting, the user should get more infos > > about the policy of the network offering while choosing it for the tier. > > > > > > Poll: > > > > 1. [] > > 2. [] > > 3. [] > > 4. [] Other? What? > > > > > > Long Version: > > > > First, let's have a look of the issue: > > > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule > > would result in a "accept egress all": > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > > NEW -j ACL_OUTBOUND_eth2 > > -A ACL_OUTBOUND_eth2 -j ACCEPT > > > > When an egress (here deny 25 egress) rule (no mather if deny or allow) > > gets added the result is a "deny all" appended: > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > > NEW -j ACL_OUTBOUND_eth2 > > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP > > -A ACL_OUTBOUND_eth2 -j DROP > > > > This does not make any sense and is a bug IMHO. > > > > > > In 4.9 the behaviour is different: > > > > (note there is a bug in the ordering of egress rules which is fixed by > > https://github.com/apache/cloudstack/pull/2313) > > > > The default policy is kept accept egress all. > > > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state > > NEW -j ACL_OUTBOUND_eth2 > > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT > > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT > > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT > > > > > > To me it looks like the wanted behavior was "egress all as default. If > > we have allow rules, append deny all". This would make sense but is > > quite instransparent. > > > > But let's poll > > > > > > > > > -- > Daan > -- Rafael Weingärtner
Re: POLL: ACL default egress policy rule in VPC
3 On Mon, Nov 13, 2017 at 3:51 PM, Daan Hoogland wrote: > 3 of course ;) > > On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser wrote: > > > Hi Devs > > > > The last days I fought with the ACL egress rule behaviour and I would > > like to make a poll in which direction the fix should go. > > > > Short Version: > > > > We need to define a better default behaviour for acl default egress > > rule. I see 3 different options: > > > > 1. always add a default deny all egress rule. > > > > This would be super easy to do (should probably also the intermediate > > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323) > > > > > > 2. add a deny all egress rule in case if have at least one egress allow > > rule. > > > > A bit intransparent to the user, but doable. This seems to be the > > behaviour how it was designed and should have been implemented. > > > > > > 3. use the default setting in the network offering "egressdefaultpolicy" > > to specify the default behavior. > > > > There is already a setting which specifies this behaviour but is not > > used in VPC. Why not use it? > > > > As a consequence when using this setting, the user should get more infos > > about the policy of the network offering while choosing it for the tier. > > > > > > Poll: > > > > 1. [] > > 2. [] > > 3. [] > > 4. [] Other? What? > > > > > > Long Version: > > > > First, let's have a look of the issue: > > > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule > > would result in a "accept egress all": > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > > NEW -j ACL_OUTBOUND_eth2 > > -A ACL_OUTBOUND_eth2 -j ACCEPT > > > > When an egress (here deny 25 egress) rule (no mather if deny or allow) > > gets added the result is a "deny all" appended: > > > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > > NEW -j ACL_OUTBOUND_eth2 > > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP > > -A ACL_OUTBOUND_eth2 -j DROP > > > > This does not make any sense and is a bug IMHO. > > > > > > In 4.9 the behaviour is different: > > > > (note there is a bug in the ordering of egress rules which is fixed by > > https://github.com/apache/cloudstack/pull/2313) > > > > The default policy is kept accept egress all. > > > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state > > NEW -j ACL_OUTBOUND_eth2 > > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT > > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT > > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT > > > > > > To me it looks like the wanted behavior was "egress all as default. If > > we have allow rules, append deny all". This would make sense but is > > quite instransparent. > > > > But let's poll > > > > > > > > > -- > Daan > -- Rafael Weingärtner
Re: POLL: ACL default egress policy rule in VPC
Note the typo in the user mailing list email address, don't use reply all... sry
Re: POLL: ACL default egress policy rule in VPC
3 of course ;) On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser wrote: > Hi Devs > > The last days I fought with the ACL egress rule behaviour and I would > like to make a poll in which direction the fix should go. > > Short Version: > > We need to define a better default behaviour for acl default egress > rule. I see 3 different options: > > 1. always add a default deny all egress rule. > > This would be super easy to do (should probably also the intermediate > fix for 4.9, see https://github.com/apache/cloudstack/pull/2323) > > > 2. add a deny all egress rule in case if have at least one egress allow > rule. > > A bit intransparent to the user, but doable. This seems to be the > behaviour how it was designed and should have been implemented. > > > 3. use the default setting in the network offering "egressdefaultpolicy" > to specify the default behavior. > > There is already a setting which specifies this behaviour but is not > used in VPC. Why not use it? > > As a consequence when using this setting, the user should get more infos > about the policy of the network offering while choosing it for the tier. > > > Poll: > > 1. [] > 2. [] > 3. [] > 4. [] Other? What? > > > Long Version: > > First, let's have a look of the issue: > > In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule > would result in a "accept egress all": > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -j ACCEPT > > When an egress (here deny 25 egress) rule (no mather if deny or allow) > gets added the result is a "deny all" appended: > > -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP > -A ACL_OUTBOUND_eth2 -j DROP > > This does not make any sense and is a bug IMHO. > > > In 4.9 the behaviour is different: > > (note there is a bug in the ordering of egress rules which is fixed by > https://github.com/apache/cloudstack/pull/2313) > > The default policy is kept accept egress all. > > -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state > NEW -j ACL_OUTBOUND_eth2 > -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT > -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT > > > To me it looks like the wanted behavior was "egress all as default. If > we have allow rules, append deny all". This would make sense but is > quite instransparent. > > But let's poll > > > -- Daan
