OpenWrt iptables Packet Limit [NFQUEUE]

Installing and Using OpenWrt
1

I have a GL-AR750S SLATE router running OpenWRT. I am trying to send all TCP packets on a specific port to a userspace application using iptables and netfilter queue. I set up a TCP socket between my local machine (connected wirelessly to the router) and a remote host, but after a certain number of packet transmissions, iptables stops capturing packets. When filtering packets into the userspace application I use the rules:

iptables -I FORWARD -p tcp --sport <port-num> -j NFQUEUE
iptables -I FORWARD -p tcp --dport <port-num> -j NFQUEUE

The userspace application prints each packet when it is received. When the number of packets equals 65 on the destination port and 66 on the source port, the application stops printing and stops receiving packets from iptables altogether. I changed the iptables target to simply ACCEPT the packets, and the problem still exists. After 131 packet transmissions in both directions combined (including ACKs and the initial connection), iptables stops counting packets for that connection. The rules I'm using to track these packets are:

iptables -I FORWARD -p tcp --sport <port-num> -j ACCEPT
iptables -I FORWARD -p tcp --dport <port-num> -j ACCEPT

With a basic TCP chat application, the rules will reach 65 packets and 66 packets respectively. The socket continues to work perfectly fine after iptables stops counting packets. A new socket connection will get captured by iptables for another 131 packets. The payload size and transmission rate don't change the outcome. Could this be an issue specific to OpenWRT or the kernel version on the router? The issue occurs with UDP packets as well, so I know it isn't an issue with the protocol. I replicated the setup on a Raspberry Pi and iptables on the Pi didn't have the issue - all packets were counted well into the thousands.

Why would iptables on OpenWRT have a packet limit?

1 Like
2

Do you use flow offloading? If so, try disabling it.

2 Likes
3

Thanks for the suggestion. Flow offloading is already disabled. Perhaps there is another setting that needs to be changed for this limit to go away.

1 Like
4

I'm actually having a similar problem. I've tried disabling things like kmod-ipt-offload and some other various settings. Flow offloading is disabled. Not hijaking just excited to see any other mention of this problem on the internet and ready to figure it out.

5

Are these rules part of a larger set where a previous "deterministic" one could be preventing your target ones being tested?

Have you inspected the tables using command line tools when it stops working to ensure the rules are still in place?

6

As far as I can tell, the iptables rules are still in place after it stops counting packets. A new socket connection will be tracked by the same iptables rule for 131 packets as well. I found a setting for Flow Offloading in the advanced settings of my router, but it was already disabled. When the TCP packets appear to be bypassing iptables, they aren't even found in the PREROUTING chain in the nat table. My latest hunch is that it has some sort of Flow Offloading feature built into the kernel that can't be disabled. The kernel version on my router is "Linux 4.14.221 mips". Also, I ran the TCP server on the router itself, and incoming/outgoing packets were on the INPUT/OUTPUT chains respectively, and 100% of those packets were counted by iptables - the issue only seems to exist on the FORWARD chain.