Openwrt firewall docs updated


I think this is the forum for the wiki, rather than the developer listserve....

I have finished the first cut at editting the firewall wiki docs. Per Albert, I put everything under inbox:firewall. I cleaned out a good deal of old configurations, suspicious logic and nonsensical placeholders. I added improved sections for simple configurations, vlans and ipset rules.

I tested as many configurations as possible using the network topology diagrammed in one of the sections. I need to update the diagram to add vlans but I do not have write permission to media manager.

Many links reference inbox:firewall.. docs, which will need to be editted if moving to the main wiki area.

Dave Turvene


You do. Go to the "media" namespace before doing anything else.

That happens automatically when pages are moved. No extra work.


What will require (some) work is fixing the links pointing to the old firewall docs that will be removed.

As per the discussion in the mailing list, he rewrote the core firewall docs, so what is in will be replacing the current Firewall section/namespace whole. Apart from the articles about upnp afaik, that will remain original.

This weekend I'll do the swap and link fixing. It's not a whole lot, most links point to the main Firewall page or a few others, I can batch-edit them.


Thanks! I added the new image into the media directory....


Sounds good! I'll edit some more of the firewall stuff after cut-over.

Yeah, I looked into upnp documentation. Two problems with it:

  1. I don't have the hardware to test it and,
  2. The 18.06 firewall3 does not support the documentation. For example, to enable PNP, the documentation has a configuration section to set "option enable_natpmp 1" (sic). This option appears nowhere in the 18.06 code base. Same with a number of PNP options.

In otherwords, someone would have to update the firewall3 code and possibly re-package the release to support this documentation section.


Perhaps worthwhile discussing that the firewall can be manually configured with iptables, and that nftables can be installed with kernel modules. (Though I haven't been able to "rid" OpenWrt of iptables completely yet). Any such mention should, in my opinion, include "expert users only" and "no GUI" warnings.


Good suggestions. There's a whole new set of sections on using/debugging native netfilter ("iptables") rules. I prefer adding them to the /etc/firewall.user file loaded by the firewall3 app but they can also be added to a start script (e.g. /etc/rc.local). I'll add an "expert user only" warning in the netfilter section(s).

I copied the old nftables section. In order to use nftables the kernel needs to be custom built with the right CONFIGs and a lot of new kmods need to be included, add at least one new package (nft), and it is not compatible with the firewall3 app. I did not attempt anything with it and don't intend to.



I agree not worth dealing with the specifics of nftables.

I may take a stab at it (much) later on once I can get rid of



Ok, I've moved over the articles.

I don't know where I should connect the following link:
which sends to this (which is now broken as I moved stuff over)

that is this paragraph

Notes on connection tracking

:!: This is now obsolete since fw3 version 2016-11-29 by this commit

By default, the firewall will disable connection tracking for a zone if no masquerading is enabled. This is achieved by generating NOTRACK firewall rules matching all traffic passing via interfaces referenced by the firewall zone. The purpose of NOTRACK is to speed up routing and save memory by circumventing resource intensive connection tracking in cases where it is not needed. You can check if connection tracking is disabled by issuing iptables -t raw -vnL, it will list all rules, check for NOTRACK target.

:!: NOTRACK will render certain ipables extensions unusable, for example the MASQUERADE target or the state match will not work!

If connection tracking is required, for example by custom rules in /etc/firewall.user, the conntrack option must be enabled in the corresponding zone to disable NOTRACK. It should appear as option conntrack 1 in the right zone in /etc/config/firewall. For further information see .

Stuff like mwan3 and umurmur say it's important, can you please advise or do the edit yourself about this?


I also moved and modified a little the name and title of the landing pages of your new Firewall section so we don't break all external links pointing to what was the main firewall article.


Good question....

I looked at the firewall3 code and applications. The point of the notes_on_connection_tracking section is to disable netfilter connection tracking to improve performance.

I don't think it is useful anymore. The section uses the firewall3 conntrack and no_track options, which were removed. Also, no_track pertains to the netfilter raw table, which is not currently included in the standard builds (needing kmod-ipt-raw), so a special kernel is necessary. I have no problem with documenting "special" netfilter caps. In fact, I added an example of using ipset, which also is not included by default but is an important netfilter function for firewalling public servers.

The mwan3 application requires conntrack to be enabled. It looks like you removed the conntrack reference in umurmur application but I suspect it needs conntrack to be enabled also.

So, I think that section can be removed because conntrack is enabled if masquerading is on and cannot subsequently be disabled.

I have a couple outstanding edits to do to the firewall pages. including a conntrack debugging section in the netfilter NAT page. I will add documentation on when conntrack is/is not used.



ok thanks, removed that paragraph as obsolete. :grinning:


I've just noticed this thread - I started another thread on the developers forum!

Anyway I've updated the page on nftables, as they can be used for people comfortable with the command line.

I've written it emphasising the "c" style of code - as to me this is the best part of nftables - it makes firewalls far more readable.

Anyway if anyone has any comments, either good or bad - let me know, and I'll see if we can accommodate ...