Hello,

I would like to know how to add an entry in the firewall in the latest openwrt build. In Kamikaze 7.09, the file /etc/firewall.user was easy to use but now, I noticed a new file in /etc/config/firewall which seems to be different. It looks like a file in /etc/init.d/firewall/uci_firewall.sh parse the file /etc/config/firewall so it is easier for new users to customize their rules BUT I prefer to use the old way with iptables command. What I don't understand are the way chain are made, etc... Anyone could explain to me so I can understand better?

THank you

Example for the new UCI firewall to allow port 22/TCP to the router. The example below uses the UCI CLI you can do the same with the LuCI UI (Network > Firewall > Custom Rules).

> uci add firewall rule
> uci set firewall.@rule[-1].src=wan
> uci set firewall.@rule[-1].target=ACCEPT
> uci set firewall.@rule[-1].proto=tcp
> uci set firewall.@rule[-1].dest_port=22
> uci commit firewall

> /etc/init.d/firewall restart

To delete that rule do:

> uci del firewall.@rule[-1]
> uci commit firewall

> /etc/init.d/firewall restart

The index @rule[-1] adds or removes the last section in the config file.

(Last edited by Yanira on 31 Aug 2008, 19:48)

ok but I want to use iptables to use more parameters like: Destination IP, Destination port, Source IP, Source Port, mac module, etc....

Look here: https://dev.openwrt.org/cgi-bin/trac.fc … config#L55

# include a file with users custom iptables rules
#config include
#    option path /etc/firewall.user


### FULL CONFIG SECTIONS
#config rule
#    option src        lan
#    option src_ip    192.168.45.2
#    option src_mac    00:11:22:33:44:55
#    option src_port    80
#    option dest        wan
#    option dest_ip    194.25.2.129
#    option dest_port    120
#    option proto    tcp
#    option target    REJECT 

#config redirect
#    option src        lan
#    option src_ip    192.168.45.2
#    option src_mac    00:11:22:33:44:55
#    option src_port        1024
#    option src_dport    80
#    option dest_ip    194.25.2.129
#    option dest_port    120

The following doesn't seem to work (in /etc/config/firewall):

config rule
        option dest wan
        option proto tcp
        option src_ip 192.168.1.206
        option target REJECT

however, it doesn't block this ip from getting onto the internet. I also tried by mac, and opt src lan (instead of dest wan), and with quotes - doesn't make any difference

before I had the rule that worked:
iptables -A input_rule -s 192.168.1.206 -j REJECT

(Last edited by ymhee_bcex on 12 Sep 2008, 07:39)

Like the OP, I'd prefer to use my own /etc/firewall.user.

'config include' does indeed pull in the firewall.user script, but I've found the custom chains (input_rule, output_rule, etc) are effectively ignored: the "zone" policy (ACCEPT/REJECT) gets enacted before the custom chains get called.

e.g. here's my config:

config defaults
    option syn_flood    1
    option input        ACCEPT
    option output        ACCEPT 
    option forward        REJECT

config zone
    option name        lan
    option input    ACCEPT 
    option output    ACCEPT 
    option forward    REJECT

config zone
    option name        wan
    option input    REJECT
    option output    ACCEPT 
    option forward    REJECT
    option masq        1 
    
config include
    option path /etc/firewall.user

here's an extract of the result, following the forward chain (observe that the custom chain, 'forwarding_rule', is after the zone 'forward'):

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  ... 
    3   188 TCPMSS     tcp  --  ... 
   91 33900 ACCEPT     all  --  ... 
   23  1232 forward    all  --  any    any     anywhere             anywhere            
    0     0 forwarding_rule  all  --  any    any     anywhere             anywhere            
    0     0 reject     all  --  any    any     anywhere             anywhere            

Chain forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   23  1232 zone_lan_forward  all  --  eth0.1 any     anywhere             anywhere            
    0     0 zone_wan_forward  all  --  ppp0   any     anywhere             anywhere           

** And here's the problem:
Chain zone_lan_forward (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   23  1232 forwarding_lan  all  --  any    any     anywhere             anywhere            
    0     0 zone_lan_REJECT  all  --  any    any     anywhere             anywhere

So my custom chain will never get hit - zone_lan_REJECT terminates the chain. Of course, if I swap the zone policy from REJECT to PERMIT, it doesn't change anything - the chain still terminates. What I need is to be able to simply omit the desired chains altogether. I tried just leaving out the "options" I don't want (e.g. forward) but that raises errors in the firewall script.

I can't see an obvious way to do this, so I've simply patched uci_firewall.sh to include the custom chains before the zone ones:

--- /rom/lib/firewall/uci_firewall.sh    Sun Oct  5 23:45:32 2008
+++ /lib/firewall/uci_firewall.sh    Thu Oct  9 21:31:04 2008
@@ -162,6 +162,9 @@
     $IPTABLES -N output
     $IPTABLES -N forward
 
+    echo "Adding custom chains"
+    fw_custom_chains
+
     $IPTABLES -A INPUT -j input
     $IPTABLES -A OUTPUT -j output
     $IPTABLES -A FORWARD -j forward
@@ -169,9 +172,6 @@
     $IPTABLES -N reject
     $IPTABLES -A reject -p tcp -j REJECT --reject-with tcp-reset
     $IPTABLES -A reject -j REJECT --reject-with icmp-port-unreachable
-
-    echo "Adding custom chains"
-    fw_custom_chains
 
     fw_set_chain_policy INPUT "$DEF_INPUT"
     fw_set_chain_policy OUTPUT "$DEF_OUTPUT"

(Last edited by af3556 on 9 Oct 2008, 11:58)

What about using -I instead of -A ? No need to patch the firewall then.

~ JoW

Alas, using '-I' in the rules for the custom chains only affects the ordering of the custom chain itself. i.e. it's the firewall script that creates all the chains in the various orders. Yes, I could use /etc/firewall.user to rearrange the top-level chains but to do it right would require deleting the custom chain, finding out the index of the zone chain (N) and re-creating the custom chain at N-1. And repeat for every chain. It's easier to "fix" the firewall script.

As it stands now, whilst I appreciate there is great flexibility in the new firewall with it's multitude of chains, that flexibility has come with a complexity cost. I swear you could go cross-eyed following each chain down from the top :-)

(Last edited by af3556 on 9 Oct 2008, 11:51)

And this rule doesn't work too?

iptables -I input_lan -s 192.168.1.206 -j zone_lan_REJECT

or this?

config rule
    option src        lan
    option src_ip    192.168.1.206
    option target    REJECT

Custom rules *must* contain a "src" option, otherwise the firewall is unnable to add them to the appropriate zone.

~ JoW

(Last edited by jow on 9 Oct 2008, 12:02)

I have a few non-interface-specific rules for VPN traffic; I guess I could try and convert all my /etc/firewall.user rules to UCI, but to be honest I don't find the new way very easy to parse. I have long experience with iptables, and I prefer looking at a bunch of iptables rules than the config equivalents.

I do like that the new way seems intended to handle "legacy" requirements such as mine, it's just not quite right yet :-)

I didn't realize that - thank you very much! yes, adding src made a difference!

Is there a way to specify the WAN IP address for the destination IP address?

Here's my scenario:  I run servers within my network that I would also like to be able to access from the WAN side.  The catch is that I need to be able to access the resources independent of whether I'm on my LAN or I'm coming in from the WAN port.  Setting up a standard port forward works great for access from the WAN side.  If I try to use my domain name from the LAN side it needs to SNAT.  The only way I can figure to do this is to determine the packet both came from the LAN with the WAN ip as the destination.

The other wrinkle is that I have a dynamic IP and any relevant firewall rules would need to get reloaded when my WAN address changes.