OpenWrt Forum Archive

Topic: /etc/config/firewall

The content of this topic has been archived on 15 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

There has been some discussion in #openwrt about replacing /etc/config/firewall with a UCI-based file format.

There is a prototype in ticket #1327, but I'm not satisfied with it:
* The parsing logic is clunky and inefficient
* /etc/firewall.user isn't quite as streamlined as it could be
* No provision is made yet for host-specific firewall policies
* Forward/accept/deny rules processing isn't quite right
* /etc/firewall.user should have an available but optional API

I'd like to open up discussion about the config file specification, to make sure that my efforts cover all reasonable cases. Here is the full set of available options planned at this time. If someone thinks other features should be included here, or that the behaviors of certain options should change, then this is the time and place for debate.

This is the /etc/config/firewall spec as it stands now:

config policy <in-iface>
        option default          <deny|accept>
        option <out-iface>   <deny|accept>

config forward <servicename>
        option target          <ipaddress>
        option proto           <tcp|udp|esp|gre|icmp|...>
        option dports         <list of port ranges>
        option sports         <list of port ranges>
        option dport           <one port number>
        option sport           <one port number>
        option dest            <specific wan ip address>
        option src              <ip address of originator>

config accept <servicename>
        option proto           <tcp|udp|esp|gre|icmp|...>
        option dports         <list of port ranges>
        option sports         <list of port ranges>
        option dport           <one port number>
        option sport           <one port number>
        option dest            <specific wan ip address>
        option src              <ip address of originator>

config drop <servicename>
        option proto           <tcp|udp|esp|gre|icmp|...>
        option dports         <list of port ranges>
        option sports         <list of port ranges>
        option dport           <one port number>
        option sport           <one port number>
        option dest            <specific wan ip address>
        option src              <ip address of originator>

A real world example configuration:

config policy lan
        option default          deny
        option wan              allow
        option wap              allow
   
config policy wap
        option default          deny
        option wan              allow
   
config policy vpn
        option default          deny
   
config policy wan
        option default          deny


# there can be only one forward rule with no filters
# can be named anything but must be the first rule listed
config forward dmzserver
        option target           192.168.1.30

# internal publicly available webserver
config forward webserver
        option target           192.168.1.10
        option proto            tcp
        option dports           80,443

# internal server reachable only from a specific host
config forward shellserver
        option target           192.168.1.20
        option source           1.2.3.4
        option proto            tcp
        option dport            22

# who'd run mysql on a router, but it's an example...
config accept mysqlserver
        option proto            tcp
        option dport            3306


# drop windows traffic to and through the router
config drop riffraffserver
        option dports           137-139

I think that you should be able to apply a given rule to a specified interface maybe have a optional "option iface" otherwise default to wan.

Ticket #1327 updated with fixes to most of my complaints above, and the requested 'iface' parameter.

I don't think I can take this much further without some serious peer review, it'll just get to nitpicking if I go it alone.

The discussion might have continued from here.