Repository navigation
Shared network UI constraints prevent VR IP from matching gateway IP #12953
Description
Activity
Thanks for opening your first issue here! Be sure to follow the issue template!
🏷️ Issue Triaged
Hi
@llukeell! I've categorized this issue as feature based on the following analysis:Reasoning: This is a feature request to modify UI constraints for shared network configuration, specifically to allow VR IP to match gateway IP, as indicated by the "required feature described as a wish" section.
View Triage Details
Analysis
- Keywords detected: "required feature", "wish", "Expected behavior: Allow", "provide a supported configuration path"
- Issue type indicators: Requests new functionality to relax existing UI constraints for a specific network configuration scenario
- Confidence: High
Recommended Next Steps
- Consider if this is a bug in the UI validation logic or an intentional design choice
- Evaluate security implications of allowing VR IP to match gateway IP
- Review the workaround mentioned (manual database update) to understand if this is already supported in the backend
References: Triage run §23949484533
Generated by Issue Triage Agent
To install this workflow, run
gh aw add github/gh-aw/.github/workflows/issue-triage-agent.md@94662b1dee8ce96c876ba9f33b3ab8be32de82a4. View source at https://github.com/github/gh-aw/tree/94662b1dee8ce96c876ba9f33b3ab8be32de82a4/.github/workflows/issue-triage-agent.md.@llukeell , I think one would use a shared network if the VMs need direct access to the gateway provided and not need to have their connectivity go through the VR, hence the VR IP would never be that of the gateway. What you describe would be isolated network functionality.
please clarify if I see it wrong.
Reacted by Wei Zhou@llukeell , I think one would use a shared network if the VMs need direct access to the gateway provided and not need to have their connectivity go through the VR, hence the VR IP would never be that of the gateway. What you describe would be isolated network functionality.
please clarify if I see it wrong.
+1 with what @DaanHoogland said.
@llukeell
what's your use case to have VR as gateway in shared network ?- locked and limited conversation to collaborators
on May 13, 2026
The required feature described as a wish
When creating a shared network, the CloudStack UI enforces two mutually exclusive constraints:
Gateway IP cannot be within the guest IP range
Virtual router IP must be within the guest IP range
This makes it impossible for the VR IP and gateway IP to match. As a result, the VR health check (gateways_check.py) fails permanently since nothing responds at the gateway IP in a virtual environment.
Steps to reproduce:
Expected behavior:
Allow the VR IP to be designated as the gateway IP, or provide a supported configuration path where the VR IP and gateway IP can match.
Workaround:
Manually update nics.gateway and vlan.vlan_gateway in the database to match the VR's assigned IP.
CloudStack version: 4.22.0.0
Hypervisor: KVM
Zone type: Security Group zone