Red Hat Bugzilla – Bug 1312626
SCTP traffic cannot access from External network to instances (using floating IP)
Last modified: 2017-08-24 16:24:48 EDT
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):
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
$nc --sctp 10.10.10.13 60000 < qux.txt
traffic blocked even when rule exists in IPtables.
traffic should pass to VM
(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.
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 ?
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.
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.
(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.
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?
You need nf_nat_proto_sctp.