Bug 1312626 - SCTP traffic cannot access from External network to instances (using floating IP)
Summary: SCTP traffic cannot access from External network to instances (using floating...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 8.0 (Liberty)
Assignee: Brian Haley
QA Contact: Toni Freger
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-02-28 06:40 UTC by Eran Kuris
Modified: 2022-08-09 14:21 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-08-24 20:35:03 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-8510 0 None None None 2022-08-09 14:21:31 UTC

Description Eran Kuris 2016-02-28 06:40:03 UTC
Description of problem:
When trying to send SCTP traffic from external network(outside cloud environment) to instance it does not work... 
According to RFC https://www.ietf.org/rfc/rfc3257.txt
There is kind of limitation with NAT:

SCTP Network Address Translators (NAT) issues [RFC2663]
When two endpoints are to setup an SCTP association and one (or both)
of them is behind a NAT (i.e., it does not have any publicly
available network addresses), the endpoint(s) behind the NAT should
consider one of the following options:

(1) When single homed sessions are to be used, no transport addresses
should be sent in the INIT or INIT ACK chunk(Refer to section 3.3 of
RFC2960 for chunk definitions).  This will force the endpoint that
receives this initiation message to use the source address in the IP
header as the only destination address for this association.  This
method can be used for a NAT, but any multi-homing configuration at
the endpoint that is behind the NAT will not be visible to its peer,
and thus not be taken advantage of.  See figure 1.



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.Install OSP 8 setup 
2.create vm with floating IP and create Security group that allow SCTP traffic
3.with netcat listen on instance for sctp traffic : 
$nc --sctp -l -p 60000 > test.txt

4. From your PC send with netcat sctp traffic: 
$echo hi > qux.txt
$cat qux.txt 
$nc --sctp 10.10.10.13 60000 < qux.txt

traffic blocked even when rule exists in IPtables.

Actual results:


Expected results:
traffic should pass to VM

Additional info:

Comment 2 Jakub Libosvar 2016-02-28 15:15:52 UTC
(In reply to Eran Kuris from comment #0)
> 
> traffic blocked even when rule exists in IPtables.
> 
This is misleading. Traffic is not blocked as packets don't even reach qr- device in router namespace and thus packets don't even reach point where filtering is applied. SCTP filtering in security groups work when using both endpoints in private network. The issue is that NAT rule in router namespace is not applied on SCTP traffic.

Comment 3 David Lake 2016-05-24 21:12:50 UTC
I am currently hitting this bug in trying to deploy a vEPC solution on OpenStack Liberty.

S1-MME uses SCTP to communicate to the S-GW in the EPC and no traffic currently reaches the S-GW.

Is there any way to manually add the NAT rule for SCTP traffic until this is fixed ?

Thanks

David

Comment 4 Brian Haley 2017-06-12 14:04:26 UTC
There is an SCTP NAT module in Linux that might need to be loaded for this.  Can you try loading the nf_nat_proto_sctp module on the network node hosting this router (or all nodes if that's easier) and see if that helps?  Thanks.

Comment 11 Mosaic 2017-08-24 17:20:41 UTC
Hello everyone,

I recently installed Openstack Ocata and i'm also having the same problem as Eran Kuris posted above, unfortunately, I could not see how he managed to resolve the problem. Can anyone or perhaps Eran or Assaf help with his solution? Thanks in advance.

Comment 12 Assaf Muller 2017-08-24 17:42:39 UTC
(In reply to Mosaic from comment #11)
> Hello everyone,
> 
> I recently installed Openstack Ocata and i'm also having the same problem as
> Eran Kuris posted above, unfortunately, I could not see how he managed to
> resolve the problem. Can anyone or perhaps Eran or Assaf help with his
> solution? Thanks in advance.

The SCTP conntrack kernel module is compiled directly into the kernel in RHEL 7.4, so you shouldn't hit this issue.

Comment 13 Mosaic 2017-08-24 19:50:56 UTC
Thanks for the prompt reply but I'm not sure the kernel module is the cause of the problem because I loaded the sctp kernel module by first installing the conntrack-tools and by running:

sudo modprobe nf_conntrack_proto_sctp 

and checked if sctp was actually loaded by running:

lsmod | grep sctp which returns sctp as a loaded module.

Or should I have done more than this?

Comment 14 Assaf Muller 2017-08-24 20:24:48 UTC
You need nf_nat_proto_sctp.

Comment 17 Brian Haley 2018-06-27 13:23:57 UTC
Hi Rohit, with later kernels that module is built-in and modprobe will give an error.  What about module nf_nat_proto_sctp, is that loaded?

Comment 18 Assaf Muller 2018-06-27 13:43:27 UTC
Please see comment 17.

Comment 20 rohit londhe 2018-07-04 06:03:49 UTC
(In reply to Brian Haley from comment #17)
> Hi Rohit, with later kernels that module is built-in and modprobe will give
> an error.  What about module nf_nat_proto_sctp, is that loaded?

[root@overcloud-compute-1 ~]# sudo modprobe nf_nat_proto_sctp
modprobe: FATAL: Module nf_nat_proto_sctp not found.

Comment 22 Brian Haley 2018-07-09 16:13:31 UTC
I will have to get a rhel 7.4 system up and running to see if I can figure out what modules you might need to load.

Or do you have a 7.4 + OSP8 environment setup where I can login and look around?

Comment 23 Brian Haley 2018-07-09 22:08:48 UTC
I booted a 7.4 VM today and added an iptables SCTP rule using 'iptables -A -p sctp -m sctp --dport 12345'.  The only extra module it loaded was xt_sctp.  I verified in /boot/config* that the NAT and NFILTER SCTP options were =y, so everything else should be built-into the kernel.

Can you sent the output of 'lsmod | grep sctp' from the compute node in question?  Also, the output of 'iptables-save -c' which should show the rules, etc.  I'm just not sure if you're seeing a different issue.

Comment 24 rohit londhe 2018-07-10 10:06:58 UTC
(In reply to Brian Haley from comment #23)
> I booted a 7.4 VM today and added an iptables SCTP rule using 'iptables -A
> -p sctp -m sctp --dport 12345'.  The only extra module it loaded was
> xt_sctp.  I verified in /boot/config* that the NAT and NFILTER SCTP options
> were =y, so everything else should be built-into the kernel.
> 
> Can you sent the output of 'lsmod | grep sctp' from the compute node in
> question?  Also, the output of 'iptables-save -c' which should show the
> rules, etc.  I'm just not sure if you're seeing a different issue.

[root@overcloud-ovscompute-21 ~]# lsmod | grep sctp
sctp_diag              12845  0
sctp                  270556  5 sctp_diag
inet_diag              18949  4 tcp_diag,dccp_diag,sctp_diag,udp_diag
libcrc32c              12644  5 xfs,sctp,openvswitch,nf_nat,nf_conntrack

Comment 26 Brian Haley 2018-07-10 16:34:06 UTC
So in that iptables-save output I do see an SCTP rule allowing all traffic:

[590387:30700124] -A neutron-openvswi-i703f7eac-0 -p sctp -j RETURN

And the numbers within the brackets indicate there have been packets allowed into the tap device for the instance.  If they are sending SCTP packets and you see those increase, then the security group code has allowed them, the only other place to check would be inside the instance itself to know why they are being dropped there.

Comment 27 Brian Haley 2018-07-31 19:41:22 UTC
Sorry, should have tagged the last one as needinfo - is there anything inside the instance dropping these SCTP packets?

Comment 28 rohit londhe 2018-08-06 10:16:40 UTC
We have asked to reproduce it again, after which we can check at an instance level specifically.


Note You need to log in before you can comment on or make changes to this bug.