cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] [Resolved] (CLOUDSTACK-10200) ACL not applied for PrivateGateway inside ACL_INBOUND/OUTBOUND chains. Traffic blocked by next DROP rule
Date Thu, 21 Dec 2017 11:50:00 GMT


    Resolution: Fixed

> ACL not applied for PrivateGateway inside ACL_INBOUND/OUTBOUND chains. Traffic blocked
by next DROP rule
> --------------------------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-10200
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.9.0,,
>         Environment: CloudStack with advanced network installation
>            Reporter: IGOR VOLOSHANENKO
>              Labels: pull-request-available
>             Fix For: Future,
> We found bug in ACL rules for PrivateGateway for VPC
> At a glance - rules not applied - switching Allow All or Deny All (default ACL) - showed
as completed - but rules missed.
> Result - traffic via PrivateGateway blocked by next DROP rule in next chains
> How to reproduce:
> 1. Enable PrivateGateway for Cloudstack
> 2. Create VPC
> 3. Provision new PrivateGateway inside VPC with some VLAN
> 4. Change ACL (optional step to show that problem not in initial configuration but in
config itself)
> Expected:
> ACL rules applied (inserted) into correspondig ACL_INBOUND/OUTBOUND chanins for PrivateGateway
interface (ethX) based on ACL which user choose 
> Current:
> No rules inserted. ACL_INBOUND/OUTBOUND_ethX - empty. Traffic blocked by next DROP rule
in FORWARD chain
> Affect - all our corporate customers blocked with access to their own nets via PG and
> Root cause:
> Issue happened because of logic for inserting rules for ACL_INBOUND/OUTBOUND
> We choose rule numebr to isnert right before last DROP rule - but forget about fact -
that if chain empty - we also return 0 as insert position. Which not true for iptables - numeration
started from 0.
> So we need very small patch to handle this special case - if number of rules inside chain
equal to zero - return 1, else - return count of rules inside chain.
> It's found only one - just because be default for PrivateGateway - we didn't insert any
"service rules" (if SourceNat for PrivateGteway not ticked) - and we have by default empty
ACL_INBOUND/OUTBOUND chains. Because same insert happened for all VPC networks (but when we
call this insert - we already have at least 1 rule inside chains - and we successfully can

This message was sent by Atlassian JIRA

View raw message