Hi, so ACL doesn't really affect LB as far as I know and can tell - i.e. if you do LB port 80, you can not really filter who can connect to it...everyone can connect !
Why? - it's about implementation, which you can check below, in case you have free time to read :) Port Forwarding or Static Nat traffic (as defined in CloudStack) is filtered via iptables inside Virtual Router because inside the iptables main FORWARD chain, traffic is sorted/redirected to the appropriate sub-chain i.e. "ACL_INBOUND_eth2" and "ACL_OUTBOUND_eth2", where eth2 is the network (nic) on which you applied certain ACL in CloudStack. A single CloudStack ACL (all it's rules ) are being split in 2 different sub-chains, as in explained above - all inbound rules are added to "acl_inbound_eth2", and all outbound rules are added to "acl_outbound_eth2" - so this is how magic happens in filtering in/out traffic to a network - any internal network of VPC. But, again, remember these are ACL rules (iptables sub-chains) inside the main *FORWARD* chain - since VR is doing FORWARDING of traffic from internet to internal network by effectively doing a DNAT on the incoming IP packet from Internet... Now... LB vs ACL. LB=haproxy, works in different way - here the VR (haproxy) accepts connections from internet on local VR port (named "Public port", as named/configured in ACS - check with "netstat -antup | grep PORT") - and this is the main INPUT chain of iptables. Imagine doing LB for port 80 - this means there will be a single ALLOW rule created directly inside this main ACCEPT chain allowing remote connection to the (local) port 80 on the VR (haproxy) - again check with netstat, you will see local port 80 listening on the public NIC of the VR ! Next step in LB proxying process: VR (haproxy) initiates a BRAND NEW TCP connection from itself (from internal interface this time, say, from eth2) to the internal destination VM, which means the main OUTPUT chain in iptables is evaluated now (it's not forwarding traffic, it is a brand new TCP connection) - but main OUTPUT chain allows all outbound connections from the VR itself (I'm talking about main OUTPUT chain, which means all connections from VR alone only!, are allowed - i.e. this doesn't evaluate/allow traffic from/to internal networks). In other words, ACLs are not applicable for LB rules :) You can check all this by logging inside VR and examining iptables (i.e. do "iptables-save" with different ACLs applied, then diff the 2 files which you saved). Boring, but perhaps interesting... Cheers Andrija On Mon, 5 Nov 2018 at 21:05, Matheus Fontes <[email protected]> wrote: > Hi, > Do acls work with public load balancers in vpc? > If I use a port forward or static nat on public ips inside vpc they work > perfect, but when I change a port from port forwarding to load balance the > acls are not working. > We are using Cloudstack 4.11.1 > > Thanks > Matheus Fontes -- Andrija Panić
