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:
(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 ? Thanks David
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.
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.
(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.
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?
Please see comment 17.
(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.
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?
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.
(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
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.
Sorry, should have tagged the last one as needinfo - is there anything inside the instance dropping these SCTP packets?
We have asked to reproduce it again, after which we can check at an instance level specifically.