I saw the counter is not 0. But no sctp conntrack module in my system. How can i find it?
[root@compute02 ~]# ovs-ofctl dump-flows br-int | grep +inv
cookie=0x46c226b6d9a3ff8f, duration=229312.185s, table=72, n_packets=13, n_bytes=1274, idle_age=65534, hard_age=65534, priority=50,ct_state=+inv+trk actions=resubmit(,93)
cookie=0x46c226b6d9a3ff8f, duration=229312.186s, table=82, n_packets=2517, n_bytes=925218, idle_age=65534, hard_age=65534, priority=50,ct_state=+inv+trk actions=resubmit(,93)
[root@compute02 ~]#
[root@compute02 ~]#
[root@compute02 ~]# lsmod | grep sctp
[root@compute02 ~]#
[root@compute02 ~]#
[root@compute02 ~]# modprobe ip_conntrack_proto_sctp
modprobe: FATAL: Module ip_conntrack_proto_sctp not found.
[root@compute02 ~]#
[root@compute02 ~]# cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core)
[root@compute02 ~]#
[root@compute02 ~]# uname -r
3.10.0-957.el7.x86_64
On 05/08/2019 12:01, thuanlk@viettel.com.vn wrote:
> I have tried any version of OpenvSwitch but problem continue happened.
> Is Openvswitch firewall support sctp?
Yes, as long as you have sctp conntrack support in kernel. Can you paste
output of 'ovs-ofctl dump-flows br-int | grep +inv' on the node where
the VM using sctp is running? If the counters are not 0 it's likely that
you're missing the sctp conntrack kernel module.
Jakub
>
> Thanks and best regards !
>
> ---------------------------------------
> Lăng Khắc Thuận
> OCS Cloud | OCS (VTTEK)
> +(84)- 966463589
>
>
> -----Original Message-----
> From: Lang Khac Thuan [mailto:thuanlk@viettel.com.vn]
> Sent: Tuesday, July 30, 2019 11:22 AM
> To: 'smooney@redhat.com' <smooney@redhat.com>; 'openstack-discuss@lists.openstack.org' <openstack-discuss@lists.openstack.org>
> Subject: RE: [neutron] OpenvSwitch firewall sctp getting dropped
>
> I have tried config SCTP but nothing change!
>
> openstack security group rule create --ingress --remote-ip 0.0.0.0/0 --protocol 132 --dst-port 2000:10000 --description "SCTP" sctp openstack security group rule create --egress --remote-ip 0.0.0.0/0 --protocol 132 --dst-port 2000:10000 --description "SCTP" sctp
>
> Displaying 2 items
> Direction Ether Type IP Protocol Port Range Remote IP Prefix Remote Security Group Actions
> Egress IPv4 132 2000 - 10000 0.0.0.0/0 -
> Ingress IPv4 132 2000 - 10000 0.0.0.0/0 -
>
>
> Thanks and best regards !
>
> ---------------------------------------
> Lăng Khắc Thuận
> OCS Cloud | OCS (VTTEK)
> +(84)- 966463589
>
>
> -----Original Message-----
> From: smooney@redhat.com [mailto:smooney@redhat.com]
> Sent: Tuesday, July 30, 2019 1:27 AM
> To: thuanlk@viettel.com.vn; openstack-discuss@lists.openstack.org
> Subject: Re: [neutron] OpenvSwitch firewall sctp getting dropped
>
> On Mon, 2019-07-29 at 22:38 +0700, thuanlk@viettel.com.vn wrote:
>> I have installed Openstack Queens on CentOs 7 with OvS and I recently
>> used the native openvswitch firewall to implement SecusiryGroup. The
>> native OvS firewall seems to work just fine with TCP/UDP traffic but
>> it does not forward any SCTP traffic going to the VMs no matter how I
>> change the security groups, But it run if i disable port security
>> completely or use iptables_hybrid firewall driver. What do I have to
>> do to allow SCTP packets to reach the VMs?
> the security groups api is a whitelist model so all traffic is droped by default.
>
> if you want to allow sctp you would ihave to create an new security group rule with ip_protocol set to the protocol number for sctp.
>
> e.g.
> openstack security group rule create --protocol sctp ...
>
> im not sure if neutron support --dst-port for sctp but you can still filter on --remote-ip or --remote-group and can specify the rule as an --ingress or --egress rule as normal.
>
> https://docs.openstack.org/python-openstackclient/stein/cli/command-objects/security-group-rule.html
>
> based on this commit https://github.com/openstack/neutron/commit/f711ad78c5c0af44318c6234957590c91592b984
>
> it looks like neutron now validates the prot ranges for sctp impligying it support setting them so i gues its just a gap in the documentation.
>
>
>
>>
>
>