Repository navigation
CS4.22.0 vROUTER ACLs Feature is non RFC compliant applied to Internal Interface #13266
Description
Activity
@tatay188
can you give some examples of step2 and step3 ?Step 2: example:
<style> </style>protocol traffictype state cidrlist aclid aclname number action fordisplay all Ingress Active 45.128.0.0/17 ****************************76311 VPC-ROUTED 1 Deny TRUE all Ingress Active 5.0.0.0/8 ****************************76311 VPC-ROUTED 2 Deny TRUE all Ingress Active 149.202.0.0/16 ****************************76311 VPC-ROUTED 3 Deny TRUE all Ingress Active 217.154.0.0/21 ****************************76311 VPC-ROUTED 4 Deny TRUE all Ingress Active 137.74.0.0/16 ****************************76311 VPC-ROUTED 5 Deny TRUE all Ingress Active 2.57.0.0/16 ****************************76311 VPC-ROUTED 6 Deny TRUE all Ingress Active 179.43.128.0/18 ****************************76311 VPC-ROUTED 7 Deny TRUE all Ingress Active 193.104.0.0/16 ****************************76311 VPC-ROUTED 8 Deny TRUE all Ingress Active 96.127.128.0/18 ****************************76311 VPC-ROUTED 9 Deny TRUE all Ingress Active 87.0.0.0/8 ****************************76311 VPC-ROUTED 10 Deny TRUE all Ingress Active 107.189.0.0/19 ****************************76311 VPC-ROUTED 11 Deny TRUE all Ingress Active 162.142.125.244/32 ****************************76311 VPC-ROUTED 12 Deny TRUE all Ingress Active 172.110.208.0/20 ****************************76311 VPC-ROUTED 13 Deny TRUE all Ingress Active 172.110.64.0/20 ****************************76311 VPC-ROUTED 14 Deny TRUE all Ingress Active 200.14.40.0/21 ****************************76311 VPC-ROUTED 15 Deny TRUE all Ingress Active 50.128.0.0/9 ****************************76311 VPC-ROUTED 16 Deny TRUE all Ingress Active 51.161.0.0/16 ****************************76311 VPC-ROUTED 17 Deny TRUE all Ingress Active 51.91.0.0/16 ****************************76311 VPC-ROUTED 18 Deny TRUE all Ingress Active 66.178.128.0/21 ****************************76311 VPC-ROUTED 19 Deny TRUE all Ingress Active 0.0.0.0/0 ****************************76311 VPC-ROUTED 20 Allow TRUE all Egress Active 0.0.0.0/0 ****************************76311 VPC-ROUTED 21 Allow TRUE all Ingress Active 0.0.0.0/0 ****************************76311 VPC-ROUTED 22 Deny TRUE Step-3:
I can see the traffic from those blocked IP addresses.There is an Obvious Workaround - Use Egress instead of Ingress - In my case I decided to use Paloalto VNF.
IF change to Egress it should Block them; However, this should be applied to the edge interface/Wan-interface.
Or Give the end User to select Which interface to apply to the ACL.Step-3: I can see the traffic from those blocked IP addresses.
There is an Obvious Workaround - Use Egress instead of Ingress - In my case I decided to use Paloalto VNF. IF change to Egress it should Block them; However, this should be applied to the edge interface/Wan-interface. Or Give the end User to select Which interface to apply to the ACL.
@tatay188
thanks for the info, I will try to reproduce the issue@weizhouapache It Seems like, I am certainly eager to test it.
no hurries, but close at will
🎯 Triage report
The reporter wants VPC ACLs to be applicable to the WAN/edge (public) side of the virtual router rather than only the internal/LAN side, aligning with common firewall conventions (RFC 2827/3704). A maintainer already pointed at PR #12706 as a likely solution and the reporter has not yet confirmed whether it resolves their use case.
📊 Assessment
Dimension Value Reasoning Type type:enhancement Feature request to change/extend where ACLs are applied, not a defect in existing documented behavior. Component component:virtual-router, component:networking Behavior concerns the VPC virtual router's ACL enforcement point. Severity n/a Not a bug — a design/feature request. Labels type:enhancement, component:virtual-router, component:networking See above Coding agent Not suitable Requires an architectural decision (where to enforce ACLs, backward compatibility for existing deployments) already under discussion by maintainers, plus verification against an existing PR. 🔗 Similar issues
- Support Firewall for public IPs in VPC #12706 (related) — maintainer-linked PR that may already address this request; awaiting reporter confirmation.
💡 Notes and suggestions
A maintainer already asked the reporter (2026-07-22) whether PR #12706 solves the use case, and the reporter indicated they still need to build a test environment to verify. This issue may be closable once that verification is confirmed — a maintainer should follow up.
Generated by Daily Issue Triage · sonnet50 262K · ◷
Add this agentic workflows to your repo
To install this agentic workflow, run
gh aw add githubnext/agentics/workflows/daily-issue-triage.md@d7c1dc4b72b00607a67caaffdcc216cb64379cf9- linked a pull request that will close this issueSupport Firewall for public IPs in VPC #12706
on Oct 7, 2026
problem
CS 4.22.0
Host Ubuntu 22.4 KVM
vRouter on VPC ACLs
This VPC ACL feature is beyond good, it's awesome. However @weizhouapache with all the love I have for the team. That's not right, ACL should be applied to the edge - and we know that should not be to interpretation, and many think are just Cisco best practices - we should have a feature to select WAN-side, LAN-side or named Edge-side, Internal-Side which seems are more contemporary names.
Suggestion: if decided to make it RF-ish. To make easy the transition for existing systems, the updated feature will apply to LAN-side (internal-side) by default.
versions
CS 4.22.0
Host Ubuntu 22.4 KVM
running vRouter with 8CPUs and 8GRAM, oversubscription is 1:1 for all systems.
The steps to reproduce the bug
What to do about it?
No response