Opened 6 years ago

Closed 5 years ago

Last modified 4 years ago

#11453 closed defect (fixed)

Firewall chains setup "accept-within-zone" leaks out packets to other zones

Reported by: mats.hansson@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:


Assuming following setup:
Two zones: "lan" and "wan",
"lan" has two networks.
Really tight firewall i.e. no forwardings from lan to wan (ports opened individually as needed).
Now accept forwarding between networks within "lan" (implying choosing the "accept" for "Forwarding" for zone "lan"), i.e. one wants to route freely between local interfaces/networks.

In this scenario packets are "leaking" from "lan" to "wan" which is NOT the desired behaviour.
The problem is in the "zone_lan_ACCEPT" chain: This has two rules, one tests for incoming interface and one tests the outgoing interface (having wildcards for the not-tested). Instead, it should only test for outgoing interface. Otherwise, it accidentally gets a match in the scenario above: the incoming interface will always match, since it has already been tested in the chain named "forward", and is passed on to the zone_lan_forward, which passes it on to zone_lan_ACCEPT.

The cure, to get it really general, is to have two separate chains instead of a common zone_lan_ACCEPT etc.: one matching only incoming interface and one matching the outgoing interface. So for "lan" we will have:
zone_lan_SRC_ACCEPT (testing in:...)
zone_lan_DST_ACCEPT (testing out:...)
zone_lan_SRC_DROP (testing in:...)
zone_lan_DST_DROP (testing out:...)
zone_lan_SRC_REJECT (testing in:...)
zone_lan_DST_REJECT (testing out:...)
With this solution, the ..._SRC_... targets should be used in the input chains only, the ..._DST_... targets being used in the output chains and the forward chains. Only then can there be a real, functional separation between what is forwarded within a zone and what is forwarded out from it. I.e. essentially what is described on the LuCI page "Firewall - Zone Settings" in the section header.

There is a reasonably easy implementation for this change, one can keep the current names zone_lan_ACCEPT etc, and let them stand for the ..._DST_... chains, and introduce only three new ..._SRC_... chains for each zone.
In script

fw add $mode f ${chain}_SRC_ACCEPT
fw add $mode f ${chain}_SRC_DROP
fw add $mode f ${chain}_SRC_REJECT


fw add $mode f ${chain} ${chain}_${zone_input} $


fw add $mode f ${chain} ${chain}_SRC_${zone_input} $

In script

fw $action $mode f ${chain}_ACCEPT ACCEPT $ { -i "$ifname" $inet }
fw $action $mode f ${chain}_DROP DROP $ { -i "$ifname" $inet }
fw $action $mode f ${chain}_REJECT reject $ { -i "$ifname" $inet }


fw $action $mode f ${chain}_SRC_ACCEPT ACCEPT $ { -i "$ifname" $inet }
fw $action $mode f ${chain}_SRC_DROP DROP $ { -i "$ifname" $inet }
fw $action $mode f ${chain}_SRC_REJECT reject $ { -i "$ifname" $inet }

This was tested on Backfire 10.03.1 version, but I have checked with the trunk code today, and the scripts are in practice unchanged with respect to this problem.


Attachments (0)

Change History (2)

comment:1 Changed 5 years ago by jow

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

Should be fixed with r35484.

comment:2 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

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.