Re: egress fw problems in 4.10?

[Nux!]

Thanks Jayapal,

Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually I 
got an error:
ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid


Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 though, 
however I still can't do any egress except for ICMP ping for some reason.

If I omit specifying a a dest CIDR, then I get trully unrestricted egress.

I need to investigate some more when I get time, something's fishy.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Jayapal Uradi" 
> To: "dev" 
> Sent: Friday, 17 November, 2017 04:02:13
> Subject: Re: egress fw problems in 4.10?

> Hi Nux,
> 
> I think the the ipset for destination cidr is not configured with 0.0.0.0/0 
> due
> this you might see this issue.
> Please check the ipset and iptables rules once.
> 
> iptables -L -nv
> ipset -L
> 
> Thanks,
> Jayapal
> 
> 
>> On Nov 17, 2017, a t 6:55 AM, Nux!  wrote:
>> 
>> Hi,
>> 
>> Just installed 4.10 today for a demo, but seems there are some problems with 
>> the
>> egress rules in isolated networks.
>> Is there anything wrong with this rule? ACS allows me to add it, but no 
>> outbound
>> traffic is allowed at all.
>> 
>> 10.1.1.0/24  0.0.0.0/0   All All All
>> 
>> http://img.nux.ro/gL3-Selection_002.png
>> 
>> If I replace 0.0.0.0/0 with a certain IP/32, then traffic works.
>> 
>> 
>> Also, if I don't mention a destination cidr at all, outbound traffic also 
>> works,
>> but the docs state 0.0.0.0/0 should be honoured as valid destination cidr.
>> 
>> Any ideas? I know there was recent work done on egress recently, maybe 
>> related
>> to that?
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
> 
> 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 liability for
> virus infected mails.

Re: HTTPS LB and x-forwarded-for

[Nux!]

lol good find..

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Pierre-Luc Dion" 
> To: "Wido den Hollander" 
> Cc: "dev" , "users" 
> Sent: Friday, 17 November, 2017 13:56:11
> Subject: Re: HTTPS LB and x-forwarded-for

> That's funny!
> 
> Cloudstack ui does not provide lb protocol options, but the api does and
> cloudstack already support proxy proto v1!!!
> 
> So that's cool!
> 
> Le 13 nov. 2017 09 h 18, "Wido den Hollander"  a écrit :
> 
>>
>> > Op 13 november 2017 om 15:14 schreef Pierre-Luc Dion > >:
>> >
>> >
>> > Hi,
>> >
>> > This is looking quite promising, I have a colleague that tested that last
>> > Friday, look like the proxy proto v1 work out of the box with Nginx, but
>> > would need an extra package for Apache 2.4 ?
>>
>> It depends. You need HTTPd 2.4.28, see: https://httpd.apache.org/docs/
>> trunk/mod/mod_remoteip.html#remoteipproxyprotocol
>>
>> It's there upstream, but not in all packages.
>>
>> It can from this module:
>>
>> - https://github.com/roadrunner2/mod-proxy-protocol
>> - https://roadrunner2.github.io/mod-proxy-protocol/mod_proxy_protocol.html
>>
>> They donated the code to go upstream and went into mod_remoteip but landed
>> in 2.4.28
>>
>> It will probably make it into Ubuntu 18.04 and CentOS 7.4.
>>
>> Wido
>>
>> > Otherwise, it seems to be a good way to do  https LB without complicated
>> > configuration and huge changes in CloudStack.
>> >
>> >
>> >
>> > On Fri, Nov 10, 2017 at 10:36 AM, Nux!  wrote:
>> >
>> > > Pierre-Luc,
>> > >
>> > > Haproxy docs say it should work for any kind of traffic as long as both
>> > > ends are PROXY-aware and it look like a majority of software is.
>> > > So, in short, yes.
>> > >
>> > > --
>> > > Sent from the Delta quadrant using Borg technology!
>> > >
>> > > Nux!
>> > > www.nux.ro
>> > >
>> > > - Original Message -
>> > > > From: "Pierre-Luc Dion" 
>> > > > To: "Wido den Hollander" 
>> > > > Cc: "dev" , "Khosrow Moossavi" <
>> > > kmooss...@cloudops.com>, "Will Stevens"
>> > > > , "Nux!" , "users" <
>> > > us...@cloudstack.apache.org>
>> > > > Sent: Friday, 10 November, 2017 15:32:38
>> > > > Subject: Re: HTTPS LB and x-forwarded-for
>> > >
>> > > > Hi Wido, do you know if this would work for https traffic too?
>> > > >
>> > > > Le 10 nov. 2017 09 h 35, "Wido den Hollander"  a
>> écrit :
>> > > >
>> > > >>
>> > > >> > Op 10 november 2017 om 14:27 schreef Pierre-Luc Dion <
>> > > pd...@cloudops.com
>> > > >> >:
>> > > >> >
>> > > >> >
>> > > >> > I kind of like the proxy backend type, ill check on our end if
>> that
>> > > would
>> > > >> > work but definitely a simple and efficient approach!
>> > > >> >
>> > > >>
>> > > >> See: https://www.haproxy.com/blog/haproxy/proxy-protocol/
>> > > >>
>> > > >> Apache HTTPd supports PROXY since 2.4.28:
>> > > https://httpd.apache.org/docs/
>> > > >> trunk/mod/mod_remoteip.html#remoteipproxyprotocol
>> > > >>
>> > > >> "RemoteIPProxyProtocol is only available in httpd 2.4.28 and newer"
>> > > >>
>> > > >> Wido
>> > > >>
>> > > >> >
>> > > >> >
>> > > >> > Le 10 nov. 2017 01 h 44, "Wido den Hollander"  a
>> > > écrit :
>> > > >> >
>> > > >> > >
>> > > >> > > > Op 9 november 2017 om 19:59 schreef Nux! :
>> > > >> > > >
>> > > >> > > >
>> > > >> > > > Wido,
>> > > >> > > >
>> > > >> > > > Excellent suggestion with the "transparent proxy", I was not
>> > > aware of
>> > > >> > > that.
>> > > >> > > > I think that would be a great idea and wouldn't require too
>> many
>> > > >> > > modifications, especially as Haproxy comes already with the VR.
>> > > >> > > >
>> > > >> > >
>> > > >> > > It's indeed just a matter of a HAProxy config setting. We could
>> > > make it
>> > > >> > > configurable per backend in HAProxy. Regular HTTP, TCP or PROXY
>> for
>> > > >> example.
>> > > >> > >
>> > > >> > > That way your problem would be solved.
>> > > >> > >
>> > > >> > > Wido
>> > > >> > >
>> > > >> > > > To Paul:
>> > > >> > > > - imho the LB solution ACS ships now is a bit handicaped since
>> > > you do
>> > > >> > > not know the remote host ip. You're flying blind unless you use
>> > > google
>> > > >> > > analytics (and these things have gotten more and more
>> aggressively
>> > > >> filtered
>> > > >> > > by adblocks).
>> > > >> > > > Enhancing Haproxy as Wido suggested would go a long way, it
>> > > wouldn't
>> > > >> > > break existing functionality and would also keep SSL processing
>> off
>> > > >> the VR.
>> > > >> > > >
>> > > >> > > > --
>> > > >> > > > Sent from the Delta quadrant using Borg technology!
>> > > >> > > >
>> > > >> > > > Nux!
>> > > >> > > > www.nux.ro
>> > > >> > > >
>> > > >> > > > - Original Message -
>> > > 

Re: POLL: ACL default egress policy rule in VPC

[Nux!]

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: [FS] Request for comments: Secure VM Live Migration for KVM

[Marc-Aurèle Brothier - Exoscale]

Working, thanks!


On Fri, 2017-11-17 at 11:27 -0200, Rafael Weingärtner wrote:
> Marc I added permission to you; can you test if you can make comments
> now?
> 
> On Fri, Nov 17, 2017 at 11:20 AM, Marc-Aurèle Brothier - Exoscale <
> ma...@exoscale.ch> wrote:
> 
> > I'm not able to post comments on the wiki even when logged in so I
> > post
> > to the mailing list. I guess I'm not in any special wiki group to
> > edit
> > CS pages.
> > 
> > Good news you made the live migration working (right?) on master.
> > Is it
> > really something we want to control under CS on the agent
> > installation
> > all this libvirt TLS setup? Maybe the installation could write
> > libvirtd
> > configuration file for TLS and non-TLS setup in CS and/or libvirt
> > /etc
> > directory but without overriding the normal one. I have to admit
> > I'm
> > not familiar with how things are usually done in CS for external
> > components.
> > 
> > You can also add to cloudstack configuration the libvirt flags used
> > for
> > the live migration, which should be customizable in some way. On my
> > PR
> > it's in agent.properties, but it could be sent along with the
> > migration
> > command.
> > 
> > I would welcome if you could setup a wiki page that I could edit on
> > the
> > KVM live migration so I could add my remark on my experience and
> > things
> > to config/consider.
> > 
> > On your question: +1 on having the configuration value for TLS or
> > plain
> > tcp.
> > 
> > Marc-Aurèle
> > 
> > On Thu, 2017-11-16 at 10:32 +, Rohit Yadav wrote:
> > > All,
> > > 
> > > 
> > > Kindly review and share your thoughts and comments for a new
> > > feature
> > > - Secure VM live migration for KVM, this feature builds on top of
> > > the
> > > previous feature that brought in a new CA framework [1] for
> > > CloudStack.
> > > 
> > > 
> > > Here is a rough first draft for your review:
> > > 
> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+KVM
> > > +VM+
> > > Live+Migration
> > > 
> > > 
> > > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure
> > > +Age
> > > nt+Communications
> > > 
> > > 
> > > Regards.
> > > 
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > > 
> > > 
> > > 
> 
> 
> 

Re: HTTPS LB and x-forwarded-for

[Pierre-Luc Dion]

That's funny!

Cloudstack ui does not provide lb protocol options, but the api does and
cloudstack already support proxy proto v1!!!

So that's cool!

Le 13 nov. 2017 09 h 18, "Wido den Hollander"  a écrit :

>
> > Op 13 november 2017 om 15:14 schreef Pierre-Luc Dion  >:
> >
> >
> > Hi,
> >
> > This is looking quite promising, I have a colleague that tested that last
> > Friday, look like the proxy proto v1 work out of the box with Nginx, but
> > would need an extra package for Apache 2.4 ?
>
> It depends. You need HTTPd 2.4.28, see: https://httpd.apache.org/docs/
> trunk/mod/mod_remoteip.html#remoteipproxyprotocol
>
> It's there upstream, but not in all packages.
>
> It can from this module:
>
> - https://github.com/roadrunner2/mod-proxy-protocol
> - https://roadrunner2.github.io/mod-proxy-protocol/mod_proxy_protocol.html
>
> They donated the code to go upstream and went into mod_remoteip but landed
> in 2.4.28
>
> It will probably make it into Ubuntu 18.04 and CentOS 7.4.
>
> Wido
>
> > Otherwise, it seems to be a good way to do  https LB without complicated
> > configuration and huge changes in CloudStack.
> >
> >
> >
> > On Fri, Nov 10, 2017 at 10:36 AM, Nux!  wrote:
> >
> > > Pierre-Luc,
> > >
> > > Haproxy docs say it should work for any kind of traffic as long as both
> > > ends are PROXY-aware and it look like a majority of software is.
> > > So, in short, yes.
> > >
> > > --
> > > Sent from the Delta quadrant using Borg technology!
> > >
> > > Nux!
> > > www.nux.ro
> > >
> > > - Original Message -
> > > > From: "Pierre-Luc Dion" 
> > > > To: "Wido den Hollander" 
> > > > Cc: "dev" , "Khosrow Moossavi" <
> > > kmooss...@cloudops.com>, "Will Stevens"
> > > > , "Nux!" , "users" <
> > > us...@cloudstack.apache.org>
> > > > Sent: Friday, 10 November, 2017 15:32:38
> > > > Subject: Re: HTTPS LB and x-forwarded-for
> > >
> > > > Hi Wido, do you know if this would work for https traffic too?
> > > >
> > > > Le 10 nov. 2017 09 h 35, "Wido den Hollander"  a
> écrit :
> > > >
> > > >>
> > > >> > Op 10 november 2017 om 14:27 schreef Pierre-Luc Dion <
> > > pd...@cloudops.com
> > > >> >:
> > > >> >
> > > >> >
> > > >> > I kind of like the proxy backend type, ill check on our end if
> that
> > > would
> > > >> > work but definitely a simple and efficient approach!
> > > >> >
> > > >>
> > > >> See: https://www.haproxy.com/blog/haproxy/proxy-protocol/
> > > >>
> > > >> Apache HTTPd supports PROXY since 2.4.28:
> > > https://httpd.apache.org/docs/
> > > >> trunk/mod/mod_remoteip.html#remoteipproxyprotocol
> > > >>
> > > >> "RemoteIPProxyProtocol is only available in httpd 2.4.28 and newer"
> > > >>
> > > >> Wido
> > > >>
> > > >> >
> > > >> >
> > > >> > Le 10 nov. 2017 01 h 44, "Wido den Hollander"  a
> > > écrit :
> > > >> >
> > > >> > >
> > > >> > > > Op 9 november 2017 om 19:59 schreef Nux! :
> > > >> > > >
> > > >> > > >
> > > >> > > > Wido,
> > > >> > > >
> > > >> > > > Excellent suggestion with the "transparent proxy", I was not
> > > aware of
> > > >> > > that.
> > > >> > > > I think that would be a great idea and wouldn't require too
> many
> > > >> > > modifications, especially as Haproxy comes already with the VR.
> > > >> > > >
> > > >> > >
> > > >> > > It's indeed just a matter of a HAProxy config setting. We could
> > > make it
> > > >> > > configurable per backend in HAProxy. Regular HTTP, TCP or PROXY
> for
> > > >> example.
> > > >> > >
> > > >> > > That way your problem would be solved.
> > > >> > >
> > > >> > > Wido
> > > >> > >
> > > >> > > > To Paul:
> > > >> > > > - imho the LB solution ACS ships now is a bit handicaped since
> > > you do
> > > >> > > not know the remote host ip. You're flying blind unless you use
> > > google
> > > >> > > analytics (and these things have gotten more and more
> aggressively
> > > >> filtered
> > > >> > > by adblocks).
> > > >> > > > Enhancing Haproxy as Wido suggested would go a long way, it
> > > wouldn't
> > > >> > > break existing functionality and would also keep SSL processing
> off
> > > >> the VR.
> > > >> > > >
> > > >> > > > --
> > > >> > > > Sent from the Delta quadrant using Borg technology!
> > > >> > > >
> > > >> > > > Nux!
> > > >> > > > www.nux.ro
> > > >> > > >
> > > >> > > > - Original Message -
> > > >> > > > > From: "Andrija Panic" 
> > > >> > > > > To: "users" 
> > > >> > > > > Cc: "Khosrow Moossavi" , "Will
> > > Stevens" <
> > > >> > > wstev...@cloudops.com>, "dev"
> > > >> > > > > , "Pierre-Luc Dion" <
> > > pd...@cloudops.com
> > > >> >
> > > >> > > > > Sent: Thursday, 9 November, 2017 13:10:58
> > > >> > > > > Subject: Re: HTTPS LB and x-forwarded-for
> > > >> > > >
> > > >> > > > > Wido,
> > > >> > > > >
> > > >> > 

Re: [FS] Request for comments: Secure VM Live Migration for KVM

[Rafael Weingärtner]

Marc I added permission to you; can you test if you can make comments now?

On Fri, Nov 17, 2017 at 11:20 AM, Marc-Aurèle Brothier - Exoscale <
ma...@exoscale.ch> wrote:

> I'm not able to post comments on the wiki even when logged in so I post
> to the mailing list. I guess I'm not in any special wiki group to edit
> CS pages.
>
> Good news you made the live migration working (right?) on master. Is it
> really something we want to control under CS on the agent installation
> all this libvirt TLS setup? Maybe the installation could write libvirtd
> configuration file for TLS and non-TLS setup in CS and/or libvirt /etc
> directory but without overriding the normal one. I have to admit I'm
> not familiar with how things are usually done in CS for external
> components.
>
> You can also add to cloudstack configuration the libvirt flags used for
> the live migration, which should be customizable in some way. On my PR
> it's in agent.properties, but it could be sent along with the migration
> command.
>
> I would welcome if you could setup a wiki page that I could edit on the
> KVM live migration so I could add my remark on my experience and things
> to config/consider.
>
> On your question: +1 on having the configuration value for TLS or plain
> tcp.
>
> Marc-Aurèle
>
> On Thu, 2017-11-16 at 10:32 +, Rohit Yadav wrote:
> > All,
> >
> >
> > Kindly review and share your thoughts and comments for a new feature
> > - Secure VM live migration for KVM, this feature builds on top of the
> > previous feature that brought in a new CA framework [1] for
> > CloudStack.
> >
> >
> > Here is a rough first draft for your review:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+KVM+VM+
> > Live+Migration
> >
> >
> > [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Age
> > nt+Communications
> >
> >
> > Regards.
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
>



-- 
Rafael Weingärtner

Re: [FS] Request for comments: Secure VM Live Migration for KVM

[Marc-Aurèle Brothier - Exoscale]

I'm not able to post comments on the wiki even when logged in so I post
to the mailing list. I guess I'm not in any special wiki group to edit
CS pages.

Good news you made the live migration working (right?) on master. Is it
really something we want to control under CS on the agent installation
all this libvirt TLS setup? Maybe the installation could write libvirtd
configuration file for TLS and non-TLS setup in CS and/or libvirt /etc
directory but without overriding the normal one. I have to admit I'm
not familiar with how things are usually done in CS for external
components.

You can also add to cloudstack configuration the libvirt flags used for
the live migration, which should be customizable in some way. On my PR
it's in agent.properties, but it could be sent along with the migration
command.

I would welcome if you could setup a wiki page that I could edit on the
KVM live migration so I could add my remark on my experience and things
to config/consider.

On your question: +1 on having the configuration value for TLS or plain
tcp.

Marc-Aurèle

On Thu, 2017-11-16 at 10:32 +, Rohit Yadav wrote:
> All,
> 
> 
> Kindly review and share your thoughts and comments for a new feature
> - Secure VM live migration for KVM, this feature builds on top of the
> previous feature that brought in a new CA framework [1] for
> CloudStack.
> 
> 
> Here is a rough first draft for your review:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+KVM+VM+
> Live+Migration
> 
> 
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Age
> nt+Communications
> 
> 
> Regards.
> 
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>   
>  
> 

Re: POLL: ACL default egress policy rule in VPC

[Rene Moser]

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é