Modify

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#13652 closed defect (fixed)

firewall3: Inconsistent use of DROP chain in ip6tables

Reported by: anonymous Owned by: developers
Priority: low Milestone: Attitude Adjustment 12.09.1
Component: packages Version: Attitude Adjustment 12.09
Keywords: firewall3 ipv6 ip6tables Cc:

Description

This is not broken functionally, but just inconsistent use of DROP chains. The following zone traffic rules are in the firewall file:

config rule
        option name 'Drop v6 traffic'
        option src 'wan6'
        option ipset 'badgeo6'
        option proto 'all'
        option family 'ipv6'
        option target 'DROP'

config rule
        option name 'Drop v6 traffic'
        option src 'wan6'
        option dest 'lan'
        option ipset 'badgeo6'
        option proto 'all'
        option family 'ipv6'
        option target 'DROP'

I noticed that the "zone_wan6_input" rule DROPs traffic directly instead of sending it to "zone_wan6_src_DROP" chain:

-A zone_wan6_input -m set --match-set badgeo6 src -m comment --comment "Drop traffic" -j DROP
-A zone_wan6_forward -m set --match-set badgeo6 src -m comment --comment "Drop traffic" -j zone_lan_dest_DROP

Again this doesn't break functionality, just consistency on the ip6tables.

Attachments (0)

Change History (7)

comment:1 Changed 5 years ago by jow

This is/was actually intentional. Using zone_x_src_ACTION for input rules would introduce additional overhead since the -i ifname rules would need to get matched again which is unecessary as the traffic is already matched within zone_x_input. But for the sake of consistency I'll change it anyway since that also fixes logging for input rules of zones with option log 1.

comment:2 Changed 5 years ago by jow

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

Behaviour changed with r36854, r36855

comment:3 Changed 5 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

This new change seems to also send ACCEPT traffic to zone_wan_src_ACCEPT, zone_wan6_src_ACCEPT. Can you exclude ACCEPT traffic from that "zone_x_src_ACTION" option?

The zones "option log 1" logs only dropped or rejected traffic. Sending accepted traffic into a common chain serve no logging purposes and reduces iptables efficiency.

comment:4 Changed 5 years ago by jow

  • Resolution set to wontfix
  • Status changed from reopened to closed

No, I will not do that, as it complicate s the rule layout even further. Either I revert that change or I keep it the way it is now.

comment:5 Changed 5 years ago by anonymous

  • Resolution wontfix deleted
  • Status changed from closed to reopened

After reviewing more of this, I think the change for zone_x_src_ACTION makes accepted traffic more inefficient. Ingress v4 forwarded traffic is unaffected. But v4 input, and both v6's forward and input has to go through another chain and interface match.

Could you revert the change? So sorry for the trouble and sorry that I asked about the inconsistent DROP chains.

comment:6 Changed 5 years ago by jow

  • Resolution set to fixed
  • Status changed from reopened to closed

Reverted to the only behaviour except when target != ACCEPT *and* logging is enabled in the src zone, then it will use zone_name_src_ACTION (see http://nbd.name/gitweb.cgi?p=firewall3.git;a=commitdiff;h=aeba5741d7ed3b53fb4f1bb3679feb0fa526f4c6)

comment:7 Changed 5 years ago by anonymous

Thanks Jow!

Add Comment

Modify Ticket

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


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

 
Note: See TracTickets for help on using tickets.