Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3005 - iptables ruleset order improvement option #7767

Open
openwrt-bot opened this issue Apr 13, 2020 · 10 comments
Open

FS#3005 - iptables ruleset order improvement option #7767

openwrt-bot opened this issue Apr 13, 2020 · 10 comments
Labels

Comments

@openwrt-bot
Copy link

veld_muis:

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.

@openwrt-bot
Copy link
Author

jow-:

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

@openwrt-bot
Copy link
Author

veld_muis:

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?

@openwrt-bot
Copy link
Author

veld_muis:

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

@openwrt-bot
Copy link
Author

veld_muis:

note that same applies to input/output chains.

@openwrt-bot
Copy link
Author

jow-:

Traffic count rules come to mind.

@openwrt-bot
Copy link
Author

veld_muis:

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.

@openwrt-bot
Copy link
Author

veld_muis:

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?

@openwrt-bot
Copy link
Author

veld_muis:

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.

@openwrt-bot
Copy link
Author

veld_muis:

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:

  • TCPMSS does not need mtcp--syn filter upfront, it picks interesting packets on its own
  • raw tables, even empty could allow space for stateless part of bcp38 input
  • the backward-incompatible change request to make forward table stateless

@openwrt-bot
Copy link
Author

veld_muis:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant