cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kirk Kosinski <kirkkosin...@gmail.com>
Subject Re: Problems with firewall
Date Thu, 11 Sep 2014 06:02:52 GMT
I (vaguely) recall seeing something like this.  I think you aren't
supposed to install the CSP on hosts in a basic zone without SG.  Some
but not all iptables get programmed for some reason, and it doesn't
work.  I would check if it works on a host without CSP.  It definitely
isn't needed in such a configuration anyway.

Best regards,
Kirk

On 09/10/2014 10:26 PM, Jayapal Reddy Uradi wrote:
> Hi,
> 
> iptables rules are configured on the host that means CSP is there.
> 
> The setup is basic shared network with out security groups but there are
> SG rules configured for the VM in the host and there is no ingress/egress rules config
option.
> Not sure about with out SG configuring rules for VM is a bug.
> 
> Thanks,
> Jayapal
> 
> 
> On 11-Sep-2014, at 10:27 AM, Kirk Kosinski <kirkkosinski@gmail.com>
>  wrote:
> 
>> Hi, Carlos.  Did you install the CSP on your XS hosts?  Also is Open
>> vSwitch enabled or disabled?
>>
>> Best regards,
>> Kirk
>>
>> On 09/10/2014 02:55 PM, Carlos Reategui wrote:
>>> Hi All,
>>> This is a problem I have had for a while and worked around but would like
>>> to get a proper solution for.   I have configured a basic shared network
>>> without security groups.  The hosts are Xen 6.0.2.  I am currently on 4.3
>>> but had this problem previously on 4.1.x and 4.2.x also.
>>>
>>> The problem is that the iptables firewall is not getting configured
>>> properly on the hosts and therefore I am unable to connect to any of the
>>> VM's on that particular host.  My current solution is to have a crontab
>>> every 5 minutes issue an "/etc/init.d/iptables stop".  The reason I have to
>>> have it on a cron is that every time I create a new instance, the
>>> cloudstack management server also sends a command to configure the firewall
>>> which also turns it back on  (I guess I could also put an exit near the top
>>> of the iptables script but that is still a workaround).  My network
>>> offering does not have security groups so, as expected, I don't have a
>>> means to edit ingress/egress rules.
>>>
>>> Has anyone else run into this?  Is this a bug or something that I have not
>>> properly configured?
>>>
>>> Here is the output of the firewall on one of the hosts after creating a new
>>> instance:
>>> # iptables -L -n
>>> Chain INPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> Chain FORWARD (policy ACCEPT)
>>> target     prot opt source               destination
>>> BRIDGE-FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV
>>> match --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth2+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth6+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth5+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth7+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth3+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth1+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth4+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out bond0+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out eth0+ --physdev-is-bridged
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out bond1+ --physdev-is-bridged
>>> DROP       all  --  0.0.0.0/0            0.0.0.0/0
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target     prot opt source               destination
>>>
>>> Chain BRIDGE-DEFAULT-FIREWALL (1 references)
>>> target     prot opt source               destination
>>> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state
>>> RELATED,ESTABLISHED
>>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-is-bridged udp spt:68 dpt:67
>>> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-is-bridged udp spt:67 dpt:68
>>>
>>> Chain BRIDGE-FIREWALL (1 references)
>>> target     prot opt source               destination
>>> BRIDGE-DEFAULT-FIREWALL  all  --  0.0.0.0/0            0.0.0.0/0
>>> i-3-93-def  all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-in vif20.0 --physdev-is-bridged
>>> i-3-93-def  all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out vif20.0 --physdev-is-bridged
>>>
>>> Chain i-3-93-VM (1 references)
>>> target     prot opt source               destination
>>>
>>> Chain i-3-93-VM-eg (1 references)
>>> target     prot opt source               destination
>>>
>>> Chain i-3-93-def (2 references)
>>> target     prot opt source               destination
>>> RETURN     udp  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-in vif20.0 --physdev-is-bridged set i-3-93-VM src udp dpt:53
>>> DROP       all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-in vif20.0 --physdev-is-bridged !set i-3-93-VM src
>>> DROP       all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out vif20.0 --physdev-is-bridged !set i-3-93-VM dst
>>> i-3-93-VM-eg  all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV
>>> match --physdev-in vif20.0 --physdev-is-bridged set i-3-93-VM src
>>> i-3-93-VM  all  --  0.0.0.0/0            0.0.0.0/0           PHYSDEV match
>>> --physdev-out vif20.0 --physdev-is-bridged
>>>
>>> Thanks,
>>> Carlos
>>>
> 

Mime
View raw message