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 proposed changes? Other feedback? > > > > Regards, > > Nicolas Vazquez > > Nicolas Vazquez > > Head of Customer Engineering > > *s:* +44 20 3603 0540 <+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ć
