cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wales <n...@nickwales.co.uk>
Subject Re: Problematic firewall rules for basic zone with no security groups
Date Wed, 06 Feb 2013 01:59:12 GMT
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.Xu@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:nick@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.


Mime
View raw message