search for: aojea

...y accept; ct state new queue to 100 } } and in userspace I process the packet to emit a verdict. Everything works fine with TCP and UDP, but when using SCTP I can see the packet its modified and breaks the establishment of the connection, more details in https://github.com/aojea/kube-netpol/issues/8 Once I remove the `nfqueue` rule the SCTP connection is established correctly. I triple checked the userspace program accepts the packet and removing the nfqueue rules makes the connection work. I've added a trace (by the way kudos for the tracing functionality is really...

...3:Port3, and this connection has source port Port1, the connection can not be established, because the incoming packet is not de-natted The bug was originally reported in Kubernetes: https://github.com/kubernetes/kubernetes/issues/90258 but I was able to reproduce it here: https://gist.github.com/aojea/4ffb520db9f72de21685294d8fec7f33 -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200521/e3bbbd34/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1766 Bug ID: 1766 Summary: nfqueue randomly drops packets with same tuple Product: netfilter/iptables Version: unspecified Hardware: x86_64 OS: All Status: NEW Severity: major Priority: P5 Component: netfilter hooks Assignee: