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/highlighted in the release notes. > > > > > > What are your thoughts on the proposed 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> > > > *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ć >
