Thanks Anthony for the quick response, that appears to have worked perfectly. Looking forward to the 4.1 release now!
Just to note I had to remove the ebtables package without pulling dependencies otherwise libvirt and cloud-agent would have been removed too. rpm -e --nodeps ebtables On 5 Feb 2013, at 17:44, Anthony Xu <xuefei...@citrix.com> wrote: > Hi Nick, > > This issue was fixed in 4.1 > > Try below workaround for 4.0.0. > - stop cloud Agent service on KVM host > - execute iptables -F, ebtables -F on KVM host > - uninstall ebtables package on KVM host > - start cloud Agent service on KVM host > > > After uninstall ebtables package, CS thinks this KVM host cannot support SG, > and will not program Security group for this host. > > > --Anthony > > >> -----Original Message----- >> From: Nick Wales [mailto:n...@nickwales.co.uk] >> Sent: Tuesday, February 05, 2013 3:18 PM >> To: cloudstack-users@incubator.apache.org >> Subject: Problematic firewall rules for basic zone with no security >> groups >> >> I am running CS 4.0.0 running KVM. I have a basic zone with a network >> offering providing DHCP and USERDATA only. >> >> When I create a new instance I get the following iptables rules: >> >> Chain i-2-18-VM (1 references) >> target prot opt source destination >> DROP all -- anywhere anywhere >> >> Chain i-2-18-VM-eg (1 references) >> target prot opt source destination >> >> Chain i-2-18-def (2 references) >> target prot opt source destination >> ACCEPT all -- anywhere anywhere state >> RELATED,ESTABLISHED >> ACCEPT udp -- anywhere anywhere PHYSDEV >> match --physdev-in vnet13 --physdev-is-bridged udp spt:bootpc >> dpt:bootps >> ACCEPT udp -- anywhere anywhere PHYSDEV >> match --physdev-out vnet13 --physdev-is-bridged udp spt:bootps >> dpt:bootpc >> RETURN udp -- 10.28.175.130 anywhere PHYSDEV >> match --physdev-in vnet13 --physdev-is-bridged udp dpt:domain >> i-2-18-VM-eg all -- 10.28.175.130 anywhere PHYSDEV >> match --physdev-in vnet13 --physdev-is-bridged >> i-2-18-VM all -- anywhere anywhere PHYSDEV >> match --physdev-out vnet13 --physdev-is-bridged >> >> I can't ping or ssh to the guest until I remove the DROP line. I >> obviously want to avoid this step every time I spin up a new instance >> and I can't add rules to the default security group as I don't have one. >> I want completely unrestricted access to these guests from first boot >> and I was under the impression not having security groups would provide >> this. Please confirm if this is the case! >> >> I have also changed and changed back the global setting: >> "network.securitygroups.defaultadding" to false but that had seemingly >> no impact. >> >> >> In other news I also got the following rules added initially, which >> stop things like console services from working. "public" is the bridge >> name so I presume that is >> >> Chain FORWARD (policy ACCEPT) >> target prot opt source destination >> BF-public all -- anywhere anywhere PHYSDEV >> match --physdev-is-bridged >> BF-public all -- anywhere anywhere PHYSDEV >> match --physdev-is-bridged >> DROP all -- anywhere anywhere >> DROP all -- anywhere anywhere >> >> If I comment out the following in the configuration file then >> everything works. >> -a FORWARD -o public -j DROP >> -a FORWARD -i public -j DROP >> >> I'd like to remove this manual step if at all possible though. >> >> Any help much appreciated.
