[Openstack] Security Groups rules applied but ignored...
Martinx - ジェームズ
thiagocmartinsc at gmail.com
Thu Nov 7 03:52:36 UTC 2013
Hi!
I'm back to "LibvirtHybridOVSBridgeDriver" and Security Groups are working
again... I did some of cleanups / reboots to make sure and it is okay now.
Tks!
Thiago
On 30 October 2013 19:48, Martinx - ジェームズ <thiagocmartinsc at gmail.com> wrote:
> No problem... =)
>
> My nova.conf [DEFAULT] section have:
>
> ---
> firewall_driver = nova.virt.firewall.NoopFirewallDriver
> security_group_api = neutron
> libvirt_vif_driver = nova.virt.libvirt.vif.LibvirtOpenVswitchDriver
> ---
>
> But, even with "libvirt_vif_driver =
> nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver", it doesn't work as
> expected... I can fallback to HybridOVS, if required / recommended (but the
> non-hybrid is faster).
>
> Tks,
> Thiago
>
>
> On 30 October 2013 16:14, Aaron Rosen <arosen at nicira.com> wrote:
>
>> Whoops sorry about that: nova.conf - http://codepad.org/howA9b1E
>>
>> The only settings matter for this would be:
>>
>> firewall_driver=nova.virt.firewall.NoopFirewallDriversecurity_group_api=quantumlibvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
>>
>>
>>
>>
>> On Tue, Oct 29, 2013 at 4:17 PM, Martinx - ジェームズ <
>> thiagocmartinsc at gmail.com> wrote:
>>
>>> At nova.conf, firewall_driver is under [DEFAULT].
>>>
>>>
>>> On 29 October 2013 20:58, Martinx - ジェームズ <thiagocmartinsc at gmail.com>wrote:
>>>
>>>> Hello my friend! =)
>>>>
>>>> Yes, firewall_driver is under [securitygroup].
>>>>
>>>> ---
>>>> root at net-node-1:~# grep -v ^$
>>>> /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini | grep -v ^#
>>>> [ovs]
>>>> tenant_network_type = vxlan
>>>> enable_tunneling = True
>>>> tunnel_type = vxlan
>>>> tunnel_id_ranges = 1:1000
>>>> integration_bridge = br-int
>>>> tunnel_bridge = br-tun
>>>> local_ip = 10.20.2.52
>>>>
>>>> [agent]
>>>> polling_interval = 2
>>>> tunnel_types = vxlan
>>>>
>>>> [securitygroup]
>>>> firewall_driver =
>>>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>>>>
>>>> [database]
>>>> connection = mysql://
>>>> neutronUser:pofs4433gEW at controller-1.yourdomain.com/neutron
>>>> ---
>>>>
>>>> Aaron, your "nova.conf" that you pasted, IS your ovs_neutron_plugin.ini
>>>> ... Can you re-paste it, please?
>>>>
>>>> Tks!
>>>> Thiago
>>>>
>>>>
>>>> On 29 October 2013 19:50, Aaron Rosen <arosen at nicira.com> wrote:
>>>>
>>>>> Hi Martinx,
>>>>>
>>>>> can you confirm that firewall_driver is under the securitygroup
>>>>> section? I can confirm that the following nova.conf and
>>>>> ovs_neutron_plugin.ini work with security groups:
>>>>>
>>>>> nova.conf http://codepad.org/vH3aIs8f
>>>>> ovs_neutron_plugin.ini - http://codepad.org/vH3aIs8f
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>> On Mon, Oct 28, 2013 at 8:41 PM, Martinx - ジェームズ <
>>>>> thiagocmartinsc at gmail.com> wrote:
>>>>>
>>>>>> The only way I'm seeing to protect your Havana cloud right now
>>>>>> (topology Per-Tenants Router with Private Networks), is by enabling FWaaS...
>>>>>>
>>>>>> That's it! FWaaS installed, Tenant network protected.
>>>>>>
>>>>>> I think that there is a bug with Security Groups in Havana /
>>>>>> Neutron...
>>>>>>
>>>>>> Comments?!
>>>>>>
>>>>>> Regards,
>>>>>> Thiago
>>>>>>
>>>>>>
>>>>>> On 28 October 2013 22:18, Martinx - ジェームズ <thiagocmartinsc at gmail.com>wrote:
>>>>>>
>>>>>>> Guys,
>>>>>>>
>>>>>>> A new test to see that the packages currently did not mach any
>>>>>>> iptables rules at the compute node, completely bypassing "Security Groups",
>>>>>>> look:
>>>>>>>
>>>>>>>
>>>>>>> * Instance with ONLY port 80 TCP open:
>>>>>>>
>>>>>>> ---
>>>>>>> root at hypervisor-1:~# *iptables -L neutron-openvswi-i2fa3cfab-a -nv*
>>>>>>> Chain neutron-openvswi-i2fa3cfab-a (1 references)
>>>>>>> pkts bytes target prot opt in out source
>>>>>>> destination
>>>>>>> 0 0 DROP all -- * * 0.0.0.0/0
>>>>>>> 0.0.0.0/0 state INVALID
>>>>>>> 0 0 RETURN all -- * * 0.0.0.0/0
>>>>>>> 0.0.0.0/0 state RELATED,ESTABLISHED
>>>>>>> 0 0 RETURN tcp -- * * 0.0.0.0/0
>>>>>>> 0.0.0.0/0 tcp dpt:80
>>>>>>> 0 0 RETURN udp -- * * 192.168.50.3
>>>>>>> 0.0.0.0/0 udp spt:67 dpt:68
>>>>>>> 0 0 neutron-openvswi-sg-fallback all -- * *
>>>>>>> 0.0.0.0/0 0.0.0.0/0
>>>>>>> ---
>>>>>>>
>>>>>>> Starting dumping TCP data directly on instance port:
>>>>>>>
>>>>>>> ---
>>>>>>> root at hypervisor-1:~# *tcpdump -ni tap2fa3cfab-a3*
>>>>>>> tcpdump: WARNING: tap2fa3cfab-a3: no IPv4 address assigned
>>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>>>> decode
>>>>>>> listening on tap2fa3cfab-a3, link-type EN10MB (Ethernet), capture
>>>>>>> size 65535 bytes
>>>>>>> ....
>>>>>>> ---
>>>>>>>
>>>>>>> ....and trying to connect at its port 22 from the Internet (not
>>>>>>> allowed!!):
>>>>>>>
>>>>>>> ---
>>>>>>> thiago at desktop-1:~$ *telnet 189.8.93.69 22 <189.8.93.69%2022>*
>>>>>>> Trying 189.8.93.69...
>>>>>>> Connected to 189.8.93.69.
>>>>>>> Escape character is '^]'.
>>>>>>> SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
>>>>>>> ---
>>>>>>>
>>>>>>> NOTE: *189.8.93.69* is the 'Floating IP' attached to that Instance
>>>>>>> and *192.168.50.2* is the Instance IP.
>>>>>>>
>>>>>>> ---
>>>>>>> root at hypervisor-1:~# *tcpdump -ni tap2fa3cfab-a3*
>>>>>>> tcpdump: WARNING: tap2fa3cfab-a3: no IPv4 address assigned
>>>>>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol
>>>>>>> decode
>>>>>>> listening on tap2fa3cfab-a3, link-type EN10MB (Ethernet), capture
>>>>>>> size 65535 bytes
>>>>>>> 22:13:40.800122 IP 200.232.113.107.7955 > 192.168.50.2.22: Flags
>>>>>>> [S], seq 2257975349, win 29200, options [mss 1460,sackOK,TS val
>>>>>>> 52435018 ecr 0,nop,wscale 7], length 0
>>>>>>> 22:13:40.800525 IP 192.168.50.2.22 > 200.232.113.107.7955: Flags
>>>>>>> [S.], seq 2704020835, ack 2257975350, win 14480, options [mss
>>>>>>> 1460,sackOK,TS val 703831 ecr 52435018,nop,wscale 2], length 0
>>>>>>> 22:13:40.805484 IP 200.232.113.107.7955 > 192.168.50.2.22: Flags
>>>>>>> [.], ack 1, win 229, options [nop,nop,TS val 52435019 ecr 703831], length 0
>>>>>>> 22:13:40.821804 IP 192.168.50.2.22 > 200.232.113.107.7955: Flags
>>>>>>> [P.], seq 1:42, ack 1, win 3620, options [nop,nop,TS val 703837 ecr
>>>>>>> 52435019], length 41
>>>>>>> 22:13:40.826058 IP 200.232.113.107.7955 > 192.168.50.2.22: Flags
>>>>>>> [.], ack 42, win 229, options [nop,nop,TS val 52435025 ecr 703837], length 0
>>>>>>> ---
>>>>>>>
>>>>>>> See?! Security Groups are being ignored.
>>>>>>>
>>>>>>> Please, help!
>>>>>>>
>>>>>>> Thanks! =)
>>>>>>> Thiago
>>>>>>>
>>>>>>>
>>>>>>> On 28 October 2013 22:03, Martinx - ジェームズ <thiagocmartinsc at gmail.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Okay, I think I got it...
>>>>>>>>
>>>>>>>> Nova should proxy 'Security Groups' calls to Neutron (and not do it
>>>>>>>> by itself), so, it must have:
>>>>>>>>
>>>>>>>> --- nova.conf ---
>>>>>>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver
>>>>>>>> security_group_api = neutron
>>>>>>>> ---
>>>>>>>>
>>>>>>>> At Neutron OVS Agent (ovs_neutron_plugin.ini), you must set:
>>>>>>>>
>>>>>>>> ---
>>>>>>>> firewall_driver =
>>>>>>>> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Source:
>>>>>>>> http://docs.openstack.org/havana/install-guide/install/apt/content/install-neutron.install-plugin.ovs.html
>>>>>>>>
>>>>>>>> BUT, it doesn't work.
>>>>>>>>
>>>>>>>> All my Security Groups rules are just being ignored. They are all
>>>>>>>> applied at the Compute Node OVS ports but, no effect at all.
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>> Thiago
>>>>>>>>
>>>>>>>>
>>>>>>>> On 28 October 2013 21:26, Martinx - ジェームズ <
>>>>>>>> thiagocmartinsc at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Well,
>>>>>>>>>
>>>>>>>>> Now I'm using "firewall_driver =
>>>>>>>>> nova.virt.firewall.NoopFirewallDriver" for both Nova and Neutron (Open
>>>>>>>>> vSwitch Agent) but, Security Groups rules are applied but ignored.
>>>>>>>>>
>>>>>>>>> Tips!?
>>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>> Thiago
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 28 October 2013 21:13, Martinx - ジェームズ <
>>>>>>>>> thiagocmartinsc at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Guys,
>>>>>>>>>>
>>>>>>>>>> I'm back using "libvirt_vif_driver =
>>>>>>>>>> nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver" (nova-compute.conf) but
>>>>>>>>>> the problem persist for "tenant1".
>>>>>>>>>>
>>>>>>>>>> My nova.conf contains:
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>> # Network settings
>>>>>>>>>> network_api_class = nova.network.neutronv2.api.API
>>>>>>>>>> neutron_url = http://contrller-1.mydomain.com:9696
>>>>>>>>>> neutron_auth_strategy = keystone
>>>>>>>>>> neutron_admin_tenant_name = service
>>>>>>>>>> neutron_admin_username = neutron
>>>>>>>>>> neutron_admin_password = 123test123
>>>>>>>>>> neutron_admin_auth_url =
>>>>>>>>>> http://controller-1.mydomain.com:35357/v2.0
>>>>>>>>>>
>>>>>>>>>> linuxnet_interface_driver =
>>>>>>>>>> nova.network.linux_net.LinuxOVSInterfaceDriver
>>>>>>>>>>
>>>>>>>>>> # If you want Neutron + Nova Security groups
>>>>>>>>>> firewall_driver = nova.virt.firewall.NoopFirewallDriver
>>>>>>>>>> security_group_api = neutron
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> Is that a valid configuration for Havana?! I'm get it from my
>>>>>>>>>> previous Grizzly setup.
>>>>>>>>>>
>>>>>>>>>> Also, I just realized that, there are two places to configure the
>>>>>>>>>> "firewall_driver", first one is located at nova.conf, the second is located
>>>>>>>>>> at "ovs_neutron_plugin.ini" under [securitygroups], of course, I believe,
>>>>>>>>>> they must "match", I mean, I must be the same for both services, right?!
>>>>>>>>>>
>>>>>>>>>> Thanks!
>>>>>>>>>> Thiago
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 28 October 2013 20:30, Martinx - ジェームズ <
>>>>>>>>>> thiagocmartinsc at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Stackers!
>>>>>>>>>>>
>>>>>>>>>>> I'm trying to configure my Security Groups and, I'm seeing that
>>>>>>>>>>> the rules are being applied at the Compute Node OVS ports (iptables /
>>>>>>>>>>> ip6tables) BUT, it does have no effect (or just being ignored?).
>>>>>>>>>>>
>>>>>>>>>>> I'm using Ubuntu 12.04.3 + Havana from Cloud Archive.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> For example:
>>>>>>>>>>>
>>>>>>>>>>> I have 1 Instance with 1 Floating IP attached to it, open port
>>>>>>>>>>> is: 80.
>>>>>>>>>>>
>>>>>>>>>>> Look:
>>>>>>>>>>>
>>>>>>>>>>> ---
>>>>>>>>>>> root at hypervisor-1:~# iptables -L neutron-openvswi-i9cf07c24-7
>>>>>>>>>>> -nv
>>>>>>>>>>> Chain neutron-openvswi-i9cf07c24-7 (1 references)
>>>>>>>>>>> pkts bytes target prot opt in out source
>>>>>>>>>>> destination
>>>>>>>>>>> 0 0 DROP all -- * * 0.0.0.0/0
>>>>>>>>>>> 0.0.0.0/0 state INVALID
>>>>>>>>>>> 0 0 RETURN all -- * * 0.0.0.0/0
>>>>>>>>>>> 0.0.0.0/0 state RELATED,ESTABLISHED
>>>>>>>>>>> 0 0 RETURN tcp -- * * 0.0.0.0/0
>>>>>>>>>>> 0.0.0.0/0 tcp dpt:80
>>>>>>>>>>> 0 0 RETURN udp -- * * 192.168.50.3
>>>>>>>>>>> 0.0.0.0/0 udp spt:67 dpt:68
>>>>>>>>>>> 0 0 neutron-openvswi-sg-fallback all -- * *
>>>>>>>>>>> 0.0.0.0/0 0.0.0.0/0
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The problem is that the respective Instance still answers SSH to
>>>>>>>>>>> the Internet. I mean, ALL ports are OPEN!! Regardless of what I typed at
>>>>>>>>>>> its Security Groups.
>>>>>>>>>>>
>>>>>>>>>>> I created one "Security Group", called "web", only with TCP port
>>>>>>>>>>> 80 on it, nothing more, nothing less. This Instance doesn't belong to the
>>>>>>>>>>> "default" Security Group", only "web".
>>>>>>>>>>>
>>>>>>>>>>> Recently I've changed the *libvirt_vif_driver* from
>>>>>>>>>>> *nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver* to
>>>>>>>>>>> *nova.virt.libvirt.vif.LibvirtOpenVswitchDriver*, maybe it is
>>>>>>>>>>> the cause?!
>>>>>>>>>>>
>>>>>>>>>>> Any tips!?
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Thiago
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list:
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>> Post to : openstack at lists.openstack.org
>>>>>> Unsubscribe :
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131107/3199a326/attachment.html>
More information about the Openstack
mailing list