Kyle Larose <kyle@xxxxxxxxxxxx> wrote: > On 10 September 2018 at 16:21, Kyle Larose <kyle@xxxxxxxxxxxx> wrote: > > So, 368982cd7d1b does indeed fix the problem I am facing. > > Sad news. This fixes the problem I was facing in my preliminary > testing, but now that I have moved on to a slightly more advanced > use-case, I'm running into it again. This time, I'm using a mark > within the NF_QUEUE handler + the NF_REPEAT return to ensure that > further rules after my NF_QUEUE handler are invoked. > > To be clear the rules now look like this: > > iptables -t nat -N sniffer > iptables -t nat -A sniffer -m mark --mark 1 -j RETURN > iptables -t nat -A sniffer -m conntrack --ctstate RELATED,ESTABLISHED -j RETURN > iptables -t nat -A sniffer -j NFQUEUE --queue-num 0 --queue-bypass > iptables -t nat -A OUTPUT -j sniffer > > With these rules in place, I am running into insert_failed conditions > in conntrack. If I remove the repeat, the problem goes away. So, > somehow repeat is exacerbating the problem. I thought that maybe it > was a timing issue, so I placed a 500ms sleep into my handler, but > that didn't seem to cause the drops -- everything got through fine. > > Sadly, even with 4.19-rc2, which has some newer patches related to the > nat races, I still run into the issue. I tried in both the mangle and > nat chains. I suspect this is fixed by commit ad18d7bf68a3da860ebb62a59c449804a6d237b4 netfilter: nfnetlink_queue: Solve the NFQUEUE/conntrack clash for NF_REPEAT
