Thanks @daan Hoogland <[email protected]> — ironically 😉 — for both merging *and* reverting this one, all without a heads-up. Jokes aside, no harm done and thanks for the quick revert. Maybe let's keep the merge button away from you mousem, until we're back from the beach next time 😄
On a serious note: I've reopened the identical change as apache/cloudstack#14300 · Network: default egress policy… <https://github.com/apache/cloudstack/pull/14300>. It should stay parked until this thread concludes — please don't merge ahead of that. On Fri, Oct 2, 2026 at 6:16 PM Andrija Panic <[email protected]> wrote: > 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ć > -- Andrija Panić
