Shared network UI constraints prevent VR IP from matching gateway IP

[llukeell]

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:

1. Create a shared network in a Security Group zone
2. Attempt to set the VR IP to match the gateway IP
3. UI returns error: The gateway ip should not be part of the ip range being added
4. Attempt to set VR IP outside the guest range
5. UI returns error: Router IPv4 IP provided is not within the specified range

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

[boring-cyborg[bot]]

Thanks for opening your first issue here! Be sure to follow the issue template!

[github-actions[bot]]

🏷️ 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.

[DaanHoogland]

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

[weizhouapache]

@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 ?