OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Dries - 13.04.2020

FS#3005 - iptables ruleset order improvement option

Supply the following if possible:
- Device problem occurs on
TP-Link Archer C7 v5
- Software versions of OpenWrt/LEDE release, packages, etc.
19.07.2, just default packages
- Steps to reproduce
Current iptable ordering is badly pessimal (this repeats 3x, so 3 states get set for each connection, but thats for other news)
-A FORWARD -m comment –comment “!fw3: Custom forwarding rule chain” -j forwarding_rule
-A FORWARD -m conntrack –ctstate RELATED,ESTABLISHED -m comment –comment “!fw3” -j ACCEPT
-A FORWARD -m conntrack –ctstate INVALID -m comment –comment “!fw3” -j DROP
following does same job but does significantly less processing for typical case of in-state packets
-A FORWARD -m conntrack –ctstate RELATED,ESTABLISHED -m comment –comment “!fw3” -j ACCEPT
-A FORWARD -m conntrack –ctstate INVALID -m comment –comment “!fw3” -j DROP
-A FORWARD -m comment –comment “!fw3: Custom forwarding rule chain” -j forwarding_rule
Not willing to generalize, but my wifi and wire behind could not reach subscription 100Mbps in any way before the change, after change it is steady 100Mbps both ways.

Jo-Philipp Wich commented on 13.04.2020 17:04

This will change the behavior of the `forwarding_rule` user chain since it will not see all packets anymore.

Dries commented on 13.04.2020 17:38

It will no more see packets that apply to established states. Those are accepted already, thy wont make a state, (not) dropping packets midst connection is your concern?

Dries commented on 13.04.2020 17:41

There is (unused) RAW table for stuff in single-packet context.

Dries commented on 13.04.2020 17:57

note that same applies to input/output chains.

Jo-Philipp Wich commented on 13.04.2020 18:02

Traffic count rules come to mind.

Dries commented on 13.04.2020 18:04

Actually forwarding is IP - Layer 3 thing, so TCP/UDP states should not even apply there, they are sort of well with NAT. States are kind of fun , track states, lots of them, but in the end nothing more than counting state vs new state above unnecessary processing happens behind the scenes.

Dries commented on 13.04.2020 18:27
Traffic count rules come to mind.

They count on the interface first
then iptables -L -v

probably one needs to sum all rules already instead of ripping number of the exactly second one for proper result?

Dries commented on 13.04.2020 18:41

Relevant part from ubuntu UFW, before any user hook enters (they can prepend a rule same as OpenWRT)

-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT

They sort of have by magnitude more memory bandwidth to copy packets and cpu power to stroll state trees.

Dries commented on 14.04.2020 02:04

The ultimate request is to sort rules in a logical in 6 places (in/out/fw ip4/ip6) where they exit fw3 generator. There is no way around it to put sense into existing configuration except for user script prepending complete override for all generated ruleset. It should not work that bad out of the box.

Other things catching the eye:

  1. TCPMSS does not need mtcp–syn filter upfront, it picks interesting packets on its own
  2. raw tables, even empty could allow space for stateless part of bcp38 input
  3. the backward-incompatible change request to make forward table stateless
Dries commented on 14.04.2020 20:00

As looking from wat luci extensions can be installed most hook into NAT table, connmark and stuff, so indifferent if forward keeps state on top of leak blocks.

noddos prepends filter forward rule - no interference
bcp38, banip matches cstate NEW checking every packet, they certainly should go after, existing states will never match new, especially on every packet.

raw table is extra module, probably not worth integrating

out of fear of breaking something, i will happily jump to snapshot f it goes better for my simple setup.


Available keyboard shortcuts


Task Details

Task Editing