server: scope IPv6 security group member rules to the exact host by nagaboinaramgopal · Pull Request #14037 · apache/cloudstack

nagaboinaramgopal · 2026-09-02T14:45:33Z

Description

When a security group rule references another security group, each member VM
should be authorized as an exact host. The IPv4 address is correctly pinned to a
/32, but the IPv6 address was expanded to /64, opening the whole subnet the
member sits in rather than just that member. This silently broadens the rule to
every address in the member's /64.

Pin the IPv6 member to /128 to match the IPv4 behaviour.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Feature/Enhancement Scale or Bug Severity

Bug Severity

Minor

How Has This Been Tested?

Added a unit test asserting an IPv6 security-group member is authorized as a /128
host and not the whole /64. Also built the standard packages and deployed on a KVM
advanced zone.

wido

Code looks good. This is a very common IPv6 oversight of people. Good catch! Lets merge this one quickly

DaanHoogland · 2026-09-03T16:33:07Z

Code looks good. This is a very common IPv6 oversight of people. Good catch! Lets merge this one quickly

but in the 4.20 branch. by the looks of it this has been in since 4.19.4?

When a security group rule references another security group, each member VM should be authorized as an exact host. The IPv4 address is correctly pinned to a /32, but the IPv6 address was expanded to /64, opening the whole subnet the member sits in rather than just that member. Pin the IPv6 member to /128 to match the IPv4 behaviour.

wido · 2026-09-03T16:55:58Z

Code looks good. This is a very common IPv6 oversight of people. Good catch! Lets merge this one quickly

but in the 4.20 branch. by the looks of it this has been in since 4.19.4?

I did not check. But lets make sure it at least goes into 4.20 and onwards

DaanHoogland · 2026-09-03T17:07:47Z

tnx guys

codecov · 2026-09-03T17:15:48Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 16.40%. Comparing base (2cd8c5e) to head (6ecb8ec).
⚠️ Report is 18 commits behind head on 4.20.

Additional details and impacted files

@@             Coverage Diff              @@
##               4.20   #14037      +/-   ##
============================================
+ Coverage     16.34%   16.40%   +0.05%     
- Complexity    13574    13635      +61     
============================================
  Files          5669     5669              
  Lines        501368   501541     +173     
  Branches      60903    60925      +22     
============================================
+ Hits          81964    82261     +297     
+ Misses       410219   410058     -161     
- Partials       9185     9222      +37

Flag	Coverage Δ
uitests	`4.16% <ø> (+0.01%)`	⬆️
unittests	`17.26% <100.00%> (+0.05%)`	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

DaanHoogland · 2026-09-03T18:43:00Z

@blueorangutan package

blueorangutan · 2026-09-03T18:44:04Z

@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.

blueorangutan · 2026-09-03T20:11:07Z

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19090

nagaboinaramgopal · 2026-09-15T15:12:31Z

Thanks @wido for the review and @DaanHoogland for the package build. This needs a smoke test run and a second review.

DaanHoogland · 2026-10-01T14:29:46Z

@blueorangutan test

blueorangutan · 2026-10-01T14:38:04Z

@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

blueorangutan · 2026-10-02T06:52:57Z

[SF] Trillian test result (tid-17058)
Environment: kvm-ol8 (x2), zone: Advanced Networking with Mgmt server ol8
Total time taken: 54957 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr14037-t17058-kvm-ol8.zip
Smoke tests completed. 141 look OK, 0 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File

weizhouapache · 2026-10-02T09:13:08Z

@nagaboinaramgopal
have you tested it ?

After digging into it, I think the same change is needed in SecurityGroupManagerImpl2.java as well.

…host

nagaboinaramgopal · 2026-10-05T16:59:20Z

Good catch, thanks. SecurityGroupManagerImpl2 overrides generateRulesForVM and builds the member CIDRs from the VO join, so it had the same thing: the IPv4 member at /32 but the IPv6 member at /64 (line 253). I've set it to /128 to match the exact-host scope, and added a unit test for the Impl2 path alongside the existing one.

weizhouapache

code lgtm

Damans227 · 2026-10-05T21:11:20Z

                            cidrs.add(cidr);
                            if (defaultNic.getIPv6Address() != null) {
-                                cidrs.add(defaultNic.getIPv6Address() + "/64");
+                                cidrs.add(defaultNic.getIPv6Address() + "/128");


what happens to vms that pick their own random ipv6 address, like windows does by default? looks like their traffic wont match this single address anymore

Thanks for raising this, it's a good thing to pin down. I went and looked at the agent side to be sure, and I think we might actually be covered here, though let me know if I'm missing a case.

From what I can see, a VM can't really put a self-chosen address on the wire in an SG network anyway. The KVM agent installs a source anti-spoof rule in security_group.py (the -m set ! --match-set <vmipset6> src -j DROP near the end of the IPv6 default chain), and that ipset only gets the addresses CloudStack assigned to the NIC. So a Windows temporary/privacy address wouldn't be in the set, and its traffic would get dropped at that VM's own vNIC before the receiving VM's member rule is ever looked at. If that reading is right, then /64 wasn't really letting those packets through either, they just died earlier in the path.

Where /64 did make a difference, I think, is that it also let any other VM sharing that /64 reach the protected VM, member or not, and narrowing to /128 lines it up with what the IPv4 side already does at /32. Does that match how you understand it, or is there a setup where a VM ends up sending from an address CloudStack didn't assign?

makes sense, the agent drops anything from an address it didnt assign so /64 wasnt helping there. thanks for checking

boring-cyborg Bot added component:networking component:security-group labels Sep 2, 2026

DaanHoogland requested a review from weizhouapache September 2, 2026 17:41

wido approved these changes Sep 3, 2026

View reviewed changes

nagaboinaramgopal force-pushed the fix/secgroup-ipv6-host-cidr branch from 8358dfa to 8c6df72 Compare September 3, 2026 16:56

DaanHoogland changed the base branch from main to 4.20 September 3, 2026 17:05

DaanHoogland added this to the 4.20.4 milestone Sep 3, 2026

DaanHoogland added this to CloudStack Testing Sep 3, 2026

github-project-automation Bot moved this to Backlog in CloudStack Testing Sep 3, 2026

DaanHoogland moved this from Backlog to Ready in CloudStack Testing Sep 3, 2026

This comment was marked as outdated.

Sign in to view

weizhouapache self-requested a review October 2, 2026 09:12

server: scope the Impl2 IPv6 security group member rule to the exact …

6ecb8ec

…host

weizhouapache approved these changes Oct 5, 2026

View reviewed changes

Damans227 reviewed Oct 5, 2026

View reviewed changes

Damans227 approved these changes Oct 5, 2026

View reviewed changes

Conversation

nagaboinaramgopal commented Sep 2, 2026

Description

Types of changes

Feature/Enhancement Scale or Bug Severity

Bug Severity

How Has This Been Tested?

Uh oh!

wido left a comment

Choose a reason for hiding this comment

Uh oh!

DaanHoogland commented Sep 3, 2026

Uh oh!

wido commented Sep 3, 2026

Uh oh!

DaanHoogland commented Sep 3, 2026

Uh oh!

codecov Bot commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

DaanHoogland commented Sep 3, 2026

Uh oh!

blueorangutan commented Sep 3, 2026

Uh oh!

blueorangutan commented Sep 3, 2026

Uh oh!

nagaboinaramgopal commented Sep 15, 2026

Uh oh!

DaanHoogland commented Oct 1, 2026

Uh oh!

blueorangutan commented Oct 1, 2026

Uh oh!

blueorangutan commented Oct 2, 2026

Uh oh!

This comment was marked as outdated.

Uh oh!

weizhouapache commented Oct 2, 2026

Uh oh!

nagaboinaramgopal commented Oct 5, 2026

Uh oh!

weizhouapache left a comment

Choose a reason for hiding this comment

Uh oh!

Damans227 Oct 5, 2026

Choose a reason for hiding this comment

Uh oh!

nagaboinaramgopal Oct 5, 2026

Choose a reason for hiding this comment

Uh oh!

Damans227 Oct 5, 2026

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

codecov Bot commented Sep 3, 2026 •

edited

Loading