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 > *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. > > >
