User Tools

Site Tools


docs:guide-user:firewall:firewall_configuration

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Previous revision
docs:guide-user:firewall:firewall_configuration [2018/08/08 15:44]
docs:guide-user:firewall:firewall_configuration [2018/09/16 12:49] (current)
bobafetthotmail ↷ Links adapted because of a move operation
Line 1: Line 1:
-====== Firewall ====== +====== Firewall ​Configuration in OpenWrt  ​====== 
-The firewall configuration located in **''/​etc/​config/​firewall''​**.+OpenWrt'firewall ​management application [[docs:​guide-user:​firewall:​overview|fw3]] has three provisioning mechanisms
  
-===== Overview ===== +  - UCI Configuration Files 
-LEDE relies on netfilter for packet filtering, NAT and mangling. The UCI Firewall provides a configuration interface that abstracts from the [[http://​www.netfilter.org|iptables system]] to provide a simplified configuration model that is fit for most regular purposes while enabling the user to supply needed iptables rules on their own when needed.+  - ''​uci''​ utility 
 +  - LuCI
  
-UCI Firewall maps two or more //​Interfaces//​ together into //Zones// that are used to describe default rules for a given interface, forwarding rules between interfaces, and extra rules. In the config file, default rules come //first// but they are the last to take effect. The netfilter system is a chained processing filter where packets pass through various rules. The first rule that matches is executed, often leading to another rule-chain until a packet hits either ACCEPT or DROP/​REJECT. Such an outcome is final, therefore the default rules take effect last, and the most specific rule takes effect first. Zones are also used to configure //​masquerading//​ also known as NAT (network-address-translation);​ as well as port forwarding rules, which are more generally known as redirects.+Most of the information in this section will focus on the configuration files and content. 
 +The UCI and LuCI interfaces are user abstractions ultimately modifiying ​the configuration files.
  
-Zones must always be mapped onto one or more Interfaces which ultimately map onto physical devices. Therefore zones cannot be used to specify networks (subnets), and the generated iptables rules operate on interfaces exclusively. The difference ​is that interfaces ​can be used to reach destinations not part of their own subnet, when their subnet contains another gateway. Usually however, forwarding is done between lan and wan interfaces, with the router serving as '​edge'​ gateway to the internet. The default configuration of UCI Firewall provides for such a common setup.+===== Firewall Managment through UCI Configuration Files ===== 
 +See [[docs:​guide-user:​base-system:​uci|UCI System]] for an overview of the UCI configuration files. 
 +The main firewall configuration file is ''/​etc/​config/​firewall''​. This can be editted ​to modify 
 +the firewall settings.
  
-===== Requirements ===== +:!: save the current ​''​firewall'' ​to a backup file.  If your changes cause loss-of-connectivity to the router 
-  * **''​firewall''​** (or  **''​firewall3''​**) and its dependencies (//pre-installed//​) +you will need to access it in failsafe mode and restore the backup to ''/​etc/config/firewall''​.
-  * **''​iptables''​** (//pre-installed//) +
-  * **''​iptables-mod-?''​** (//​optional//​) - depends on what special feature is required+
  
-====Sections ​=====+Once the settings are changed (and double-checked!),​ use 
 +''/​etc/​init.d/​firewall restart''​ to reload the firewall rules. This is a simple shell script calling ''​fw3 reload''​. 
 +It will print diagnostics to the console as it parses the new firewall configuration. ​ Check for errors! 
 + 
 +:!: Any line  using ''#''​ in the first character is not parsed. ​ This is useful for comments to explain a section, 
 +or to quickly comment out a section. 
 + 
 +The capabilities provided by [[http://​www.netfilter.org|netfilter]] are large and continually growing. 
 +The UCI firewall configuration in ''/​etc/​config/​firewall''​ covers a reasonable subset of netfilter rules 
 +but not all of them.  In order to support more functionality an ''​includes''​ section was added to the 
 +UCI firewall configuration to load a file containing native iptable directives. ​ It is processed as a shell 
 +script so really any shell command can be added to it but the focus is working with the netfilter subsystem 
 +by adding ''​iptables''​ commands. 
 +See [[docs:​guide-user:​firewall:​fw3_configurations:​fw3_config_examples|fw3 Configuration Examples]] for usage. 
 + 
 +:!: The [[http://​www.netfilter.org|iptables]] commands can be cryptic and cause 
 +unexpected results. Whenever possible, use the fw3 firewall UCI config. ​ There 
 +are some scenarios where ''​iptable''​ commands are required. 
 +See [[docs:​guide-user:​firewall:​netfilter_iptables:​netfilter_openwrt|Netfilter in 
 +OpenWrt]] for more information. 
 + 
 +==== Configuration File Sections ====
 Below is an overview of the section types that may be defined in the firewall configuration. Below is an overview of the section types that may be defined in the firewall configuration.
-A minimal firewall configuration for a router usually consists of one //​defaults//​ section, at least two //zones// (''​lan''​ and ''​wan''​) and one //​forwarding//​ to allow traffic from ''​lan''​ to ''​wan''​. (The forwarding section is not strictly required when there are no more than two zones as the rule can then be set as the '​global default'​ for that zone.)+A minimal firewall configuration for a router usually consists of one //​defaults//​ section, 
 +at least two //zones// (''​lan''​ and ''​wan''​) 
 +and one //​forwarding//​ to allow traffic from ''​lan''​ to ''​wan''​. 
 +(The forwarding section is not strictly required when there are no more than two zones as the rule 
 +can then be set as the '​global default'​ for that zone.)
  
-==== Defaults ​====+=== Defaults ===
 The ''​defaults''​ section declares global firewall settings which do not belong to specific zones. The ''​defaults''​ section declares global firewall settings which do not belong to specific zones.
 The following options are defined within this section: The following options are defined within this section:
Line 24: Line 52:
 ^ Name ^ Type ^ Required ^ Default ^ Description ^ ^ Name ^ Type ^ Required ^ Default ^ Description ^
 | ''​input''​ | string | no | ''​REJECT''​ | Set policy for the ''​INPUT''​ chain of the ''​filter''​ table. | | ''​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. | | ''​output''​ | string | no | ''​REJECT''​ | Set policy for the ''​OUTPUT''​ chain of the ''​filter''​ table. |
-| ''​forward''​ | string | no | ''​REJECT''​ | Set policy for the ''​FORWARD''​ chain of the ''​filter''​ table. ​ | 
 | ''​drop_invalid''​ | boolean | no | ''​0''​ | Drop invalid packets (e.g. not matching any active connection). | | ''​drop_invalid''​ | boolean | no | ''​0''​ | Drop invalid packets (e.g. not matching any active connection). |
 | ''​syn_flood''​ | boolean | no | ''​0''​ | Enable [[wp>SYN flood]] protection (obsoleted by ''​synflood_protect''​ setting). | | ''​syn_flood''​ | boolean | no | ''​0''​ | Enable [[wp>SYN flood]] protection (obsoleted by ''​synflood_protect''​ setting). |
Line 32: Line 60:
 | ''​synflood_burst''​ | string | no | ''​50''​ | Set burst limit for SYN packets above which the traffic is considered a flood if it exceeds the allowed rate. | | ''​synflood_burst''​ | string | no | ''​50''​ | Set burst limit for SYN packets above which the traffic is considered a flood if it exceeds the allowed rate. |
 | ''​tcp_syncookies''​ | boolean | no | ''​1''​ | Enable the use of [[wp>SYN cookies]]. | | ''​tcp_syncookies''​ | boolean | no | ''​1''​ | Enable the use of [[wp>SYN cookies]]. |
-| ''​tcp_ecn''​ | boolean | no | ''​0''​ |  | +| ''​tcp_ecn''​ | boolean | no | ''​0''​ | FIXME |
-| ''​tcp_westwood''​ | boolean | no | ''​0''​ |  ​|+
 | ''​tcp_window_scaling''​ | boolean | no | ''​1''​ | Enable TCP window scaling. | | ''​tcp_window_scaling''​ | boolean | no | ''​1''​ | Enable TCP window scaling. |
-| ''​accept_redirects''​ | boolean | no | ''​0''​ |  | +| ''​accept_redirects''​ | boolean | no | ''​0''​ | FIXME  | 
-| ''​accept_source_route''​ | boolean | no | ''​0''​ |  | +| ''​accept_source_route''​ | boolean | no | ''​0''​ | FIXME  | 
-| ''​custom_chains''​ | boolean | no | ''​1''​ |  |+| ''​custom_chains''​ | boolean | no | ''​1''​ | FIXME |
 | ''​disable_ipv6''​ | boolean | no | ''​0''​ | Disable IPv6 firewall rules. | | ''​disable_ipv6''​ | boolean | no | ''​0''​ | Disable IPv6 firewall rules. |
 | ''​flow_offloading''​ | boolean | no | ''​0''​ | Enable software flow offloading for connections. (decrease cpu load / increase routing throughput) | | ''​flow_offloading''​ | boolean | no | ''​0''​ | Enable software flow offloading for connections. (decrease cpu load / increase routing throughput) |
 | ''​flow_offloading_hw''​ | boolean | no | ''​0''​ | Enable hardware flow offloading for connections. (depends on flow_offloading and hw capability) | | ''​flow_offloading_hw''​ | boolean | no | ''​0''​ | Enable hardware flow offloading for connections. (depends on flow_offloading and hw capability) |
 +| ''​tcp_reject_code''​ | reject_code | no | FIXME | FIXME |
 +| ''​any_reject_code''​ | reject_code | no | FIXME | FIXME |
 +| ''​auto-helper''​ | bool | no | FIXME | FIXME |
  
-==== Zones ===+=== Zones ===
 A ''​zone''​ section groups one or more //​interfaces//​ and serves as a //source// or //​destination//​ for //​forwardings//,​ //rules// and //​redirects//​. Masquerading (NAT) of outgoing traffic is controlled on a per-zone basis. Note that masquerading is defined on the //​outgoing//​ interface. A ''​zone''​ section groups one or more //​interfaces//​ and serves as a //source// or //​destination//​ for //​forwardings//,​ //rules// and //​redirects//​. Masquerading (NAT) of outgoing traffic is controlled on a per-zone basis. Note that masquerading is defined on the //​outgoing//​ interface.
  
Line 59: Line 88:
 | ''​masq_dest''​ | list of subnets | no | ''​0.0.0.0/​0''​ | Limit masquerading to the given destination subnets. Negation is possible by prefixing the subnet with ''​!'';​ multiple subnets are allowed. | | ''​masq_dest''​ | list of subnets | no | ''​0.0.0.0/​0''​ | Limit masquerading to the given destination subnets. Negation is possible by prefixing the subnet with ''​!'';​ multiple subnets are allowed. |
 | ''​masq_allow_invalid''​ | boolean | no | ''​0''​ | Do not add ''​DROP INVALID''​ rules, if masquerading is used. The ''​DROP''​ rules are supposed to prevent NAT leakage (see [[https://​git.lede-project.org/?​p=project/​firewall3.git;​a=commit;​h=e751cde8954a09ea32f67a8bf7974b4dc1395f2e|commit in firewall3]]). | | ''​masq_allow_invalid''​ | boolean | no | ''​0''​ | Do not add ''​DROP INVALID''​ rules, if masquerading is used. The ''​DROP''​ rules are supposed to prevent NAT leakage (see [[https://​git.lede-project.org/?​p=project/​firewall3.git;​a=commit;​h=e751cde8954a09ea32f67a8bf7974b4dc1395f2e|commit in firewall3]]). |
-| ''​conntrack''​ | boolean | no | ''​1''​ if masquerading is used, ''​0''​ otherwise | Force connection tracking for this zone. (Not supported by newer fw3 versions) (see [[#​notes_on_connection_tracking|Note on connection tracking]]). | 
 | ''​mtu_fix''​ | boolean | no | ''​0''​ | Enable MSS clamping for //​outgoing//​ zone traffic. | | ''​mtu_fix''​ | boolean | no | ''​0''​ | Enable MSS clamping for //​outgoing//​ zone traffic. |
 | ''​input''​ | string | no | ''​DROP''​ | Default policy (''​ACCEPT'',​ ''​REJECT'',​ ''​DROP''​) for //​incoming//​ zone traffic. | | ''​input''​ | string | no | ''​DROP''​ | Default policy (''​ACCEPT'',​ ''​REJECT'',​ ''​DROP''​) for //​incoming//​ zone traffic. |
Line 65: Line 93:
 | ''​output''​ | string | no | ''​DROP''​ | Default policy (''​ACCEPT'',​ ''​REJECT'',​ ''​DROP''​) for //​outgoing//​ zone traffic. | | ''​output''​ | string | no | ''​DROP''​ | Default policy (''​ACCEPT'',​ ''​REJECT'',​ ''​DROP''​) for //​outgoing//​ zone traffic. |
 | ''​family''​ | string | no | ''​any''​ | The protocol family (''​ipv4'',​ ''​ipv6''​ or ''​any''​) these iptables rules are for. | | ''​family''​ | string | no | ''​any''​ | The protocol family (''​ipv4'',​ ''​ipv6''​ or ''​any''​) these iptables rules are for. |
-| ''​log''​ | boolean | no | ''​0''​ | Create log rules for rejected and dropped traffic in this zone. | 
 | ''​log''​ | int | no | ''​0''​ | Bit field to enable logging in the filter and/or mangle tables, bit 0 = filter, bit 1 = mangle. (Since r6397-7cc9914aae)| | ''​log''​ | int | no | ''​0''​ | Bit field to enable logging in the filter and/or mangle tables, bit 0 = filter, bit 1 = mangle. (Since r6397-7cc9914aae)|
 | ''​log_limit''​ | string | no | ''​10/​minute''​ | Limits the amount of log messages per interval. | | ''​log_limit''​ | string | no | ''​10/​minute''​ | Limits the amount of log messages per interval. |
Line 73: Line 100:
 | ''​extra_src''​ | string | no | //Value of ''​extra''//​ | Extra arguments passed directly to iptables for source classification rules. ​ | | ''​extra_src''​ | string | no | //Value of ''​extra''//​ | Extra arguments passed directly to iptables for source classification rules. ​ |
 | ''​extra_dest''​ | string | no | //Value of ''​extra''//​ | Extra arguments passed directly to iptables for destination classification rules. ​ | | ''​extra_dest''​ | string | no | //Value of ''​extra''//​ | Extra arguments passed directly to iptables for destination classification rules. ​ |
 +| ''​custom-chains''​ | bool | no | FIXME | FIXME |
 +| ''​enabled''​ | bool | no | yes | if set to ''​0'',​ zone is disabled |
 +| ''​auto_helper''​ | bool | no | FIXME | FIXME |
 +| ''​helper''​ | cthelper | no | FIXME | FIXME |
  
-==== Forwardings ===+=== Forwardings === 
- +The ''​forwarding''​ sections control the traffic flow between //zones// and may enable [[wp>​Path_MTU_discovery#​Problems_with_PMTUD|MSS clamping]] for specific directions. Only one direction is covered by a ''​forwarding''​ rule. To allow bidirectional traffic flows between two //zones//, two //​forwardings//​ are required, with ''​src''​ and ''​dest''​ reversed in each. 
-The ''​forwarding''​ sections control the traffic flow between //zones// and may enable [[wp>​Path_MTU_discovery#​Problems_with_PMTUD|MSS clamping]] for specific directions. Only one direction is covered by a ''​forwarding''​ rule. To allow bidirectional traffic flows between two //zones//, two //​forwardings//​ are required, with ''​src''​ and ''​dest''​ reversed in each.+
  
 Below is a listing of allowed option within //​forwardings//:​ Below is a listing of allowed option within //​forwardings//:​
  
 ^ Name ^ Type ^ Required ^ Default ^ Description ^ ^ Name ^ Type ^ Required ^ Default ^ Description ^
 +| ''​name''​ | forward name | no | //(none)// | Unique forwarding name. |
 | ''​src''​ | zone name | yes | //(none)// | Specifies the traffic //source zone//. Must refer to one of the defined //zone names//. For typical port forwards this usually is '​wan'​. | | ''​src''​ | zone name | yes | //(none)// | Specifies the traffic //source zone//. Must refer to one of the defined //zone names//. For typical port forwards this usually is '​wan'​. |
 | ''​dest''​ | zone name | yes | //(none)// | Specifies the traffic //​destination zone//. Must refer to one of the defined //zone names// | | ''​dest''​ | zone name | yes | //(none)// | Specifies the traffic //​destination zone//. Must refer to one of the defined //zone names// |
 | <​del>''​mtu_fix''</​del>​ | <​del>​boolean</​del>​ | <​del>​no</​del>​ | <​del>''​0''</​del>​ | <​del>​Enable MSS clamping for traffic flowing from the //source zone// to the //​destination zone//</​del>​ (Deprecated and moved to ''​zone''​ sections in 8.09.2+) | | <​del>''​mtu_fix''</​del>​ | <​del>​boolean</​del>​ | <​del>​no</​del>​ | <​del>''​0''</​del>​ | <​del>​Enable MSS clamping for traffic flowing from the //source zone// to the //​destination zone//</​del>​ (Deprecated and moved to ''​zone''​ sections in 8.09.2+) |
 | ''​family''​ | string | no | ''​any''​ | Protocol family (''​ipv4'',​ ''​ipv6''​ or ''​any''​) to generate iptables rules for. | | ''​family''​ | string | no | ''​any''​ | Protocol family (''​ipv4'',​ ''​ipv6''​ or ''​any''​) to generate iptables rules for. |
 +| ''​enabled''​ | bool | no | yes | if set to ''​0'',​ forward is disabled |
  
 :!: The //​iptables//​ rules generated for this section rely on the //state match// which needs connection tracking to work. :!: The //​iptables//​ rules generated for this section rely on the //state match// which needs connection tracking to work.
-At least one of the ''​src''​ or ''​dest''​ zones needs to have //​connection tracking// enabled ​through either ​the ''​masq''​ or the ''​conntrack''​ option. +At least one of the ''​src''​ or ''​dest''​ zones needs to have //​connection tracking// enabled ​throught ​the ''​masq''​ option.
- +
-==== Redirects ==== +
- +
-Port forwardings (DNAT) are defined by ''​redirect''​ sections. All //​incoming//​ traffic on the specified //source zone// which matches the given rules will be directed to the specified internal host. +
- +
-//Redirects are also commonly known as "port forwarding",​ and "​virtual servers"​.//​ +
- +
-Port ranges are specified as ''​start:​stop'',​ for instance ''​6666:​6670''​. ​ This is similar to the iptables syntax. +
- +
-The options below are valid for //​redirects//:​ +
- +
-^ Name ^ Type ^ Required ^ Default ^ Description ^ +
-| ''​src''​ | zone name | yes for ''​DNAT''​ target | //(none)// | Specifies the traffic //source zone//. Must refer to one of the defined //zone names//. For typical port forwards this usually is ''​wan''​. | +
-| ''​src_ip''​ | ip address | no | //(none)// | Match incoming traffic from the specified //source ip address//. | +
-| ''​src_dip''​ | ip address | yes for ''​SNAT''​ target | //(none)// | For //DNAT//, match incoming traffic directed at the given //​destination ip address//. For //SNAT// rewrite the //source address// to the given address. | +
-| ''​src_mac''​ | mac address | no | //(none)// | Match incoming traffic from the specified //mac address//. | +
-| ''​src_port''​ | port or range | no | //(none)// | Match incoming traffic originating from the given //source port or port range// on the client host. | +
-| ''​src_dport''​ | port or range | no | //(none)// | For //DNAT//, match incoming traffic directed at the given //​destination port or port range// on this host. For //SNAT// rewrite the //source ports// to the given value. | +
-| ''​proto''​ | protocol name or number | yes | //tcpudp// | Match incoming traffic using the given //​protocol//​. | +
-| ''​dest''​ | zone name | yes for ''​SNAT''​ target | //(none)// | Specifies the traffic //​destination zone//. Must refer to one of the defined //zone names//. For ''​DNAT''​ target on Attitude Adjustment, NAT reflection works only if this is equal to ''​lan''​. | +
-| ''​dest_ip''​ | ip address | yes for ''​DNAT''​ target | //(none)// | For //DNAT//, redirect matched incoming traffic to the specified internal host. For //SNAT//, match traffic directed at the given address. For //DNAT// if the ''​dest_ip''​ value matches the local ip addresses of the router, as shown in the ''​ifconfig'',​ then the rule is translated in a DNAT + input '​accept'​ rule. Otherwise it is a DNAT + forward rule. | +
-| ''​dest_port''​ | port or range | no | //(none)// | For //DNAT//, redirect matched incoming traffic to the given port on the internal host. For //SNAT//, match traffic directed at the given ports. Only a single port or range can be specified, not disparate ports as with Rules (below). | +
-| ''​ipset''​ | string | no | //(none)// | If specified, match traffic against the given //​[[#​ip.sets|ipset]]//​. The match can be inverted by prefixing the value with an exclamation mark. | +
-| ''​mark''​ | string | no | //(none)// | If specified, match traffic against the given firewall mark, e.g. ''​0xFF''​ to match mark 255 or ''​0x0/​0x1''​ to match any even mark value. The match can be inverted by prefixing the value with an exclamation mark, e.g. ''​!0x10''​ to match all but mark #16. | +
-| ''​start_date''​ | date (''​yyyy-mm-dd''​) | no | //​(always)//​ | If specifed, only match traffic after the given date (inclusive). | +
-| ''​stop_date''​ | date (''​yyyy-mm-dd''​) | no | //​(always)//​ | If specified, only match traffic before the given date (inclusive). | +
-| ''​start_time''​ | time (''​hh:​mm:​ss''​) | no | //​(always)//​ | If specified, only match traffic after the given time of day (inclusive). | +
-| ''​stop_time''​ | time (''​hh:​mm:​ss''​) | no | //​(always)//​ | If specified, only match traffic before the given time of day (inclusive). | +
-| ''​weekdays''​ | list of weekdays | no | //​(always)//​ | If specified, only match traffic during the given week days, e.g. ''​sun mon thu fri''​ to only match on sundays, mondays, thursdays and fridays. The list can be inverted by prefixing it with an exclamation mark, e.g. ''​! sat sun''​ to always match but on saturdays and sundays. | +
-| ''​monthdays''​ | list of dates | no | //​(always)//​ | If specified, only match traffic during the given days of the month, e.g. ''​2 5 30''​ to only match on every 2nd, 5th and 30rd day of the month. The list can be inverted by prefixing it with an exclamation mark, e.g. ''​! 31''​ to always match but on the 31st of the month. | +
-| ''​utc_time''​ | boolean | no | ''​0''​ | Treat all given time values as UTC time instead of local time. | +
-| ''​target''​ | string | no | ''​DNAT''​ | NAT target (''​DNAT''​ or ''​SNAT''​) to use when generating the rule. | +
-| ''​family''​ | string | no | ''​any''​ | Protocol family (''​ipv4'',​ ''​ipv6''​ or ''​any''​) to generate iptables rules for. | +
-| ''​reflection''​ | boolean | no | ''​1''​ | Activate NAT reflection for this redirect - applicable to ''​DNAT''​ targets. | +
-| ''​reflection_src''​ | string | no | ''​internal''​ | The source address to use for NAT-reflected packets if ''​reflection''​ is ''​1''​. This can be ''​internal''​ or ''​external'',​ specifying which interface’s address to use. Applicable to ''​DNAT''​ targets. | +
-| ''​limit''​ | string | no | //(none)// | Maximum average matching rate; specified as a number, with an optional ''/​second'',​ ''/​minute'',​ ''/​hour''​ or ''/​day''​ suffix. Examples: ''​3/​second'',​ ''​3/​sec''​ or ''​3/​s''​. | +
-| ''​limit_burst''​ | integer | no | ''​5''​ | Maximum initial number of packets to match, allowing a short-term average above ''​limit''​. | +
-| ''​extra''​ | string | no | //(none)// | Extra arguments to pass to iptables. Useful mainly to specify additional match options, such as ''​-m policy %%--%%dir in''​ for IPsec. | +
-| ''​enabled''​ | string | no | ''​1''​ or ''​yes''​ | Enable the redirect rule or not. | +
- +
-:!: On Attitude Adjustment, for NAT reflection to work, you **must** specify ''​option dest lan''​ in the ''​redirect''​ section (even though we're using a ''​DNAT''​ target). +
- +
-==== Rules ====+
  
 +=== Rules ===
 Sections of the type ''​rule''​ can be used to define basic accept or reject rules to allow or restrict access to specific ports or hosts. Sections of the type ''​rule''​ can be used to define basic accept or reject rules to allow or restrict access to specific ports or hosts.
  
-Up to Firewall v2version 57 and below the rules behave like //​redirects// ​and are tied to the given //source zone// and match incoming traffic occuring there. +In fw3, the ''​src'' ​and ''​dest'' ​are tied to the target:
- +
-In later versions the rules are defined as follows:+
   * If ''​src''​ and ''​dest''​ are given, the rule matches //​forwarded//​ traffic   * If ''​src''​ and ''​dest''​ are given, the rule matches //​forwarded//​ traffic
   * If only ''​src''​ is given, the rule matches //​incoming//​ traffic   * If only ''​src''​ is given, the rule matches //​incoming//​ traffic
Line 147: Line 135:
  
 ^ Name ^ Type ^ Required ^ Default ^ Description ^ ^ Name ^ Type ^ Required ^ Default ^ Description ^
 +| ''​name''​ | string | no | //(none)//| Name of rule|
 | ''​src''​ | zone name | yes (:!: optional since Firewall v2, version 58 and above) | //(none)// | Specifies the traffic //source zone//. Must refer to one of the defined //zone names//. | | ''​src''​ | zone name | yes (:!: optional since Firewall v2, version 58 and above) | //(none)// | Specifies the traffic //source zone//. Must refer to one of the defined //zone names//. |
 | ''​src_ip''​ | ip address | no | //(none)// | Match incoming traffic from the specified //source ip address// | | ''​src_ip''​ | ip address | no | //(none)// | Match incoming traffic from the specified //source ip address// |
Line 173: Line 162:
 | ''​extra''​ | string | no | //(none)// | Extra arguments to pass to iptables. Useful mainly to specify additional match options, such as ''​-m policy %%--%%dir in''​ for IPsec. | | ''​extra''​ | string | no | //(none)// | Extra arguments to pass to iptables. Useful mainly to specify additional match options, such as ''​-m policy %%--%%dir in''​ for IPsec. |
 | ''​enabled''​ | boolean | no | yes | Enable or disable rule. | | ''​enabled''​ | boolean | no | yes | Enable or disable rule. |
 +| ''​device''​ | string | no | FIXME | FIXME |
 +| ''​direction''​ | direction | no | FIXME | FIXME //​direction_out//​ |
 +| ''​set_helper''​ | cthelper | no | FIXME | FIXME |
 +| ''​helper''​ | cthelper | no | FIXME | FIXME |
  
 Available icmp type names for //​icmp_type//:​ Available icmp type names for //​icmp_type//:​
Line 186: Line 179:
 | ''​host-precedence-violation''​ | ''​parameter-problem''​ | ''​source-quench''​ | ''​ttl-zero-during-reassembly''​ | | ''​host-precedence-violation''​ | ''​parameter-problem''​ | ''​source-quench''​ | ''​ttl-zero-during-reassembly''​ |
 | ''​host-prohibited''​ | ''​ping''​ | ''​source-route-failed''​ | ''​ttl-zero-during-transit''​ | | ''​host-prohibited''​ | ''​ping''​ | ''​source-route-failed''​ | ''​ttl-zero-during-transit''​ |
-==== Includes ==== 
  
 +=== Redirects ===
 +Port forwardings (DNAT) are defined by ''​redirect''​ sections. All //​incoming//​ traffic on the specified //source zone// which matches the given rules will be directed to the specified internal host.
 +
 +//Redirects are also commonly known as "port forwarding",​ and "​virtual servers"​.//​
 +
 +Port ranges are specified as ''​start:​stop'',​ for instance ''​6666:​6670''​. ​ This is similar to the iptables syntax.
 +
 +The options below are valid for //​redirects//:​
 +
 +^ Name ^ Type ^ Required ^ Default ^ Description ^
 +| ''​name''​ | string | no | //string// | Name of redirect|
 +| ''​src''​ | zone name | yes for ''​DNAT''​ target | //(none)// | Specifies the traffic //source zone//. Must refer to one of the defined //zone names//. For typical port forwards this usually is ''​wan''​. |
 +| ''​src_ip''​ | ip address | no | //(none)// | Match incoming traffic from the specified //source ip address//. |
 +| ''​src_dip''​ | ip address | yes for ''​SNAT''​ target | //(none)// | For //DNAT//, match incoming traffic directed at the given //​destination ip address//. For //SNAT// rewrite the //source address// to the given address. |
 +| ''​src_mac''​ | mac address | no | //(none)// | Match incoming traffic from the specified //mac address//. |
 +| ''​src_port''​ | port or range | no | //(none)// | Match incoming traffic originating from the given //source port or port range// on the client host. |
 +| ''​src_dport''​ | port or range | no | //(none)// | For //DNAT//, match incoming traffic directed at the given //​destination port or port range// on this host. For //SNAT// rewrite the //source ports// to the given value. |
 +| ''​proto''​ | protocol name or number | yes | //tcpudp// | Match incoming traffic using the given //​protocol//​. |
 +| ''​dest''​ | zone name | yes for ''​SNAT''​ target | //(none)// | Specifies the traffic //​destination zone//. Must refer to one of the defined //zone names//. For ''​DNAT''​ target on Attitude Adjustment, NAT reflection works only if this is equal to ''​lan''​. |
 +| ''​dest_ip''​ | ip address | yes for ''​DNAT''​ target | //(none)// | For //DNAT//, redirect matched incoming traffic to the specified internal host. For //SNAT//, match traffic directed at the given address. For //DNAT// if the ''​dest_ip''​ value matches the local ip addresses of the router, as shown in the ''​ifconfig'',​ then the rule is translated in a DNAT + input '​accept'​ rule. Otherwise it is a DNAT + forward rule. |
 +| ''​dest_port''​ | port or range | no | //(none)// | For //DNAT//, redirect matched incoming traffic to the given port on the internal host. For //SNAT//, match traffic directed at the given ports. Only a single port or range can be specified, not disparate ports as with Rules (below). |
 +| ''​ipset''​ | string | no | //(none)// | If specified, match traffic against the given //​[[#​ip.sets|ipset]]//​. The match can be inverted by prefixing the value with an exclamation mark. |
 +| ''​mark''​ | string | no | //(none)// | If specified, match traffic against the given firewall mark, e.g. ''​0xFF''​ to match mark 255 or ''​0x0/​0x1''​ to match any even mark value. The match can be inverted by prefixing the value with an exclamation mark, e.g. ''​!0x10''​ to match all but mark #16. |
 +| ''​start_date''​ | date (''​yyyy-mm-dd''​) | no | //​(always)//​ | If specifed, only match traffic after the given date (inclusive). |
 +| ''​stop_date''​ | date (''​yyyy-mm-dd''​) | no | //​(always)//​ | If specified, only match traffic before the given date (inclusive). |
 +| ''​start_time''​ | time (''​hh:​mm:​ss''​) | no | //​(always)//​ | If specified, only match traffic after the given time of day (inclusive). |
 +| ''​stop_time''​ | time (''​hh:​mm:​ss''​) | no | //​(always)//​ | If specified, only match traffic before the given time of day (inclusive). |
 +| ''​weekdays''​ | list of weekdays | no | //​(always)//​ | If specified, only match traffic during the given week days, e.g. ''​sun mon thu fri''​ to only match on sundays, mondays, thursdays and fridays. The list can be inverted by prefixing it with an exclamation mark, e.g. ''​! sat sun''​ to always match but on saturdays and sundays. |
 +| ''​monthdays''​ | list of dates | no | //​(always)//​ | If specified, only match traffic during the given days of the month, e.g. ''​2 5 30''​ to only match on every 2nd, 5th and 30rd day of the month. The list can be inverted by prefixing it with an exclamation mark, e.g. ''​! 31''​ to always match but on the 31st of the month. |
 +| ''​utc_time''​ | boolean | no | ''​0''​ | Treat all given time values as UTC time instead of local time. |
 +| ''​target''​ | string | no | ''​DNAT''​ | NAT target (''​DNAT''​ or ''​SNAT''​) to use when generating the rule. |
 +| ''​family''​ | string | no | ''​any''​ | Protocol family (''​ipv4'',​ ''​ipv6''​ or ''​any''​) to generate iptables rules for. |
 +| ''​reflection''​ | boolean | no | ''​1''​ | Activate NAT reflection for this redirect - applicable to ''​DNAT''​ targets. |
 +| ''​reflection_src''​ | string | no | ''​internal''​ | The source address to use for NAT-reflected packets if ''​reflection''​ is ''​1''​. This can be ''​internal''​ or ''​external'',​ specifying which interface’s address to use. Applicable to ''​DNAT''​ targets. |
 +| ''​limit''​ | string | no | //(none)// | Maximum average matching rate; specified as a number, with an optional ''/​second'',​ ''/​minute'',​ ''/​hour''​ or ''/​day''​ suffix. Examples: ''​3/​second'',​ ''​3/​sec''​ or ''​3/​s''​. |
 +| ''​limit_burst''​ | integer | no | ''​5''​ | Maximum initial number of packets to match, allowing a short-term average above ''​limit''​. |
 +| ''​enabled''​ | string | no | ''​1''​ or ''​yes''​ | Enable the redirect rule or not. |
 +| ''​helper''​ | cthelper | no | FIXME | FIXME |
 +
 +=== Includes ===
 It is possible to include custom firewall scripts by specifying one or more ''​include''​ sections in the firewall configuration. It is possible to include custom firewall scripts by specifying one or more ''​include''​ sections in the firewall configuration.
  
Line 203: Line 235:
 :!: Since custom iptables rules are meant to be more specific than the generic ones, you must make sure to use ''​-I''​ (insert) instead of ''​-A''​ (append) so that the rules appear **before** the default rules. :!: Since custom iptables rules are meant to be more specific than the generic ones, you must make sure to use ''​-I''​ (insert) instead of ''​-A''​ (append) so that the rules appear **before** the default rules.
  
 +:!: If the rule existings in iptables it wil not be re-added. ​ A standard iptables ''​-I''​ or ''​-A''​ will add a duplicate rule.
  
-==== IP Sets ====+The standard include config is this.  The ''/​etc/​firewall.user''​ is empty initially.
  
-The UCI firewall ​version 3 supports referencing or creating [[http://​ipset.netfilter.org/​|ipsets]] to simplify matching of+<​file>​ 
 +config include 
 + option path '/etc/firewall.user'​ 
 +</​file>​ 
 + 
 +=== Source NAT (SNAT) === 
 + 
 +FIXME list of options but need to find how to use to document this 
 +<​file>​ 
 +snats.c:​23:​ FW3_OPT("​enabled", ​            ​bool, ​     snat,     ​enabled),​ 
 +snats.c:​25:​ FW3_OPT("​name", ​               string, ​   snat,     ​name),​ 
 +snats.c:​26:​ FW3_OPT("​family", ​             family, ​   snat,     ​family),​ 
 +snats.c:​28:​ FW3_OPT("​src", ​                ​device, ​   snat,     ​src),​ 
 +snats.c:​29:​ FW3_OPT("​device", ​             string, ​   snat,     ​device),​ 
 +snats.c:​31:​ FW3_OPT("​ipset", ​              ​setmatch, ​ snat,     ​ipset),​ 
 +snats.c:​33:​ FW3_LIST("​proto", ​             protocol, ​ snat,     ​proto),​ 
 +snats.c:​35:​ FW3_OPT("​src_ip", ​             network, ​  ​snat, ​    ​ip_src),​ 
 +snats.c:​36:​ FW3_OPT("​src_port", ​           port,      snat,     ​port_src),​ 
 +snats.c:​38:​ FW3_OPT("​snat_ip", ​            ​network, ​  ​snat, ​    ​ip_snat),​ 
 +snats.c:​39:​ FW3_OPT("​snat_port", ​          ​port, ​     snat,     ​port_snat),​ 
 +snats.c:​41:​ FW3_OPT("​dest_ip", ​            ​network, ​  ​snat, ​    ​ip_dest),​ 
 +snats.c:​42:​ FW3_OPT("​dest_port", ​          ​port, ​     snat,     ​port_dest),​ 
 +snats.c:​44:​ FW3_OPT("​extra", ​              ​string, ​   snat,     ​extra),​ 
 +snats.c:​46:​ FW3_OPT("​limit", ​              ​limit, ​    ​snat, ​    ​limit),​ 
 +snats.c:​47:​ FW3_OPT("​limit_burst", ​        ​int, ​      ​snat, ​    ​limit.burst),​ 
 +snats.c:​49:​ FW3_OPT("​connlimit_ports", ​    ​bool, ​     snat,     ​connlimit_ports),​ 
 +snats.c:​51:​ FW3_OPT("​utc_time", ​           bool,      snat,     ​time.utc),​ 
 +snats.c:​52:​ FW3_OPT("​start_date", ​         date,      snat,     ​time.datestart),​ 
 +snats.c:​53:​ FW3_OPT("​stop_date", ​          ​date, ​     snat,     ​time.datestop),​ 
 +snats.c:​54:​ FW3_OPT("​start_time", ​         time,      snat,     ​time.timestart),​ 
 +snats.c:​55:​ FW3_OPT("​stop_time", ​          ​time, ​     snat,     ​time.timestop),​ 
 +snats.c:​56:​ FW3_OPT("​weekdays", ​           weekdays, ​ snat,     ​time.weekdays),​ 
 +snats.c:​57:​ FW3_OPT("​monthdays", ​          ​monthdays,​ snat,     ​time.monthdays),​ 
 +snats.c:​59:​ FW3_OPT("​mark", ​               mark,      snat,     ​mark),​ 
 +snats.c:​61:​ FW3_OPT("​target", ​             target, ​   snat,     ​target),​ 
 +</​file>​ 
 + 
 +=== IP Sets === 
 +fw3 supports referencing or creating [[http://​ipset.netfilter.org/​|ipsets]] to simplify matching of
 huge address or port lists without the need for creating one rule per item to match. huge address or port lists without the need for creating one rule per item to match.
  
Line 224: Line 295:
 | ''​hashsize''​ | integer | no | ''​1024''​ | Specifies the initial hash size of the set, only applicable to the ''​hash''​ storage type. | | ''​hashsize''​ | integer | no | ''​1024''​ | Specifies the initial hash size of the set, only applicable to the ''​hash''​ storage type. |
 | ''​timeout''​ | integer | no | ''​0''​ | Specifies the default timeout for entries added to the set. A value of ''​0''​ means no timeout. | | ''​timeout''​ | integer | no | ''​0''​ | Specifies the default timeout for entries added to the set. A value of ''​0''​ means no timeout. |
 +| ''​entry''​ | setentry | no | FIXME | FIXME |
 +| ''​loadfile''​ | string | no | FIXME | FIXME |
  
-=== Possible Storage / Match Combinations ===+:!: This needs the ''​kmod-ipt-ipset''​ kernel module installed.
  
 +== ipsets Possible Storage / Match Combinations ==
 The table below outlines the possible combinations of storage methods and matched datatypes as well as the usable IP address family. The table below outlines the possible combinations of storage methods and matched datatypes as well as the usable IP address family.
 The order of the datatype matches is significant. The order of the datatype matches is significant.
Line 245: Line 319:
 As described above, the option ''​family''​ is used for distinguishing between IPv4, IPv6 and both protocols. However the family is inferred automatically if IPv6 addresses are used, e.g. As described above, the option ''​family''​ is used for distinguishing between IPv4, IPv6 and both protocols. However the family is inferred automatically if IPv6 addresses are used, e.g.
  
-<code>+<file>
 config rule config rule
         option src wan         option src wan
         option src_ip fdca:​f00:​ba3::/​64         option src_ip fdca:​f00:​ba3::/​64
         option target ACCEPT         option target ACCEPT
-</code>+</file>
  
 ... is automatically treated as IPv6 only rule. ... is automatically treated as IPv6 only rule.
Line 256: Line 330:
 Similar, such a rule: Similar, such a rule:
  
-<code>+<file>
 config rule config rule
         option src wan         option src wan
         option dest_ip 88.77.66.55         option dest_ip 88.77.66.55
         option target REJECT         option target REJECT
-</code>+</file>
  
 ... is detected as IPv4 only. ... is detected as IPv4 only.
Line 268: Line 342:
 Redirect rules (portforwards) are always IPv4 (for now) since there is no IPv6 DNAT support (yet). Redirect rules (portforwards) are always IPv4 (for now) since there is no IPv6 DNAT support (yet).
  
 +===== Firewall Management through the ''​uci''​ utility =====
 +The ''​uci''​ utility (base package) is a low-level abstraction to the configuration files.
 +It can accessed on the device remotely through SSH.
  
 +Use ''​uci show firewall''​ to display the firewall content as a set of arrays mapping
 +to the Configuration File Sections:
  
-===== Examples =====+  * ''​defaults''​ 
 +  * ''​zone''​ 
 +  * ''​forwarding''​ 
 +  * ''​rule''​ 
 +  * ''​redirect''​ 
 +  * ''​include''​
  
-==== Opening ports ====+For example, this rule rejects all traffic forwarded from the WAN-side to the LAN-side of the router.
  
-The default configuration accepts all LAN traffic, but blocks all incoming WAN traffic on ports not currently used for connections or NAT. To open a port for a service, add a ''​rule''​ section: 
-<​code>​ 
-config rule 
-        option src              wan 
-        option dest_port ​       22 
-        option target ​          ​ACCEPT 
-        option proto            tcp 
-</​code>​ 
- 
-This example enables machines on the internet to use SSH to access your router. 
- 
-==== Opening ports for selected subnet/host ==== 
- 
-If you want to permit access to one host or subnet you should describe //src_ip// field: 
-<​code>​ 
-config rule 
-        option src              wan 
-        option src_ip ​          '​12.34.56.64/​28'​ 
-        option dest_port ​       22 
-        option target ​          ​ACCEPT 
-        option proto            tcp 
-</​code>​ 
- 
-This example enables ssh access to host from entire //​12.34.56.64/​28//​ subnet. 
- 
-==== Port forwarding for IPv4 (Destination NAT/DNAT) ==== 
- 
-This example forwards http (but not HTTPS) traffic to the webserver running on 192.168.1.10:​ 
- 
-<​code>​ 
-config redirect 
-        option src       wan 
-        option src_dport 80 
-        option proto     tcp 
-        option dest      lan 
-        option dest_ip ​  ​192.168.1.10 
-</​code>​ 
- 
-This other example forwards one arbitrary port that you define to a box running ssh. 
- 
-<​code>​ 
-config redirect 
-        option src       wan 
-        option src_dport 5555 
-        option proto     tcp 
-        option dest      lan 
-        option dest_ip ​  ​192.168.1.100 
-        option dest_port 22 
-</​code>​ 
- 
-==== Stateful firewall without NAT ==== 
- 
-If your LAN is running with public IP addresses, then you definitely don't want NAT (masquerading). ​ But you may still want to run a stateful firewall on the router, so that machines on the LAN are not reachable from the Internet. 
- 
-To do this, add the ''​conntrack''​ option to the WAN zone: 
- 
-<​code>​ 
-config zone 
-        option name             wan 
-        list   ​network ​         '​wan'​ 
-        list   ​network ​         '​wan6'​ 
-        option input            REJECT 
-        option output ​          ​ACCEPT 
-        option forward ​         REJECT 
-        option masq             0 
-        option mtu_fix ​         1 
-        option conntrack ​       1 
-</​code>​ 
- 
-==== DNAT/SNAT redirects and forwarding combination ==== 
-Given a couple of redirect (DNAT and SNAT, like to redirect 
-the traffic from an host to and from a specific ip address) such as: 
 <​file>​ <​file>​
-config redirect +firewall.@rule[22]=rule 
-        ​option name     '​icmp DNAT'​ +firewall.@rule[22].src='​wan'​ 
-        option ​src      '​wan'​ +firewall.@rule[22].dest='lan
-        ​option src_dip ​  '​1.2.3.4' +firewall.@rule[22].proto='tcp udp icmp'​ 
-        option proto    '​icmp'​ +firewall.@rule[22].target='​REJECT
-        option ​dest     ​'dmz+firewall.@rule[22].name='REJECT-ALL-WAN-LAN'
-        ​option dest_ip ​ '192.168.1.79'​ +
-        option target ​  '​DNAT'​ +
- +
-config redirect +
-        option name     '​icmp ​SNAT+
-        ​option src      '​dmz'​ +
-        option src_ip ​  '​192.168.1.79+
-        ​option src_dip ​ '1.2.3.4' +
-        option proto    '​icmp'​ +
-        option dest     '​wan'​ +
-        option target ​  'SNAT'+
 </​file>​ </​file>​
  
-Someone could ask "//Ok, the packet source or destination ​is changed, +This is presumed ​to create ​the final rules (each '​proto' ​creates ​a rule) in the //WAN -> LAN// forward ​chain
-but still has to be forwarded towards ​the right network interface to reach the +These rules cause all packets from the WAN to be rejected, so desired ​traffic (e.gicmpneeds 
-endpoint//"​. So the administrator of the device could wonder if adding +to have rules prior to this.
-additional forwarding ​rules is required; but no, it is not needed. The forwarding +
-rules are added by the firewall appliance itself. +
- +
-The same applies to the masquerading,​ the rules are applied //​before//​ +
-the global masquerading ​(if a masquerading is set), therefore they will +
-not be overridden (at least the SNAT) by the masquerading mechanism. +
-==== Masquerading on lan ==== +
-Suppose that you have two routers, connected ​each other through the  +
-lan zone (both have static ip and dhcp disabled),  +
-and only one of them is connected to the internet through the wan zone.  +
-In other words the situation is: +
-<​code>​ +
-internet <​---->​ wan (172.22.13.228) | router 1 | lan (192.168.1.254) <​---->​ lan (192.168.1.1) | router 2 | wan (no connection) +
-</​code>​ +
- +
-If both routers have the default openwrt configuration  +
-(with the exceptions mentioned above), then a device on the lan side of the +
-router 1 can communicate through the internet if it has the router 1 as +
-gateway, this because the packet flow between devices is managed by routing. +
-In our case the router 2 has no proper setup in terms of gateway, +
-as the default openwrt configuration expects that a wan connection +
-on the router 2 is provided. +
- +
-Anyway suppose that on the router 1 we have the following rule: +
-<​code>​ +
-config redirect +
-        option target ​'DNAT'​ +
-        option src '​wan'​ +
-        option dest '​lan'​ +
-        option ​proto 'tcp' +
-        option src_dip '​172.22.13.228'​ +
-        option src_dport '​2023'​ +
-        option dest_ip '​192.168.1.1'​ +
-        option dest_port '​23'​ +
-        option name '​Telnet to new Router'​  +
-</​code>​ +
-This rule is redirecting the tcp packets on the port 2023 with destination the wan ip of the router 1  +
-(172.22.13.228) towards the lan ip of the router 2.  +
-The router 2 cannot reply to those packets because we didn't adjust its routing table, +
-that is we didn't specify that the gateway to reply to "​wan"​ sources is the router 1. +
-Indeed those redirected packets will have an source ip external from the (default) "​lan"​ zone 192.168.1.0/​24. +
- +
-We can solve this activating the masquerading on the "​lan"​ zone on the router 1, in this way. +
-<​code>​ +
-config zone +
-        option name '​lan'​ +
-        option network '​lan'​ +
-        option input '​ACCEPT'​ +
-        option output '​ACCEPT'​ +
-        option forward '​REJECT'​ +
-        option masq '​1'​ +
-</​code>​ +
-This setup will provide the following effect (that is the effect intended by the masquerading):​ if packet, belonging to a certain [[wp>​Virtual_circuit|connection]],​ is coming into the lan zone with a source ip belonging to another zone, keep track of the connection, taking note of the source ip of that connection, and modify the source ip with the ip of the router in the lan zone (that is: source_ip from a.b.c.d to 192.168.1.254). \\  +
-Then deliver the packet to the intended destination (that is, 192.168.1.1,​ the router2). Afterwards, if a packet from 192.168.1.1 is coming back towards 192.168.1.254,​ belonging to the connection tracked before, changed back the destination ip (here is the second effect of the masquerading) with the source ip memorized before (that is, dest_ip from 192.168.1.254 to a.b.c.d ). In this way, for the point of view of the router 2, the router 2 just communicate with a device with an ip belonging to its "​lan"​ zone , and therefore the default routing is working without problem. +
- +
-At least one side effect of this setup is that every device in the lan zone of the router 1 cannot see any "​wan"​ ip, and this could be not wanted for several reasons (one of which: if you setup a proper gateway, there is no need for this masquerading). But this was just a "​special case" to expose in brief how the masquerading works and how it could be applied to zones that usually don't use it. An improvement of "​masquerading only for a specific device in the zone" could be the following:​ +
-<​code>​ +
-config zone +
-        option name '​lan'​ +
-        option network '​lan'​ +
-        option input '​ACCEPT'​ +
-        option output '​ACCEPT'​ +
-        option forward '​REJECT'​ +
-        option masq '​1'​ +
-        option masq_dest '​192.168.1.1/​32'​ +
-</​code>​ +
-This provide the masquerading feature only if the packets are send towards the destination 192.168.1.1/​32 (this subnet should belong to the lan zone). +
-==== Port accept for IPv6 ==== +
- +
-To open port 80 so that a local webserver at ''​2001:​db8:​42::​1337''​ can be reached from the Internet: +
- +
-<​code>​ +
-config ​rule +
-        option src       wan +
-        option proto     tcp +
-        option dest      lan +
-        option dest_ip ​  ​2001:​db8:​42::​1337 +
-        option dest_port 80 +
-        option family ​   ipv6 +
-        option target ​   ACCEPT +
-</​code>​ +
- +
-To open SSH access to all IPv6 hosts in the local network: +
- +
-<​code>​ +
-config rule +
-        option src       wan +
-        option proto     tcp +
-        option dest      lan +
-        option dest_port 22 +
-        option family ​   ipv6 +
-        option target ​   ACCEPT +
-</​code>​ +
- +
-To open all TCP/UDP port between 1024 and 65535 towards the local IPv6 network: +
- +
-<​code>​ +
-config rule +
-        option src       wan +
-        option proto     ​tcpudp +
-        option dest      lan +
-        option dest_port 1024:​65535 +
-        option family ​   ipv6 +
-        option target ​   ACCEPT +
-</​code>​ +
- +
-==== Source NAT (SNAT==== +
- +
-Source NAT changes an outgoing packet so that it looks as though the LEDE system is the source of the packet. +
- +
-Define source NAT for UDP and TCP traffic directed to port 123 originating from the host with the IP address 10.55.34.85. +
-The source address is rewritten to 63.240.161.99:​ +
- +
-<​code>​ +
-config redirect +
-        option src              lan +
-        option dest             wan +
-        option src_ip ​          ​10.55.34.85 +
-        option src_dip ​         63.240.161.99 +
-        option dest_port ​       123 +
-        option target ​          ​SNAT +
-</​code>​ +
- +
-When used alone, Source NAT is used to restrict a computer'​s access to the internet, but allow it to access a few services by forwarding what appear to be a few local services, e.g. [[http://​en.wikipedia.org/​wiki/​Network_time_protocol|NTP]],​ to the internet. ​ While DNAT hides the local network from the internet, SNAT hides the internet from the local network. +
- +
-Source NAT and destination NAT are combined and used dynamically ​in IP masquerading to make computers with private (192.168.x.x,​ etc.) IP address appear on the internet with the LEDE router'​s public WAN ip address. +
- +
-==== True destination port forwarding ==== +
- +
-//Most users won't want this//​. ​ Its usage is similar to SNAT, but as the the destination IP address isn't changed, machines on the destination network need to be aware that they'​ll receive and answer requests from a public IP address that isn't necessarily theirs. ​ Port forwarding in this fashion is typically used for load balancing. +
-<​code>​ +
-config redirect +
-        option src              wan +
-        option src_dport ​       80 +
-        option dest             lan +
-        option dest_port ​       80 +
-        option proto            tcp +
-</​code>​ +
- +
-==== Block access to a specific host ==== +
- +
-The following rule blocks all connection attempts to the specified host address. +
- +
-<​code>​ +
-config rule +
-        option src              lan +
-        option dest             wan +
-        option dest_ip ​         123.45.67.89 +
-        option target ​          ​REJECT +
-</​code>​ +
- +
-==== Block access to the Internet using MAC  ==== +
- +
-The following rule blocks all connection attempts from the client to the Internet. +
- +
-<​code>​ +
-config rule +
-        option src              lan +
-        option dest             wan +
-        option src_mac ​         00:​00:​00:​00:​00:​00 +
-        option target ​          ​REJECT +
-</​code>​ +
- +
-==== Block access to the Internet for specific IP on certain times  ==== +
- +
-The following rule blocks all connection attempts to the internet from 192.168.1.27 on weekdays between 21:00pm and 09:00am (times are specified in UTC unless the --kerneltz switch is used).\\ +
-:!: The package ''​iptables-mod-ipopt''​ must be installed to provide ''​xt_time''​. +
- +
-<​code>​ +
-config rule +
-        option src              lan +
-        option dest             wan +
-        option src_ip ​          ​192.168.1.27 +
-        option proto            all +
-        option start_time ​      ​21:​00:​00 +
-        option stop_time ​       09:00:00 +
-        option weekdays ​        '​mon tue wed thu fri' +
-        option target ​          ​REJECT +
-        option extra            '​--kerneltz'​ +
-</​code>​ +
- +
-Instead of using an IP address, you can also block a specific device MAC with <​code> ​       option src_mac '​78:​BB:​AA:​3A:​88:​14'</​code>​ +
- +
-See also [[docs:​guide-user:​firewall:​parental-controls|Parental controls]] +
-==== Restricted forwarding rule ==== +
- +
-The example below creates a //forward// rule rejecting traffic from lan to wan on the ports 1000-1100. +
- +
-<​code>​config rule +
-        option src              lan +
-        option dest             wan +
-        option dest_port ​       1000-1100 +
-        option proto            tcpudp +
-        option target ​          ​REJECT</​code>​ +
- +
-==== Simple output rule ==== +
- +
-The example below creates an //output// rule which prevents the router from pinging the address ''​8.8.8.8''​. +
- +
-:!: Only supported by the Firewall v2, version 58 and above  +
- +
-<​code>​config rule +
-        option dest             wan +
-        option dest_ip ​         8.8.8.8 +
-        option proto            icmp +
-        option target ​          ​REJECT</​code>​ +
- +
-==== Transparent proxy rule (same host) ==== +
- +
-The rule below redirects all outgoing HTTP traffic from //lan// through a proxy server listening at port 3128 on the router itself. +
- +
-<​code>​config redirect +
- option src              lan +
- option proto            tcp +
- option src_dport ​       80 +
- option dest_port ​       3128 +
- option dest_ip ​         192.168.1.1</​code>​ +
- +
-==== Transparent proxy rule (external) ==== +
- +
-The following rule redirects all outgoing HTTP traffic from //lan// through an external proxy at 192.168.1.100 listening on port 3128. +
-It assumes the LEDE //lan// address to be 192.168.1.1 - this is needed to masquerade redirected traffic towards the proxy. +
- +
-<​code>​config redirect +
-        option src              lan +
-        option proto            tcp +
-        option src_ip ​          ​!192.168.1.100 +
-        option src_dport ​       80 +
-        option dest_ip ​         192.168.1.100 +
-        option dest_port ​       3128 +
-        option target ​          ​DNAT +
- +
-config redirect +
-        option dest             lan +
-        option proto            tcp +
-        option src_dip ​         192.168.1.1 +
-        option dest_ip ​         192.168.1.100 +
-        option dest_port ​       3128 +
-        option target ​          ​SNAT</​code>​ +
- +
-==== Simple DMZ rule ==== +
- +
-The following rule redirects all WAN ports for all protocols to the internal host 192.168.1.2. +
- +
-<​code>​config redirect +
- option src              wan +
- option proto            all +
- option dest_ip ​         192.168.1.2</​code>​ +
- +
-==== IPSec passthrough ==== +
- +
-This example enables proper forwarding of IPSec traffic through the wan. +
- +
-<​code>​ +
-# AH protocol +
-config rule +
-        option src              wan +
-        option dest             lan +
-        option proto            ah +
-        option target ​          ​ACCEPT +
- +
-# ESP protocol +
-config rule +
-        option src              wan +
-        option dest             lan +
-        option proto            esp +
-        option target ​          ​ACCEPT +
-</​code>​ +
- +
-For some configurations you also have to open port 500/UDP. +
- +
-<​code>​ +
-# ISAKMP protocol +
-config rule +
-        option src              wan +
-        option dest             lan +
-        option proto            udp +
-        option src_port ​        500 +
-        option dest_port ​       500 +
-        option target ​          ​ACCEPT +
-</​code>​ +
- +
-==== Using ipsets ==== +
-This example shows how to block traffic to ipset of online game IP/port combinations. Creation/​update of the ipset can be done in '/​etc/​rc.local'​ or using crontab. +
-  +
-<​code>​ +
-config ipset +
- option external ​        ​games_blacklist +
- option match            '​dest_ip dest_port'​ +
- option family ​          ​ipv4 +
- option storage ​         hash +
-</​code>​ +
- +
-<​code>​ +
-config rule +
- option name             Drop-games-blacklist +
- option src              lan +
- option ipset            games_blacklist +
- option proto            tcpudp +
- option target ​          ​DROP +
-</code> +
- +
-==== Zone declaration for semi non-UCI interfaces, manually listed in the network config, and forwardings ==== +
-Scenario: having one or more vpn tunnels using openvpn, +
-with the need of defining a zone to forward the traffic between the +
-vpn interfaces and the lan. +
- +
-First list the interfaces in **/etc/config/​network**,​ for example, as written below. Be careful on the limits of interface naming in terms of name length, [[docs:​guide-user:​base-system:​basic-networking#​interfaces|read more]]) +
-<​code>​ +
-config interface '​tun0'​ +
- option ifname '​tun0'​ +
- option proto '​none'​ +
- +
-config interface '​tun1'​ +
-        option ifname '​tun1'​ +
-        option proto '​none'​ +
-</​code>​ +
- +
-Then create the zone in **/​etc/​config/​firewall**,​ for example one zone for all the vpn interfaces. +
-<​code>​ +
-config zone +
-        option name             ​vpn_tunnel +
-        list   ​network ​         '​tun0'​ +
- list   ​network ​         '​tun1'​ +
-        option input            ACCEPT +
-          #the traffic towards the router from the interface will be accepted +
-          #(as for the lan communications) +
-        option output ​          ​ACCEPT +
-          #the traffic from the router to the interface will be accepted +
-        option ​forward ​         ​REJECT +
-          #traffic from this zone to other zones is normally rejected +
-</​code>​ +
- +
-Then we want to communicate with the "​lan"​ zone, therefore we need forwardings in both ways +
-(from lan to wan and viceversa) +
-<​code>​ +
-config forwarding +
-        option src              lan +
-        option dest             ​vpn_tunnel +
-        #if a packet from lan wants to go to the vpn_tunnel zone +
-        #let it pass +
- +
-config forwarding +
-        option src              vpn_tunnel +
-        option dest             lan +
-        #if a packet from vpn_tunnel wants to go to the lan zone +
-        #let it pass +
-</​code>​ +
-This will create a lot of "​automatic"​ iptables rules (because automatic scripting is not +
-as efficient as raw iptable commands in /​etc/​firewall.user)  +
-but those rules will be more clear in the luci webinterface and also more readable for +
-less expert users. +
- +
-In general remember that forwardings are relying how routing rules are defined, and afterwards which zones are +
-defined on which interfaces. +
-==== Zone declaration for non-UCI interfaces ==== +
- +
-This example declares a zone which maches any Linux network device whose name begins with "​ppp"​. +
- +
-:!: Only supported by the Firewall v2, version 58 and above +
- +
-<​code>​ +
-config zone +
-        option name             ​example +
-        option input            ACCEPT +
-        option output ​          ​ACCEPT +
-        option forward ​         REJECT +
-        option device ​          '​ppp+'​ +
-</​code>​ +
- +
-==== Zone declaration for a specific subnet and protocol ==== +
- +
-This example declares a zone which maches any TCP stream in the ''​10.21.0.0/​16''​ subnet. +
- +
-:!: Only supported by the Firewall v2, version 58 and above +
- +
-<​code>​ +
-config zone +
-        option name             ​example +
-        option input            ACCEPT +
-        option output ​          ​ACCEPT +
-        option forward ​         REJECT +
-        option subnet ​          '​10.21.0.0/​16'​ +
-        option extra            '-p tcp' +
-</​code>​ +
- +
- +
-==== Zone declaration for a specific protocol and port ==== +
- +
-This example declares a zone which maches any TCP stream from and to port ''​22''​. +
- +
-:!: Only supported by the Firewall v2, version 58 and above +
- +
-<​code>​ +
-config zone +
-        option name             ​example +
-        option input            ACCEPT +
-        option output ​          ​ACCEPT +
-        option forward ​         REJECT +
-        option extra_src ​       '-p tcp --sport 22' +
-        option extra_dest ​      '​-p tcp --dport 22' +
-</​code>​ +
- +
-==== Forwarding IPv6 tunnel traffic === +
- +
-:!: This example is for IPv6 tunnels only, and does not apply to native dual-stack interfaces. +
- +
-**Unverified Information!** From my experience ​all you need to do is just add the interface name of your ipv6 tunnel to the wan zone of your firewall. This worked for me: remove the information below if this is the correct way to proceed.  +
- //​Caveat:​ The above will only work if the tunnel is bringing IPv6 connectivity to the router itself. If you use the tunnel to route a prefix into your lan as well, you will additionally need to allow Inter-Zone Forwarding from wan to lan (not enabled by default). Creating a separate firewall zone (as described below) is a cleaner solution, though.// +
- +
-IPv6 packets ​are by default not forwarded ​from lan to your wan6 interface and vice versa. Make sure to add ''​net.ipv6.conf.all.forwarding=1''​ in ''/​etc/​sysctl.conf''​ to enable it permanently. Assuming your tunnel interface is called ''​henet'',​ add the following sections ​to ''/​etc/​config/​firewall''​ to create a new zone ''​wan6'',​ covering ''​henet''​ and allowing forwarding betweeen ''​wan6''​ and ''​lan''​ in both directions:​ +
- +
-<​code>​config zone +
- option name wan6 +
- option network henet +
- option family ipv6 +
- option input ACCEPT +
- option output ACCEPT +
- option forward REJECT +
- +
-config forwarding +
- option dest lan +
- option src wan6 +
-#you don't need the below as you can a firewall rule to open the port that you need +
-config forwarding +
- option dest wan6 +
- option src lan +
-</​code>​ +
- +
-The ''​family''​ option ensures that the zone and all associated entries (''​rule'',​ ''​forwarding''​ and ''​redirect''​ sections) are only added to //​ip6tables//​ but not //​iptables//​. +
- +
-==== Manual iptables rules ==== +
- +
-Traditional iptables rules, in the standard iptables unix command form, can be specified in an external file and included in the firewall config file. It is possible to include multiple files this way. +
-<​code>​ +
-config include +
-       ​option path /​etc/​firewall.user +
- +
-config include +
-       ​option path /​etc/​firewall.vpn +
-</​code>​ +
- +
-//Note:// The syntax for the includes is standard [[http://​www.netfilter.org|iptables]],​ and therefore different from the syntax supported by UCI. +
- +
-===== Firewall management ===== +
- +
-After a configuration change, firewall rules are rebuilt by executing ''/​etc/​init.d/​firewall restart'';​ calling ''/​etc/​init.d/​firewall stop''​ will flush all rules and set the policies to ACCEPT on all standard chains. +
-To manually start the firewall, call ''/​etc/​init.d/​firewall start''​. +
- +
-The firewall can be permananently disabled by executing ''/​etc/​init.d/​firewall disable''​. +
-Note that ''​disable''​ does not flush the rules, so it might be required to issue a ''​stop''​ before. +
-Use ''​enable''​ to activate the firewall again. +
- +
-==== Temporarily disable firewall ==== +
- +
-Run ''/​etc/​init.d/​firewall stop''​ to flush all rules and set the policies to ACCEPT. +
-To restart the firewall, run ''/​etc/​init.d/​firewall start''​. +
- +
-===== Hotplug hooks (8.09.2+) ===== +
- +
-In addition to //​includes//​ it is possible to let the firewall execute //hotplug handlers// when interfaces are added to a zone or removed from it. This is useful to create rules for interfaces with dynamic ip configurations (dhcp, pppoe) on the fly. +
- +
-Each time an interface is added or removed from a zone, all scripts in the ''/​etc/​hotplug.d/​firewall/''​ directory are executed. Scripts must be named in the form ''​NN-name''​ with ''​NN''​ being a numeric index between ''​00''​ and ''​99''​. The ''​name''​ can be freely choosen. +
- +
-Once a handler script is invoked, the information about the event is passed through the environment. +
-The table below lists defined variables and their meaning. +
- +
-^ Variable ^ Description ^ +
-| ACTION | Type of the event: ''​add''​ if an interface was added, ''​remove''​ if it was removed | +
-| ZONE | Name of the firewall zone the interface was added to | +
-| INTERFACE | LEDE name of the interface, for example "​lan"​ or "​wan"​ - corresponds to the interfaces defined in ''/​etc/​config/​network''​ | +
-| DEVICE | The physical interface involved, for example "​eth0"​ or "​ppp0"​ | +
-===== Implications of DROP vs. REJECT ===== +
- +
-The decision whether to //drop// or to //​reject// ​traffic ​should be done on a case-by-case basis. Many people see dropping traffic as a security advantage over rejecting it because it exposes less information to a hypothetical attacker. +
-While dropping slightly increases security, it can also complicate the debugging of network issues or cause unwanted side-effects on client programs. +
- +
-If traffic is //​rejected//,​ the router will respond with an ICMP error message ​("​destination port unreachable"​) causing the connection attempt to fail immediatelyThis also means that for each connection attempt a certain amount of response traffic is generatedThis can cause harm if the firewall is "​attacked"​ with many simultaneous connection attempts; the resulting "​backfire"​ of ICMP responses can clog up all available bandwidth and make the connection unusable (DoS). +
- +
-When connection attempts are //dropped// the client is not aware of the blocking and will continue ​to re-transmit its packets until the connection eventually times out. Depending on the way the client software is implemented,​ this could result in frozen or hanging programs that need to wait until a timeout occurs before they'​re able to continue. +
- +
-Also there is an interesting article which that claims dropping connections doesnt make you any safer - [[http://​www.chiark.greenend.org.uk/​~peterb/​network/​drop-vs-reject|Drop versus Reject]]. +
- +
-**DROP** +
-  * less information is exposed  +
-  * less attack surface +
-  * client software may not cope well with it (hangs until connection times out) +
-  * may complicate network debugging (where was traffic dropped and why) +
- +
-**REJECT** +
-  * may expose information (like the ip at which traffic was actually blocked) +
-  * client software can recover faster from rejected connection attempts +
-  * network debugging easier (routing and firewall issues clearly distinguishable) +
- +
- +
-===== Notes on connection tracking ===== +
- +
-==== NOTRACK ==== +
- +
-:!: This is now obsolete since fw3 version 2016-11-29 by [[https://​github.com/​lede-project/​source/​commit/​2daab45cae3cfc09bae96f4326a3963a7504e86d|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 http://​security.maruhn.com/​iptables-tutorial/​x4772.html . +
- +
-==== nf_conntrack_skip_filter ==== +
- +
-:!: Only available in Barrier Breaker. **''​Revoked in Chaos Calmer RC1 and onwards''​** due to various problems. +
- +
-From [[https://​dev.openwrt.org/​changeset/​42048/​trunk/​package|r42048]] to [[https://​dev.openwrt.org/​changeset/​44873|r44873]],​ there was a new setting activated by default which causes the packets with the established state, completely bypass iptables filter table. This is to [[https://​dev.openwrt.org/​ticket/​17690#​comment:​6|help with network performance]] and unless you need all packets to be counted by iptables filter or have some specific ​rules which would apply to already established connections,​ you should leave it active.  +
- +
-This behavior can be disabled by editing /​etc/​sysctl.conf : +
-  net.netfilter.nf_conntrack_skip_filter=0 +
-and then activating the new setting: +
-  sysctl -p +
- +
-or be temporarily turned off untill the next reboot by issuing : +
-  sysctl -w net.netfilter.nf_conntrack_skip_filter=0 +
- +
-===== How to delete a rule ===== +
- +
-If you made a mistake you can delete a rule this way. +
- +
-First, issue this command to find the index of the rule: +
- +
-<​code>​ +
-# iptables -L -t raw --line-numbers +
-</​code>​ +
- +
-Now to delete, e.g. the third rule from chain OUTPUT, execute: +
- +
-<​code>​ +
-# iptables -t raw -D OUTPUT 3 +
-</​code>​ +
- +
-===== Debug generated rule set ===== +
- +
-It is possible to observe the iptables commands generated by the firewall program, +
-this is useful to track down iptables errors during firewall restarts or to verify +
-the outcome of certain uci rules. +
- +
-In order to see the rules as they'​re executed, run the ''​fw''​ command with the ''​FW_TRACE''​ +
-environment variable set to ''​1''​ (one): +
- +
-<​code>​ +
-# FW_TRACE=1 fw reload +
-</​code>​ +
- +
-To direct the output to a file for later inspection, use the command below: +
-<​code>​ +
-# FW_TRACE=1 fw reload 2>/​tmp/​iptables.log +
-</​code>​ +
- +
- +
-If you are using the firewall3, you can enable debug mode using the ''​-d''​ switch: +
-<​code>​ +
-# fw3 -d reload 2>/​tmp/​iptables.log +
-</​code>​ +
- +
-Furthermore it is also possible to print the to-be generated ruleset using the ''​print''​ command in conjunction with the ''​-4''​ and ''​-6''​ switches: +
-<​code>​ +
-# fw3 -4 print > /​tmp/​ipv4.rules +
-# fw3 -6 print > /​tmp/​ipv6.rules +
-</​code>​ +
- +
-===== Packet flow ====== +
- +
-==== INPUT (destined to router) ==== +
- +
-^ Table  ^ Chain                         ^ Type     ^ Description ^ +
-| raw    | ''​PREROUTING'' ​               | system ​  | | +
-| :::    | ''​notrack'' ​                  | internal | Internal chain for NOTRACK rules | +
-| mangle | ''​PREROUTING'' ​               | system ​  | | +
-| :::    | ''​fwmark'' ​                   | internal | Internal chain for MARK rules | +
-| nat    | ''​PREROUTING'' ​               | system ​  | | +
-| :::    | ''​delegate_prerouting'' ​      | internal | Internal chain to hold toplevel prerouting rules, dispatches traffic to the corresponding ''​zone_//​name//​_prerouting''​ chains | +
-| :::    | ''​prerouting_rule'' ​          | user     | Container chain for custom user prerouting rules (firewall.user) | +
-| :::    | ''​zone_//​name//​_prerouting'' ​ | internal | Per-zone container chains for DNAT (port forwarding) rules | +
-| :::    | ''​prerouting_//​name//​_rule'' ​ | user     | Per-zone container chains for custom user prerouting rules (firewall.user) | +
-| mangle | ''​INPUT'' ​                    | system ​  | | +
-| filter | ''​INPUT'' ​                    | system ​  | | +
-| :::    | ''​delegate_input'' ​           | internal | Internal chain to hold toplevel input rules, dispatches traffic to the corresponding ''​zone_//​name//​_input''​ chains | +
-| :::    | ''​input_rule'' ​               | user     | Container chain for custom user input rules (firewall.user) | +
-| :::    | ''​syn_flood'' ​                | internal | Internal chain to match and drop syn flood attempts | +
-| :::    | ''​zone_//​name//​_input'' ​      | internal | Per-zone container chains for input rules | +
-| :::    | ''​input_//​name//​_rule'' ​      | user     | Per-zone container chains for custom user input rules (firewall.user) | +
- +
-==== OUTPUT (originating from router) ==== +
- +
-^ Table  ^ Chain                         ^ Type     ^ Description ^ +
-| raw    | ''​OUTPUT'' ​                   | system ​  | | +
-| mangle | ''​OUTPUT'' ​                   | system ​  | | +
-| nat    | ''​OUTPUT'' ​                   | system ​  | | +
-| filter | ''​OUTPUT'' ​                   | system ​  | | +
-| :::    | ''​delegate_output'' ​          | internal | Internal chain to hold toplevel output rules, dispatches traffic to the corresponding ''​zone_//​name//​_output''​ chains | +
-| :::    | ''​output_rule'' ​              | user     | Container chain for custom user output rules (firewall.user) | +
-| :::    | ''​zone_//​name//​_output'' ​     | internal | Per-zone container chains for output rules | +
-| :::    | ''​output_//​name//​_rule'' ​     | user     | Per-zone container chains for custom user output rules (firewall.user) | +
-| mangle | ''​POSTROUTING'' ​              | system ​  | | +
-| nat    | ''​POSTROUTING'' ​              | system ​  | | +
-| :::    | ''​delegate_postrouting'' ​     | internal | Internal chain to hold toplevel postrouting rules, dispatches traffic to the corresponding ''​zone_//​name//​_postrouting''​ chains | +
-| :::    | ''​postrouting_rule'' ​         | user     | Container chain for custom user postrouting rules (firewall.user) | +
-| :::    | ''​zone_//​name//​_postrouting''​ | internal | Per-zone container chains for postrouting rules (masq, snat) | +
-| :::    | ''​postrouting_//​name//​_rule''​ | user     | Per-zone container chains for custom user postrouting rules (firewall.user) | +
- +
-==== FORWARD (relayed through router) ====+
  
-^ Table  ^ Chain                         ^ Type     ^ Description ^ +The ''​uci'' ​utility is useful ​to view the firewall ​configuration but not to do any meaningful 
-| raw    | ''​PREROUTING'' ​               | system ​  | | +modifications ​for the following reasons:
-| :::    | ''​notrack'' ​                  | internal | Internal chain for NOTRACK rules |  +
-| mangle | ''​PREROUTING'' ​               | system ​  | | +
-| :::    | ''​fwmark'' ​                   | internal | Internal chain for MARK rules | +
-| nat    | ''​PREROUTING'' ​               | system ​  | | +
-| :::    | ''​delegate_prerouting'' ​      | internal | Internal chain to hold toplevel prerouting rules, dispatches traffic ​to the corresponding ''​zone_//​name//​_prerouting''​ chains |  +
-| :::    | ''​prerouting_rule'' ​          | user     | Container chain for custom user prerouting rules (firewall.user) | +
-| :::    | ''​zone_//​name//​_prerouting'' ​ | internal | Per-zone container chains for DNAT (port forwarding) rules | +
-| :::    | ''​prerouting_//​name//​_rule'' ​ | user     | Per-zone container chains for custom user prerouting rules (firewall.user) | +
-| mangle | ''​FORWARD'' ​                  | system ​  | | +
-| :::    | ''​mssfix'' ​                   | internal | Internal chain to hold for TCPMSS rules (mtu_fix) | +
-| filter | ''​FORWARD'' ​                  | system ​  | | +
-| :::    | ''​delegate_forward'' ​         | internal | Internal chain to hold toplevel forward rules, dispatches traffic to the corresponding ''​zone_//​name//​_forward''​ chains | +
-| :::    | ''​forwarding_rule'' ​          | user     | Container chain for custom user forward rules (firewall.user) | +
-| :::    | ''​zone_//​name//​_forward'' ​    | internal | Per-zone container chains for output rules | +
-| :::    | ''​forwarding_//​name//​_rule'' ​ | user     | Per-zone container chains for custom user forward rules (firewall.user) | +
-| mangle | ''​POSTROUTING'' ​              | system ​  | | +
-| nat    | ''​POSTROUTING'' ​              | system ​  | | +
-| :::    | ''​delegate_postrouting'' ​     | internal | Internal chain to hold toplevel postrouting rules, dispatches traffic to the corresponding ''​zone_//​name//​_postrouting''​ chains | +
-:::    | ''​postrouting_rule'' ​         | user     | Container chain for custom user postrouting rules (firewall.user) | +
-| :::    | ''​zone_//​name//​_postrouting''​ | internal | Per-zone container chains for postrouting rules (masq, snat) | +
-| :::    | ''​postrouting_//​name//​_rule''​ | user     | Per-zone container chains for custom user postrouting rules (firewall.user) |+
  
-===== Augmented Explanations For Options ​====== +  * Essentially prior knowledge of where a firewall rule needs to go into the rule array in order make it work.  If the rule above were at index=1 not much would work. 
-==== '​enabled'​ option ==== +  * The utility does not recognized content of ''/​etc/​firewall.user''​. 
-The **enabled** option ​is defined for each functional section and defaulted ​to //true//.  To override it add ''​option enabled '​0'​ '' ​to a particular rule (or toggle ​the LuCI Traffic Rule **enabled** checkbox.)+  * The 'uci commit'​ operation is necessary to save the changes but still 
 +    needs '/​etc/​init.d/​firewall restart'​ to reload new tables. 
 +   
 +===== Firewall Management through LuCI ===== 
 +[[docs:​guide-user:​luci:​start|LuCI]] ​is a good mechanism ​to view and modify the firewall configuration. 
 +It is located under //Network -> Firewall// and maps closely to the configuration file sections. 
 +It takes a little longer ​to modify the firewall configuration but has higher level of 
 +organization than the config files.
  
-It is very useful to add a rule but not enable it immediately. ​ For example, to disable SSH access from a particular device on the WAN-side intranet of the router to devices on the LAN-side. It's probably better to use a MAC address instead of IPv4.+Make changes and reload using ''Save & Apply''​ button.
  
-''​ +:!: LuCI will remove all '#' ​lines from '/etc/config/firewall'!
-config ​rule                                  +
-        option src '​wan' ​                    +
-        option dest '​lan' ​                   +
-        option proto '​tcp' ​                  +
-        option dest_port '​22' ​               +
-        option src_ip '​192.168.3.171' ​       +
-        option target '​REJECT' ​              +
-        option name '​REJECT-SSH-WANSTA-LAN'​ +
-        option enabled '​0'​  +
-''+
  
docs/guide-user/firewall/firewall_configuration.1533743087.txt.gz · Last modified: 2018/08/08 15:44 (external edit)