Recommended firewall settings

If you pull up Network>Firewall what are the recommended settings for "General" and "Zones?"

Upon reading google hits, many are showing a "Lan -> wan" setting of "reject" for forward whereas the out-of-the-box settings have that set to "accept" including this OpenWRT wiki.


First of all, that isn't a LAN to WAN setting of Reject. The enable LAN to WAN is the graphic to the Left of that - under the column "Zone => Forwardings". That entire row is the Zone-based firewall settings for LAN. Each row configures the Zone named on its extreme Left. I believe LAN was accept intra-zone forwarding by default (more on how to find out below).

Nonetheless, what you circled is the forwarding of a packet FROM THE LEDE TO ANOTHER ROUTER IN THE SAME ZONE. Most consumers don't use 2 routers in the same firewall zone (unless one is doing NAT).


To get your answer, simply backup the config, erase the router and see the setting. I honestly don't have a device in default configuration to check for you. From a device that I don't beleive I had to reconfigure, LAN is: Input (from LAN to router) accept, Output (from router LAN IP) accept and Forward (to other subnets in zone) accept.


As usual, thank you for the prompt an accurate info, lleachii. I did read the firewall article, but did not understand all of it. I can verify that the default is in fact captured in the image above.

It took me a long time to understand Zone-based firewalls, as I only experienced them in LEDE.

  • Recall that all firewall locations are determined by zones
  • Anything that doesn't fall in one of the listed and defined zones will be covered by the General Zone Setting
  • The first things on the GUI to define is where the Zone can forward to by default (i.e. LAN => WAN)
  • You then define rules for the zone:
    • Input to router from Zone LAN
    • Output from router on Zone LAN
    • Forwarding from this zone to a router in same zone
  • Masquerade (use router assigned IP when sending traffic out this interface)
  • MSS Clamping - (Google is your friend on this one, lol)
  • Lastly, if you need to make a rule that doesn't follow the pattern (i.e. WAN IP to HTTP server in LAN), you make a Port Forward or Traffic Rule

The information in the firewall Wiki is quite dense, but extremely informative.

Hope this helps.


Thanks for the very nice summary. Loving LEDE so far :fist:t3:

Not sure what to believe. As far as I know, the circled option is for determining if traffic is forwarded between different subnets inside this firewall zone.

That is, I had a separate wireless and wired subnets, but both inside the firewall zone called LAN. They could not talk to each other by default until I chose "accept" there.

And whatever is the case, the GUI could use some clear and simple verbiage.

Just forward!
No, forward.
From where?

It is a chain.
What chain?
A chain.
But where does it start from? Where does it end?

I mean, the installed base is most probably divided into three camps: Those 1) who know nothing about the settings and leave them as they are, those 2) who suffer under a misconception or many and wonder why changing settings has unexpected or inexplicable results and 3) the very small minority who have tried every combination and figured out what does what and what goes where and 4) the even smaller minority that somehow knows the theory behind the firewall and really knows how one forward is different from another forward.


I have to get off-topic to say that Google isn't anybody's friend (other then big data and big data affiliates).


Wiki is explaining it quite well in my opinion.


Thinkcat those were actually 4 xD

I saw no explanation there that would have answered my question. I don't know about the original poster's question, but I see there are answers to it that even add to the confusion. For example:

A zone consists of interfaces. And interfaces are a property of a particular device. As far as I know, a single router running OpenWRT knows nothing about what any other device thinks about its interfaces and how it groups these into zones.

I have played with routing protocols and zone-based firewalls in Cisco devices. But that's why I know these things aren't always inevitably related. No matter what Gertrude Stein says, zone is not a zone is not a zone.

So forget the other router. These things are not alive. They don't recognize each other and make friends. For that you would need to run a routing protocol (RIP, OSPF, IS-IS, EIGRP, BGP) and even then the firewall would deal with interfaces. One must think about it in a way where the interface is first defined by you to be a door to a certain subnet, which you can then define to be part of a zone. Then you here have added the interface to a zone according to your previous definition.

The algorithm, as far as I know, works like this:

  • A packet comes in. Does it come in from an interface that is part of a zone?
    • It does: Consult the row dedicated to that particular zone.
      • Is the packet adressed to the router? If it is, then consult the Input selection on that particular row.
      • Is it going to another subnet—that is, out through another interface—that is included in the same zone? If so, consult the red, circled number 3.
      • Is it going to another zone—that is, out through another interface—that is included in some other zone? If so, see if the destination zone is mentioned in the Forwardings column of that particular zone, that is, next to the red, circled number 2.
    • It does not:
      • Is it addressed to the router? If it is, then consult the general Input selector near and above the red circled 1.
      • Is it going somewhere else than the router? Consult the Forward selector next to the red circled 1.

I think the setting at 1 sets the default policy for each chain. (Input, Output, Forward)

man iptables:

-P, --policy chain target

Set the policy for the chain to the given target. See the section TARGETS for the legal targets. Only built-in (non-user-defined) chains can have policies, and neither built-in nor user-defined chains can be policy targets.

When a packet hits/traverses through one of the chains listened above and hits the end of the chain (because no rule (with a target) was applied) , the default policy is applied/used.

This default policy can be overwritten with the zone settings below. (at 3)
Input = Traffic to the router
Output = Traffic originating from the router
Forward = Traffic between interfaces that are members in the same zone.
For example, you configure two interfaces on your router with different subnets but you assign both interfaces to the same zone:
If you set "Forward" (at 3) to "Accept", traffic between the interfaces/subnets can flow, but if you set it to Reject/Drop, no traffic will be flowing between the interfaces/subnets.

Your assumptions are correct and, as I said, are explained quite well in the wiki:

The defaults section declares global firewall settings which do not belong to specific zones:

|input |string |no |REJECT |Set policy for the INPUT chain of the filter table.|
|forward |string |no |REJECT |Set policy for the FORWARD chain of the filter table.|
|output |string |no |REJECT |Set policy for the OUTPUT chain of the filter table.|

A zone section groups one or more interfaces and serves as a source or destination for forwardings , rules and redirects .

  • INPUT rules for a zone describe what happens to traffic trying to reach the router itself through an interface in that zone.

  • OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone.

  • FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone.

The forwarding sections control the traffic flow between zones , and may enable MSS clamping for specific directions.

I've personally unticked MSS Clamping in the gui (since PMTU is unreliable) and added the following to /etc/firewall.user

**iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460**
**ip6tables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1440**

If you do not mind me asking, why 1460?

A mtu of 1500 is majority standard for soho appliances and the internet as a whole...
mtu 1500 bytes
ipv4 header 20 bytes
(ipv6 header 40 bytes)
tcp 20 bytes

1500-20-20=1460 ipv4
1500-40-20=1440 ipv6

Thx, so PPPoE would be 1452 then...

No it's usually 1492.

Which happens to be 1452 + 20 + 20

I still don't understand why he wants to chop (clamp) off these's already under 1500 on the real Internet...

...unless he blocks receipt of ICMP - Fragmentation Needed packets.

This is a good reference as to why you would statically set the MSS on the host or source requester

1 Like

Just as I thought:

Even if the path MTU (which detects the correct MTU across the path) is enabled on the host, sessions may be dropped because system administrators sometimes disable the ICMP error messages that must be relayed from the host in order for path MTU to work.