Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#17690 closed defect (not_a_bug)

Iptables conntrack bug -- no mach for --ctstate RELATED,ESTABLISHED rule

Reported by: morfik Owned by: developers
Priority: high Milestone:
Component: base system Version: Barrier Breaker 14.07
Keywords: iptables, conntrack Cc:


The problem concerns:
BARRIER BREAKER (14.07-rc3, r42056)
CHAOS CALMER (Bleeding Edge, r42273)

at least the two were tested.

This is my router: TP-Link TL-WR1043N/ND v2

When I log via ssh and check the output of the following command:

iptables -nvL -t filter | grep -i established

I should get three lines that can show me packet counter of established,related rule in each main chain -- FORWARD,INPUT,OUTPUT. But unfortunately the counters point 0, which is weird because the communication should stop without hitting these rules.

Let's focus just on the FORWARD chain. I deleted the one default rule via:

iptables -D FORWARD 1

and as can be expected, the packet forwarding doesn't work anymore. So I added the two following rules:

iptables -t filter -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A FORWARD -i br-lan -s -m conntrack --ctstate NEW -j ACCEPT

Forwarding works. I downloaded 8MiB file to see if both rules work, but:

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *              ctstate RELATED,ESTABLISHED
   10   600 ACCEPT     all  --  br-lan *            ctstate NEW

There's no match for the first rule. As you can see, there's some packets in the rule that matches state NEW, but just only few, and 600bytes != 8MiB.

The next thing I wanted to check was removing the first rule (maybe it's just a visual bug) and see what happens -- forwarding of packets works without a problem. That's ... nice. :)

What rule do the packets hit? There's only one in the FORWARD chain, and most of the packets don't increase that counter. Besides, there's ctstate NEW only. As you can see, the counter of the FORWARD chain also points 0, but the packets go through despite the default policy of the FORWARD chain, which is DROP.

How do the packets go through the filter, and how's that even possible?

Attachments (0)

Change History (12)

comment:1 Changed 3 years ago by nbd

From /etc/sysctl.conf:

Change it to 0, run sysctl -p and see if your rule gets called again.

comment:2 Changed 3 years ago by anonymous

maybe related to
please also paste "iptables -t raw -vnL" output

comment:3 Changed 3 years ago by morfik

The net.netfilter.nf_conntrack_skip_filter parameter should be set to 0 , and that solves the problem.

Last edited 3 years ago by morfik (previous) (diff)

comment:4 Changed 3 years ago by nbd

  • Resolution set to not_a_bug
  • Status changed from new to closed

comment:5 Changed 3 years ago by anonymous

What does net.netfilter.nf_conntrack_skip_filter do? Should it be 0, or 1 by default?

comment:6 Changed 3 years ago by nbd

1 is the default because most people don't need explicit processing of these rules, and it helps with network performance.
0 should only be used if needed.

comment:7 Changed 3 years ago by morfik

Is there any documentation on this parameter? I searched for nf_conntrack_skip_filter, but google gave me just 4 entries, and there's no useful info there.

comment:8 Changed 3 years ago by nbd

no, it was only added recently

comment:9 Changed 3 years ago by anonymous

When is it needed? What are examples for where it should be set to 0? I am using OpenVPN for example on my router, which worked great until now, but I always wasnt sure, if my firewall rules were perfectly correct, for example this line always bugged me:

iptables -A forwarding_rule -i br-lan -o tun+ -j ACCEPT

Doesnt it mean anything from the tun devices is allowd in to my network, and the VPN hoster theoretically can hack inside my router if he wanted to? Ive tried something like this for example:

iptables -A FORWARD -i br-lan -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

That, in my logic, only connections my network already initiated were allowed, but it never worked. Is this where I have to set it to 0?

comment:10 Changed 3 years ago by nbd

you would only need it if you either need the counters for the rules to work, or if you somehow need to treat packets of an already established connection differently from when they were processed the first time in NEW state.

my guess is you probably don't need it for what you're doing

comment:11 Changed 3 years ago by anonymous

This defiantly needs documentation. as it confused the hell out of me as well. the pros and cons of enabling and disabling this rather very unique functionality should also be identified and listed.

comment:12 Changed 3 years ago by Vortify12

I tried to add some basic details about this. Please take a look and correct it if it's required:

Add Comment

Modify Ticket

as closed .
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.