GitHub user TadiosAbebe added a comment to the discussion: Shared network issue on advanced zone with security group
I was able to do some more test today spinning up a test Cloudstack environment and here are my findings, - For a KVM host that doesn't have docker installed, the default FORWARD chain on iptables have an ACCEPT policy, and both instances on isolated network and instances on shared network with security group seems to have connectivity to the outside. - As soon as docker is installed on that KVM host the default policy for the FORWARD Chain gets changed to DROP and instances on the isolated network loss connectivity to the outside( VM -> VR and VR to internet) while the instance that reside on the shared network with security group works fine. - I guess the theory here is since shared network with securty groups add its own chain that allow or drop traffic the instance on the shared network keeps working without an issue - And since isolated networks don't have specific rules the traffic gets caught by the docker DROP policy. - Adding `iptables -I FORWARD 1 -m physdev --physdev-is-bridged -j ACCEPT` will make instances on the isolated network to work again. > It would be great if some one with a better understanding of Linux networking > shade some light on the above because i am not sure if this is exactly what > is happening it is just my guess. Specifically i don't understand why the > docker chain drop the traffic only when a shared network with security group > is created on the host. Anyways for my solution, instead of adding `iptables -I FORWARD 1 -m physdev --physdev-is-bridged -j ACCEPT`, When I review the Cloudstack installation guide and I saw steps on setting the DEFAULT_FORWARD_POLICY to ACCEPT and enabling ufw, when i check my ufw it was inactive(don't remember why i have disabled it), but I add ufw rules and re-enabled ufw. Not sure if what resolved the connectivity issue is the DEFAULT_FORWARD_POLICY or other ufw rules, but it resolved the issue, now both the instances on the shared network and isolated network can communicate out to the internet. Now getting back to my followup questions 1. the reason i needed to create a shared network is mainly for public traffic for guest vms that need direct public ip to virtual machine without a VR, and i am only able to create the shared network on physical network 3(which is the bridge that have guest traffic type), will i be having any issue architecturally residing public traffic on guest traffic type? 2. what issue would i be having if i create different shared network with the same vid(by enabling vlan id overlap) for different domains and set different start and end ip range. So for example - domain1 -> share-net-domain1[vid: 12 gw: 172.19.1.1 netmask: 255.255.255.0 start_ip: 172.19.1.5 end_ip: 172.19.1.10] - domain2 -> share-net-domain1[vid: 12 gw: 172.19.1.1 netmask: 255.255.255.0 start_ip: 172.19.1.11 end_ip: 172.19.1.15] - domain3 -> share-net-domain1[vid: 12 gw: 172.19.1.1 netmask: 255.255.255.0 start_ip: 172.19.1.16 end_ip: 172.19.1.20] from my understanding if i do the above, user on domain1 can only use ip 172.19.1.5-172.19.1.10 securiy groups will prevent him from stealing and manually assigning an ip from domain2. is this correct? GitHub link: https://github.com/apache/cloudstack/discussions/11955#discussioncomment-14847348 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
