Bug 1312626
Summary: | SCTP traffic cannot access from External network to instances (using floating IP) | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Eran Kuris <ekuris> |
Component: | openstack-neutron | Assignee: | Brian Haley <bhaley> |
Status: | CLOSED WORKSFORME | QA Contact: | Toni Freger <tfreger> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 8.0 (Liberty) | CC: | amuller, bhaley, chrisw, d.lake, ekuris, ibrahim1.afolabi, jlibosva, jmelvin, kiyyappa, nyechiel, ragiman, rlondhe, srevivo, vcojot |
Target Milestone: | --- | Keywords: | Reopened, ZStream |
Target Release: | 8.0 (Liberty) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-08-24 20:35:03 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Eran Kuris
2016-02-28 06:40:03 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. 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. |