github-actions[bot] commented on issue #14184: URL: https://github.com/apache/cloudstack/issues/14184#issuecomment-5698667351
## ๐ฏ Triage report On a VPC virtual router, the per-VM static-NAT SNAT rule and the site-to-site VPN NAT exemption are both inserted at the front of the `nat` POSTROUTING chain, so whichever is applied later wins. Enabling static NAT on a VM after a VPN connection already exists puts the SNAT rule ahead of the exemption, causing that VM's VPN-bound traffic to leave with its public IP instead of its private one โ breaking one-directional connectivity to the VPN peer while other VMs remain unaffected. The report includes a clear root cause analysis (with file/line references in `configure.py` and `CsNetfilter.py`) and a concrete proposed fix (adding a `-m mark ! --mark 0x525` exclusion to the SNAT rule). ### ๐ Assessment | Dimension | Value | Reasoning | |---|---|---| | **Type** | type:bug | Clear functional defect causing incorrect NAT behavior/connectivity failure | | **Component** | component:virtual-router, component:networking | Issue is in the VPC virtual router's iptables rule generation (`configure.py`, `CsNetfilter.py`) affecting site-to-site VPN/static NAT networking | | **Severity** | Severity:Major | Breaks VPN connectivity for static-NAT VMs silently (no error surfaced), but has a workaround (recreate the connection, or use port forwarding instead of static NAT) | | **Labels** | type:bug, component:virtual-router, component:networking, Severity:Major | See reasoning above | | **Coding agent** | Suitable | Root cause is precisely identified with file/line references, reproduction steps are detailed, and a specific minimal fix is proposed (adding a mark exclusion to the SNAT rule in `configure.py`) | No similar or duplicate issues were found in the repository. <details><summary>๐ก Notes and suggestions</summary> - The reporter's proposed fix โ appending `-m mark ! --mark 0x525` to the static-NAT SNAT rule in `CsForwardingRules.processStaticNatRule` (`systemvm/debian/opt/cloud/bin/configure.py`) โ looks like the smallest, most robust change since it makes the SNAT rule order-independent rather than relying on insertion order at apply time. - Alternative approaches worth considering during review: re-asserting the VPN exemption at position 1 on every forwarding-rule reapplication, or switching the per-VM SNAT rule from `front`/insert to `append` so it no longer races with the VPN exemption for chain position. - Suggest a maintainer or the reporter verify the fix against both a fresh VR rebuild and an incremental apply (the scenario described) to confirm the ordering issue no longer occurs either way. - Remote-access VPN interaction was explicitly not checked by the reporter and may warrant a follow-up test once the static NAT fix lands. </details> > Generated by [Daily Issue Triage](https://github.com/apache/cloudstack/actions/runs/35102523509) ยท sonnet50 84.6K ยท [โท](https://github.com/search?q=repo%3Aapache%2Fcloudstack+%22gh-aw-workflow-call-id%3A+apache%2Fcloudstack%2Fdaily-issue-triage%22&type=issues) > <details> <summary>Add this agentic workflows to your repo</summary> To install this agentic workflow, run ``` gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9 ``` </details> <!-- gh-aw-agentic-workflow: Daily Issue Triage, engine: copilot, version: 1.0.52, model: claude-sonnet-5, id: 35102523509, workflow_id: daily-issue-triage, run: https://github.com/apache/cloudstack/actions/runs/35102523509 --> <!-- gh-aw-workflow-call-id: apache/cloudstack/daily-issue-triage --> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
