missed this one, sorry.... We can, but the point is that it becomes a default one. What does a new operator/ACS user knows... - which means identical behaviour (give or take) as the PR itself.
On Wed, Sep 16, 2026 at 9:21 AM Wei ZHOU <[email protected]> wrote: > Hi Andrija, > > Just a thought: could we introduce a new network offering with the default > egress policy set to true? > > This would avoid breaking backwards compatibility or causing unexpected > changes for existing users, while still providing a new option for users > who prefer the default ALLOW behavior. > > > > Kind regards, > > Wei > > On Mon, Sep 14, 2026 at 10:57 PM Andrija Panic <[email protected]> > wrote: > > > Hi all, > > > > Before commenting, a disclosure: I opened this PR out of frustration *as > an > > operator*. I worked as a consultant at ShapeBlue for eight years, but I > no > > longer work there. This proposal reflects my experience building and > > running CloudStack in production, including before joining ShapeBlue. > > > > I still support this change. Allowing outbound connectivity by default > > provides a more practical starting point for many deployments. To be > clear, > > this discussion concerns *egress traffic for non-VPC isolated networks*. > > > > Thanks to Wei for spending time testing and clarifying the behavior. The > > relevant detail is the final rule CloudStack generates at the end of the > > egress chain. It remains there whether the operator has added no rules or > > several rules, determining what happens to traffic that has not matched > > earlier rules. Conceptually, it serves the same purpose as a firewall > > chain’s default action. > > > > My broader point is that operators should deliberately define and > > understand their intended firewall behavior. For restricted outbound > > access, that means allowing the required traffic and denying everything > > else. *With an ordered ALLOW/DENY ruleset, the natural expression of that > > intent is a final catch-all DENY after the explicit ALLOW rules. > Operators > > should be able to express and verify that intent without depending on an > > undocumented, automatically generated fallback*. > > > > We could also discuss removing the generated final rule entirely. > However, > > that would require testing where unmatched traffic goes next and which > > subsequent rule or chain policy ultimately accepts or drops it. I do not > > think that is a sensible way to simplify this change. > > > > I understand the concern about compatibility, especially given the > > unintended regressions we have introduced over the years. This change > needs > > careful testing and clear communication. I respectfully disagree, > however, > > that it necessarily makes the documentation confusing. > > > > For *CloudStack 24.0*, I would strongly support a prominent release-note > > entry explaining the change from default DENY to default ALLOW, its scope > > for fresh installations and newly created offerings, and the preservation > > of existing offerings on upgrade. The documentation should explicitly > > explain the generated fallback rule and how user-defined rules interact > > with it. > > > > Wei’s concerns about Terraform and similar tooling deserve clear examples > > and guidance. Having operated a range of production and hosting > > environments, I believe users will find this beneficial—but the > > documentation must be visible and precise enough to prevent surprises. > > My 2 cents. > > > > Regards, > > > > On Fri, Sep 11, 2026 at 9:53 AM Wei ZHOU <[email protected]> wrote: > > > > > Hi Nicolas, > > > > > > Thanks for raising this discussion. I've added the users mailing list > as > > a > > > recipient. > > > > > > Short summary: we're discussing changing the default egress policy of > the > > > default network offering > > > *DefaultIsolatedNetworkOfferingWithSourceNatService*. Opinions are > split. > > > Since users will be more affected by this change than developers, I'd > > like > > > to hear from the users list specifically. > > > > > > I'm one of the people who disagree with the change. It's a small change > > and > > > doesn't affect *new* users — in fact it helps them, since they won't > need > > > to add egress rules to allow outbound traffic from VMs, and it makes > the > > > offering consistent with security groups and network ACLs, where no > > egress > > > rule means all outgoing traffic is allowed by default. > > > > > > However, it does have impact on *existing* users: > > > > > > - *Mixed environments*: if a user runs both fresh installations and > > > upgraded environments, the two will behave differently, and users > need > > > to > > > be aware of that. > > > - *Automation*: users relying on automation tools will need to check > > the > > > egress policy explicitly rather than assume a default. > > > - *Preserving current behavior*: users who want to keep the existing > > > behavior on new installations will need to create a custom network > > > offering > > > with egressdefaultpolicy=false. > > > - *CIDR-restricted users*: users who rely on egress rules to permit > > only > > > specific CIDRs will need to create a new deny-by-default offering > and > > > migrate their networks to it, since there's no way to layer > > > restrictions on > > > top of an offering that's already allow-by-default. > > > - *Documentation drift*: existing docs, wiki pages, and third-party > > > guides that instruct users to add an egress rule to allow outbound > > > traffic > > > will be inconsistent with the new default, which may confuse users > > > following older guides during the transition. > > > > > > > > > I'd like to hear from others in the community, especially users running > > > CloudStack in production, on whether this change would impact you and > > how. > > > > > > > > > Kind regards, > > > Wei > > > > > > On Fri, Sep 11, 2026 at 12:14 AM Nicolas Vazquez < > > > [email protected]> wrote: > > > > > > > Hi all, > > > > > > > > I'd like to raise a topic for discussion regarding the changes > proposed > > > in > > > > a PR targeted to 24.0: > https://github.com/apache/cloudstack/pull/13684 > > > > (reverted). The PR proposes changing the default egress policy for > > > Isolated > > > > networks from Deny to Allow, applying to new installations and to new > > > > Isolated networks created from new network offerings (existing > networks > > > > remain unchanged). > > > > > > > > The proposed change does not update the egress policy values in the > > > > database for existing Isolated networks on upgraded environments. > > > However, > > > > it does set the default egress policy for the default Isolated > network > > > > offering to Allow on fresh installations (starting from 24.0, for > > > example). > > > > This results in two distinct scenarios: > > > > > > > > > > > > - Upgrading existing environments to 24.0: No change to the > default > > > > Isolated network offering. Any network created from the default > > > network > > > > offering after the upgrade will behave as before, with a Deny > egress > > > policy. > > > > - Fresh installations starting on 24.0: The default Isolated > network > > > > offering will have an Allow egress policy. Any network created > from > > > the > > > > default network offering will have Allow egress policy. > > > > > > > > > > > > As a result, the default Isolated network offering may behave > > differently > > > > across environments, depending on whether the environment was freshly > > > > installed (post-24.0) or upgraded from a long-running deployment. > > > > > > > > For new network offerings, the default egress policy will be set to > > Allow > > > > and the change can be documented/highlig > <https://www.google.com/maps/search/change+can+be+documented%2Fhighlig?entry=gmail&source=g>hted > in the release notes. > > > > > > > > What are your thoughts on the propos > <https://www.google.com/maps/search/at+are+your+thoughts+on+the+propos?entry=gmail&source=g>ed > changes? Should we include this > > in > > > > 24.0? Any ideas/proposals to the propos > > < > https://www.google.com/maps/search/Any+ideas%2Fproposals+to+the+propos?entry=gmail&source=g > >ed > > changes? Other feedback? > > > > > > > > Regards, > > > > Nicolas Vazquez > > > > Nicolas Vazquez > > > > Head of Customer Engineering > > > > *s:* +44 20 3603 0540 <+44%2020%203603%200540> > <+44%2020%203603%200540> > > <+44%2020%203603%200540> > > > > *e:* [email protected] | * w: *www.shapeblue.com |* > t:* > > > > @shapeblue > > > > *a:* 3 London Bridge Street, 3rd floor > > > > < > > > > > > https://www.google.com/maps/search/3+London+Bridge+Street,++3rd+floor?entry=gmail&source=g > > > >, > > > > News Building, London, SE1 9SG, UK > > > > <https://www.cloudstackcollab.org> > > > > ------------------------------ > > > > > > > > Find out more about ShapeBlue and our range of CloudStack related > > > services: > > > > IaaS Cloud Design & Build > > > > <http://shapeblue.com/iaas-cloud-design-and-build/> | CloudStack > > > > Consulting <http://shapeblue.com/cloudstack-consultancy/> | > CloudStack > > > > Software Engineering > > > > <http://shapeblue.com/cloudstack-software-engineering/> > > > > CloudStack Infrastructure Support > > > > <http://shapeblue.com/cloudstack-infrastructure-support/> | > CloudStack > > > > Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/ > > > > > > > > > > Shape Blue Ltd is a company incorporated in England & Wales. > ShapeBlue > > is > > > > a registered trademark. This email and any attachments to it may be > > > > confidential and are intended solely for the use of the individual to > > > whom > > > > it is addressed. Any views or opinions expressed are solely those of > > the > > > > author and do not necessarily represent those of Shape Blue Ltd or > > > related > > > > companies. If you are not the intended recipient of this email, you > > must > > > > neither take any action based upon its contents, nor copy or show it > to > > > > anyone. Please contact the sender if you believe you have received > this > > > > email in error. > > > > > > > > > > > > > > > > > > > > > -- > > > > Andrija Panić > > > -- Andrija Panić
