################################################################################ This documentation provides a quick reference to the configuration files. Please refer to http://www.shorewall.net/Documentation_Index.html for the complete Shorewall documentation. Copyright © 2006 Thomas M. Eastep Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover, and with no Back-Cover Texts. ################################################################################ /etc/shorewall/accounting Accounting rules exist simply to count packets and bytes in categories that you define in this file. You may display these rules and their packet and byte counters using the "shorewall show accounting" command. Please see http://shorewall.net/Accounting.html for examples and additional information about how to use this file. Columns are: ACTION - What to do when a match is found. COUNT - Simply count the match and continue with the next rule DONE - Count the match and don't attempt to match any other accounting rules in the chain specified in the CHAIN column. [:COUNT] - Where is the name of a chain. Shorewall will create the chain automatically if it doesn't already exist. Causes a jump to that chain. If :COUNT is including, a counting rule matching this record will be added to CHAIN - The name of a chain. If specified as "-" the 'accounting' chain is assumed. This is the chain where the accounting rule is added. The chain will be created if it doesn't already exist. SOURCE - Packet Source The name of an interface, an address (host or net) or an interface name followed by ":" and a host or net address. DESTINATION - Packet Destination Format the same as the SOURCE column. PROTOCOL A protocol name (from /etc/protocols), a protocol number, "ipp2p", "ipp2p:udp" or "ipp2p:all" DEST PORT(S) Destination Port number. If the PROTOCOL is "ipp2p" then this column must contain an ipp2p option ("iptables -m ipp2p --help") without the leading "--". If no option is given in this column, "ipp2p" is assumed. Service name from /etc/services or port number. May only be specified if the protocol is TCP or UDP (6 or 17). You may place a comma-separated list of port numbers in this column if your kernel and iptables include multiport match support. SOURCE PORT(S) Source Port number Service name from /etc/services or port number. May only be specified if the protocol is TCP or UDP (6 or 17). You may place a comma-separated list of port numbers in this column if your kernel and iptables include multiport match support. USER/GROUP This column may only be non-empty if the CHAIN is OUTPUT. The column may contain: [!][][:][+] When this column is non-empty, the rule applies only if the program generating the output is running under the effective and/or specified (or is NOT running under that id if "!" is given). Examples: joe #program must be run by joe :kids #program must be run by a member of #the 'kids' group !:kids #program must not be run by a member #of the 'kids' group +upnpd #program named upnpd (This feature was #removed from Netfilter in kernel #version 2.6.14). In all of the above columns except ACTION and CHAIN, the values "-", "any" and "all" may be used as wildcards. Omitted trailing columns are also treated as wildcards. Please see http://shorewall.net/Accounting.html for examples and additional information about how to use this file. ################################################################################ /etc/shorewall/blacklist This file contains a list of IP addresses, MAC addresses and/or subnetworks. Columns are: ADDRESS/SUBNET - Host address, subnetwork, MAC address, IP address range (if your kernel and iptables contain iprange match support) or ipset name prefaced by "+" (if your kernel supports ipset match). MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 A dash ("-") in this column means that any source address will match. This is useful if you want to blacklist a particular application. PROTOCOL - Optional. If specified, must be a protocol number or a protocol name from /etc/protocols. PORTS - Optional. May only be specified if the protocol is TCP (6) or UDP (17). A comma-separated list of destination port numbers or service names from /etc/services. When a packet arrives on an interface that has the 'blacklist' option specified in /etc/shorewall/interfaces, its source IP address is checked against this file and disposed of according to the BLACKLIST_DISPOSITION and BLACKLIST_LOGLEVEL variables in /etc/shorewall/shorewall.conf If PROTOCOL or PROTOCOL and PORTS are supplied, only packets matching the protocol (and one of the ports if PORTS supplied) are blocked. Example: To block DNS queries from address 192.0.2.126: ADDRESS/SUBNET PROTOCOL PORT 192.0.2.126 udp 53 Example: To block DNS queries from addresses in the ipset 'dnsblack': ADDRESS/SUBNET PROTOCOL PORT +dnsblack udp 53 Please see http://shorewall.net/blacklisting_support.htm for additional information. ################################################################################ /etc/shorewall/ecn Use this file to list the destinations for which you want to disable ECN. This feature requires kernel 2.4.20 or later. If you run 2.4.20, you also need the patch found at http://www.shorewall.net/ecn/patch. That patch is included in kernels 2.4.21 and later. INTERFACE - Interface through which host(s) communicate with the firewall HOST(S) - (Optional) Comma-separated list of IP/subnet If left empty or supplied as "-", 0.0.0.0/0 is assumed. If your kernel and iptables include iprange match support then IP address ranges are also permitted. For additional information, see http://shorewall.net/Documentation.htm#ECN ################################################################################ /etc/shorewall/hosts THE ONLY TIME YOU NEED THIS FILE IS WHERE YOU HAVE MORE THAN ONE ZONE CONNECTED THROUGH A SINGLE INTERFACE. IF YOU DON'T HAVE THAT SITUATION THEN DON'T TOUCH THIS FILE. ------------------------------------------------------------------------------ IF YOU HAVE AN ENTRY FOR A ZONE AND INTERFACE IN /etc/shorewall/interfaces THEN DO NOT ADD ANY ENTRIES FOR THAT ZONE AND INTERFACE IN THIS FILE. ------------------------------------------------------------------------------ This file is used to define zones in terms of subnets and/or individual IP addresses. Most simple setups don't need to (should not) place anything in this file. The order of entries in this file is not significant in determining zone composition. Rather, the order that the zones are defined in /etc/shorewall/zones determines the order in which the records in this file are interpreted. ZONE - The name of a zone defined in /etc/shorewall/zones. You may not list the firewall zone in this column. HOST(S) - The name of an interface defined in the /etc/shorewall/interfaces file followed by a colon (":") and a comma-separated list whose elements are either: a) The IP address of a host b) A subnetwork in the form / c) An IP address range of the form -. Your kernel and iptables must have iprange match support. d) A physical port name; only allowed when the interface names a bridge created by the brctl addbr command. This port must not be defined in /etc/shorewall/interfaces and may optionally followed by a colon (":") and a host or network IP or a range. See http://www.shorewall.net/bridge.html for details. Specifying a physical port name requires that you have BRIDGING=Yes in /etc/shorewall/shorewall.conf. e) The name of an ipset (preceded by "+"). Examples: eth1:192.168.1.3 eth2:192.168.2.0/24 eth3:192.168.2.0/24,192.168.3.1 br0:eth4 br0:eth0:192.168.1.16/28 eth4:192.168.1.44-192.168.1.49 eth2:+Admin OPTIONS - A comma-separated list of options. Currently-defined options are: maclist - Connection requests from these hosts are compared against the contents of /etc/shorewall/maclist. If this option is specified, the interface must be an ethernet NIC and must be up before Shorewall is started. routeback - Shorewall should set up the infrastructure to pass packets from this/these address(es) back to themselves. This is necessary if hosts in this group use the services of a transparent proxy that is a member of the group or if DNAT is used to send requests originating from this group to a server in the group. norfc1918 - This option only makes sense for ports on a bridge. The port should not accept any packets whose source is in one of the ranges reserved by RFC 1918 (i.e., private or "non-routable" addresses. If packet mangling or connection-tracking match is enabled in your kernel, packets whose destination addresses are reserved by RFC 1918 are also rejected. blacklist - This option only makes sense for ports on a bridge. Check packets arriving on this port against the /etc/shorewall/blacklist file. tcpflags - Packets arriving from these hosts are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL. nosmurfs - This option only makes sense for ports on a bridge. Filter packets for smurfs (packets with a broadcast address as the source). Smurfs will be optionally logged based on the setting of SMURF_LOG_LEVEL in shorewall.conf. After logging, the packets are dropped. ipsec - The zone is accessed via a kernel 2.6 ipsec SA. Note that if the zone named in the ZONE column is specified as an IPSEC zone in the /etc/shorewall/zones file then you do NOT need to specify the 'ipsec' option here. For additional information, see http://shorewall.net/Documentation.htm#Hosts ################################################################################ /etc/shorewall/interfaces You must add an entry in this file for each network interface on your firewall system. Columns are: ZONE Zone for this interface. Must match the name of a zone defined in /etc/shorewall/zones. You may not list the firewall zone in this column. If the interface serves multiple zones that will be defined in the /etc/shorewall/hosts file, you should place "-" in this column. If there are multiple interfaces to the same zone, you must list them in separate entries: Example: loc eth1 - loc eth2 - INTERFACE Name of interface. Each interface may be listed only once in this file. You may NOT specify the name of an alias (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18 You may specify wildcards here. For example, if you want to make an entry that applies to all PPP interfaces, use 'ppp+'. There is no need to define the loopback interface (lo) in this file. BROADCAST The broadcast address for the subnetwork to which the interface belongs. For P-T-P interfaces, this column is left blank.If the interface has multiple addresses on multiple subnets then list the broadcast addresses as a comma-separated list. If you use the special value "detect", Shorewall will detect the broadcast address(es) for you. If you select this option, the interface must be up before the firewall is started. If you don't want to give a value for this column but you want to enter a value in the OPTIONS column, enter "-" in this column. OPTIONS A comma-separated list of options including the following: dhcp - Specify this option when any of the following are true: 1. the interface gets its IP address via DHCP 2. the interface is used by a DHCP server running on the firewall 3. you have a static IP but are on a LAN segment with lots of Laptop DHCP clients. 4. the interface is a bridge with a DHCP server on one port and DHCP clients on another port. norfc1918 - This interface should not receive any packets whose source is in one of the ranges reserved by RFC 1918 (i.e., private or "non-routable" addresses). If packet mangling or connection-tracking match is enabled in your kernel, packets whose destination addresses are reserved by RFC 1918 are also rejected. routefilter - turn on kernel route filtering for this interface (anti-spoofing measure). This option can also be enabled globally in the /etc/shorewall/shorewall.conf file. logmartians - turn on kernel martian logging (logging of packets with impossible source addresses. It is suggested that if you set routefilter on an interface that you also set logmartians. This option may also be enabled globally in the /etc/shorewall/shorewall.conf file. blacklist - Check packets arriving on this interface against the /etc/shorewall/blacklist file. maclist - Connection requests from this interface are compared against the contents of /etc/shorewall/maclist. If this option is specified, the interface must be an ethernet NIC and must be up before Shorewall is started. tcpflags - Packets arriving on this interface are checked for certain illegal combinations of TCP flags. Packets found to have such a combination of flags are handled according to the setting of TCP_FLAGS_DISPOSITION after having been logged according to the setting of TCP_FLAGS_LOG_LEVEL. proxyarp - Sets /proc/sys/net/ipv4/conf//proxy_arp. Do NOT use this option if you are employing Proxy ARP through entries in /etc/shorewall/proxyarp. This option is intended soley for use with Proxy ARP sub-networking as described at: http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet routeback - If specified, indicates that Shorewall should include rules that allow filtering traffic arriving on this interface back out that same interface. arp_filter - If specified, this interface will only respond to ARP who-has requests for IP addresses configured on the interface. If not specified, the interface can respond to ARP who-has requests for IP addresses on any of the firewall's interface. The interface must be up when Shorewall is started. arp_ignore[=] - If specified, this interface will respond to arp requests based on the value of . 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 4-7 - reserved 8 - do not reply for all local addresses If no is given then the value 1 is assumed WARNING -- DO NOT SPECIFY arp_ignore FOR ANY INTERFACE INVOLVED IN PROXY ARP. nosmurfs - Filter packets for smurfs (packets with a broadcast address as the source). Smurfs will be optionally logged based on the setting of SMURF_LOG_LEVEL in shorewall.conf. After logging, the packets are dropped. detectnets - Automatically taylors the zone named in the ZONE column to include only those hosts routed through the interface. sourceroute - If this option is not specified for an interface, then source-routed packets will not be accepted from that interface (sets /proc/sys/net/ipv4/ conf// accept_source_route to 1). Only set this option if you know what you are you doing. This might represent a security risk and is not usually needed. upnp - Incoming requests from this interface may be remapped via UPNP (upnpd). WARNING: DO NOT SET THE detectnets OPTION ON YOUR INTERNET INTERFACE. The order in which you list the options is not significant but the list should have no embedded white space. Example 1: Suppose you have eth0 connected to a DSL modem and eth1 connected to your local network and that your local subnet is 192.168.1.0/24. The interface gets it's IP address via DHCP from subnet 206.191.149.192/27. You have a DMZ with subnet 192.168.2.0/24 using eth2. Your entries for this setup would look like: net eth0 206.191.149.223 dhcp local eth1 192.168.1.255 dmz eth2 192.168.2.255 Example 2: The same configuration without specifying broadcast addresses is: net eth0 detect dhcp loc eth1 detect dmz eth2 detect Example 3: You have a simple dial-in system with no ethernet connections. net ppp0 - For additional information, see http://shorewall.net/Documentation.htm#Interfaces ################################################################################ /etc/shorewall/maclist This file is used to define the MAC addresses and optionally their associated IP addresses to be allowed to use the specified interface. The feature is enabled by using the maclist option in the interfaces or hosts configuration file. Columns are: DISPOSITION ACCEPT or DROP (if MACLIST_TABLE=filter, then REJECT is also allowed) INTERFACE Network interface to a host. If the interface names a bridge, it may be optionally followed by a colon (":") and a physical port name (e.g., br0:eth4). MAC MAC address of the host -- you do not need to use the Shorewall format for MAC addresses here. If IP ADDRESSES is supplied then MAC can be supplied as a dash ("-") IP ADDRESSES Optional -- if specified, both the MAC and IP address must match. This column can contain a comma-separated list of host and/or subnet addresses. If your kernel and iptables have iprange match support then IP address ranges are also allowed. For additional information, see http://shorewall.net/MAC_Validation.html ################################################################################ /etc/shorewall/masq Use this file to define dynamic NAT (Masquerading) and to define Source NAT (SNAT). WARNING: The entries in this file are order-sensitive. The first entry that matches a particular connection will be the one that is used. WARNING: If you have more than one ISP, adding entries to this file will *not* force connections to go out through a particular ISP. You must use PREROUTING entries in /etc/shorewall/tcrules to do that. Columns are: INTERFACE -- Outgoing interface. This is usually your internet interface. If ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf, you may add ":" and a digit to indicate that you want the alias added with that name (e.g., eth0:0). This will allow the alias to be displayed with ifconfig. THAT IS THE ONLY USE FOR THE ALIAS NAME AND IT MAY NOT APPEAR IN ANY OTHER PLACE IN YOUR SHOREWALL CONFIGURATION. This may be qualified by adding the character ":" followed by a destination host or subnet. If you wish to inhibit the action of ADD_SNAT_ALIASES for this entry then include the ":" but omit the digit: eth0: eth2::192.0.2.32/27 Normally Masq/SNAT rules are evaluated after those for one-to-one NAT (/etc/shorewall/nat file). If you want the rule to be applied before one-to-one NAT rules, prefix the interface name with "+": +eth0 +eth0:192.0.2.32/27 +eth0:2 This feature should only be required if you need to insert rules in this file that preempt entries in /etc/shorewall/nat. If you place COMMENT in this column, then the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entry. The comment will appear delimited by "/* ... */" in the output of "shorewall show nat" SOURCE (formerly called SUBNET) Set of hosts that you wish to masquerade. You can specify this as an address (net or host) or as an interface. If you give the name of an interface, the interface must be up before you start the firewall (Shorewall will use your main routing table to determine the appropriate addresses to masquerade). In order to exclude a addrress of the specified SOURCE, you may append "!" and a comma-separated list of IP addresses (host or net) that you wish to exclude. Example: eth1!192.168.1.4,192.168.32.0/27 In that example traffic from eth1 would be masqueraded unless it came from 192.168.1.4 or 196.168.32.0/27 ADDRESS -- (Optional). If you specify an address here, SNAT will be used and this will be the source address. If ADD_SNAT_ALIASES is set to Yes or yes in /etc/shorewall/shorewall.conf then Shorewall will automatically add this address to the INTERFACE named in the first column. You may also specify a range of up to 256 IP addresses if you want the SNAT address to be assigned from that range in a round-robin range by connection. The range is specified by -. Example: 206.124.146.177-206.124.146.180 You may also use the special value "detect" which causes Shorewall to determine the IP addresses configured on the interface named in the INTERFACES column and substitute them in this column. Finally, you may also specify a comma-separated list of ranges and/or addresses in this column. This column may not contain DNS Names. Normally, Netfilter will attempt to retain the source port number. You may cause netfilter to remap the source port by following an address or range (if any) by ":" and a port range with the format - . If this is done, you must specify "tcp" or "udp" in the PROTO column. Examples: 192.0.2.4:5000-6000 :4000-5000 You can invoke the SAME target using the following in this column: SAME:[nodst:][,...] The may be single addresses or "detect" as described above. SAME works like SNAT with the exception that the same local IP address is assigned to each connection from a local address to a given remote address. If the 'nodst:' option is included, then the same source address is used for a given internal system regardless of which remote system is involved. If you want to leave this column empty but you need to specify the next column then place a hyphen ("-") here. PROTO -- (Optional) If you wish to restrict this entry to a particular protocol then enter the protocol name (from /etc/protocols) or number here. PORT(S) -- (Optional) If the PROTO column specifies TCP (protocol 6) or UDP (protocol 17) then you may list one or more port numbers (or names from /etc/services) separated by commas or you may list a single port range (:). Where a comma-separated list is given, your kernel and iptables must have multiport match support and a maximum of 15 ports may be listed. IPSEC -- (Optional) If you specify a value other than "-" in this column, you must be running kernel 2.6 and your kernel and iptables must include policy match support. Comma-separated list of options from the following. Only packets that will be encrypted via an SA that matches these options will have their source address changed. Yes or yes -- must be the only option listed and matches all outbound traffic that will be encrypted. reqid= where is specified using setkey(8) using the 'unique: option for the SPD level. spi= where is the SPI of the SA. proto=ah|esp|ipcomp mode=transport|tunnel tunnel-src=
[/] (only available with mode=tunnel) tunnel-dst=
[/] (only available with mode=tunnel) strict Means that packets must match all rules. next Separates rules; can only be used with strict.. Example 1: You have a simple masquerading setup where eth0 connects to a DSL or cable modem and eth1 connects to your local network with subnet 192.168.0.0/24. Your entry in the file can be either: eth0 eth1 or eth0 192.168.0.0/24 Example 2: You add a router to your local network to connect subnet 192.168.1.0/24 which you also want to masquerade. You then add a second entry for eth0 to this file: eth0 192.168.1.0/24 Example 3: You have an IPSEC tunnel through ipsec0 and you want to masquerade packets coming from 192.168.1.0/24 but only if these packets are destined for hosts in 10.1.1.0/24: ipsec0:10.1.1.0/24 196.168.1.0/24 Example 4: You want all outgoing traffic from 192.168.1.0/24 through eth0 to use source address 206.124.146.176 which is NOT the primary address of eth0. You want 206.124.146.176 added to be added to eth0 with name eth0:0. eth0:0 192.168.1.0/24 206.124.146.176 Example 5: You want all outgoing SMTP traffic entering the firewall on eth1 to be sent from eth0 with source IP address 206.124.146.177. You want all other outgoing traffic from eth1 to be sent from eth0 with source IP address 206.124.146.176. eth0 eth1 206.124.146.177 tcp smtp eth0 eth1 206.124.146.176 THE ORDER OF THE ABOVE TWO RULES IS SIGNIFICANT!!!!! For additional information, see http://shorewall.net/Documentation.htm#Masq ################################################################################ /etc/shorewall/nat This file is used to define one-to-one Network Address Translation (NAT). WARNING: If all you want to do is simple port forwarding, do NOT use this file. See http://www.shorewall.net/FAQ.htm#faq1. Also, in most cases, Proxy ARP is a better solution that one-to-one NAT. Columns are: EXTERNAL External IP Address - this should NOT be the primary IP address of the interface named in the next column and must not be a DNS Name. If you put COMMENT in this column, the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries in the file. The comment will appear delimited by "/* ... */" in the output of "shorewall show nat" To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. INTERFACE Interface that has the EXTERNAL address. If ADD_IP_ALIASES=Yes in shorewall.conf, Shorewall will automatically add the EXTERNAL address to this interface. Also if ADD_IP_ALIASES=Yes, you may follow the interface name with ":" and a digit to indicate that you want Shorewall to add the alias with this name (e.g., "eth0:0"). That allows you to see the alias with ifconfig. THAT IS THE ONLY THING THAT THIS NAME IS GOOD FOR -- YOU CANNOT USE IT ANYWHERE ELSE IN YOUR SHORWALL CONFIGURATION. If you want to override ADD_IP_ALIASES=Yes for a particular entry, follow the interface name with ":" and no digit (e.g., "eth0:"). INTERNAL Internal Address (must not be a DNS Name). ALL INTERFACES If Yes or yes, NAT will be effective from all hosts. If No or no (or left empty) then NAT will be effective only through the interface named in the INTERFACE column LOCAL If Yes or yes, NAT will be effective from the firewall system For additional information, see http://shorewall.net/NAT.htm ################################################################################ /etc/shorewall/netmap This file is used to map addresses in one network to corresponding addresses in a second network. WARNING: To use this file, your kernel and iptables must have NETMAP support included. Columns are: TYPE Must be DNAT or SNAT. If DNAT, traffic entering INTERFACE and addressed to NET1 has it's destination address rewritten to the corresponding address in NET2. If SNAT, traffic leaving INTERFACE with a source address in NET1 has it's source address rewritten to the corresponding address in NET2. NET1 Network in CIDR format (e.g., 192.168.1.0/24) INTERFACE The name of a network interface. The interface must be defined in /etc/shorewall/interfaces. NET2 Network in CIDR format See http://shorewall.net/netmap.html for an example and usage information. ################################################################################ /etc/shorewall/policy THE ORDER OF ENTRIES IN THIS FILE IS IMPORTANT This file determines what to do with a new connection request if we don't get a match from the /etc/shorewall/rules file . For each source/destination pair, the file is processed in order until a match is found ("all" will match any client or server). INTRA-ZONE POLICIES ARE PRE-DEFINED For $FW and for all of the zoned defined in /etc/shorewall/zones, the POLICY for connections from the zone to itself is ACCEPT (with no logging or TCP connection rate limiting but may be overridden by an entry in this file. The overriding entry must be explicit (cannot use "all" in the SOURCE or DEST). Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf, then the implicit policy to/from any sub-zone is CONTINUE. These implicit CONTINUE policies may also be overridden by an explicit entry in this file. Columns are: SOURCE Source zone. Must be the name of a zone defined in /etc/shorewall/zones, $FW or "all". DEST Destination zone. Must be the name of a zone defined in /etc/shorewall/zones, $FW or "all" POLICY Policy if no match from the rules file is found. Must be "ACCEPT", "DROP", "REJECT", "CONTINUE" or "NONE". ACCEPT - Accept the connection DROP - Ignore the connection request REJECT - For TCP, send RST. For all other, send "port unreachable" ICMP. QUEUE - Send the request to a user-space application using the QUEUE target. CONTINUE - Pass the connection request past any other rules that it might also match (where the source or destination zone in those rules is a superset of the SOURCE or DEST in this policy). NONE - Assume that there will never be any packets from this SOURCE to this DEST. Shorewall will not set up any infrastructure to handle such packets and you may not have any rules with this SOURCE and DEST in the /etc/shorewall/rules file. If such a packet _is_ received, the result is undefined. NONE may not be used if the SOURCE or DEST columns contain the firewall zone ($FW) or "all". If the policy is DROP or REJECT then the policy should be followed by ":" and one of the following: a) The word "None" or "none". This causes any default action defined in /etc/shorewall/shorewall.conf to be omitted for this policy. b) The name of an action (requires that USE_ACTIONS=Yes in shorewall.conf). That action will be invoked before the policy is enforced. c) The name of a macro. The rules in that macro will be applied before the policy is enforced. This does not require USE_ACTIONS=Yes. LOG LEVEL If supplied, each connection handled under the default POLICY is logged at that level. If not supplied, no log message is generated. See syslog.conf(5) for a description of log levels. Beginning with Shorewall version 1.3.12, you may also specify ULOG (must be in upper case). This will log to the ULOG target and sent to a separate log through use of ulogd (http://www.gnumonks.org/projects/ulogd). If you don't want to log but need to specify the following column, place "-" here. LIMIT:BURST If passed, specifies the maximum TCP connection rate and the size of an acceptable burst. If not specified, TCP connections are not limited. Example: a) All connections from the local network to the internet are allowed b) All connections from the internet are ignored but logged at syslog level KERNEL.INFO. d) All other connection requests are rejected and logged at level KERNEL.INFO. #SOURCE DEST POLICY LOG # LEVEL loc net ACCEPT net all DROP info # # THE FOLLOWING POLICY MUST BE LAST # all all REJECT info See http://shorewall.net/Documentation.htm#Policy for additional information. ################################################################################ /etc/shorewall/providers This file is used to define additional routing tables. You will want to define an additional table if: - You have connections to more than one ISP or multiple connections to the same ISP - You run Squid as a transparent proxy on a host other than the firewall. To omit a column, enter "-". Columns are: NAME The provider name. Must be a valid shell variable name. The names 'local', 'main', 'default' and 'unspec' are reserved and may not be used as provider names. NUMBER The provider number -- a number between 1 and 15 MARK A FWMARK value used in your /etc/shorewall/tcrules file to direct packets to this provider. If HIGH_ROUTE_MARKS=Yes in shorewall.conf, then the value must be a multiple of 256 between 256 and 65280 or their hexadecimal equivalents (0x0100 and 0xff00 with the low-order byte of the value being zero). Otherwise, the value must be between 1 and 255. DUPLICATE The name of an existing table to duplicate. May be 'main' or the name of a previous provider. INTERFACE The name of the network interface to the provider. Must be listed in /etc/shorewall/interfaces. GATEWAY The IP address of the provider's gateway router. You can enter "detect" here and Shorewall will attempt to detect the gateway automatically. [ EXPERIMENTAL ] For PPP devices, you may omit this column. OPTIONS A comma-separated list selected from the following: track If specified, inbound connections on this interface are to be tracked so that responses may be routed back out this same interface. You want to specify 'track' if internet hosts will be connecting to local servers through this provider. balance The providers that have 'balance' specified will get outbound traffic load-balanced among them. By default, all interfaces with 'balance' specified will have the same weight (1). You can change the weight of an interface by specifiying balance= where is the weight of the route out of this interface. loose Shorewall normally adds a routing rule for each IP address on an interface which forces traffic whose source is that IP address to be sent using the routing table for that interface. Setting 'loose' prevents creation of such rules on this interface. optional If the interface named in the INTERFACE column is not up and configured with an IPv4 address then ignore this provider. COPY A comma-separated lists of other interfaces on your firewall. Only makes sense when DUPLICATE is 'main'. Only copy routes through INTERFACE and through interfaces listed here. If you only wish to copy routes through INTERFACE, enter 'none' here. Example: You run squid in your DMZ on IP address 192.168.2.99. Your DMZ interface is eth2 #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS Squid 1 1 - eth2 192.168.2.99 - Example: eth0 connects to ISP 1. The IP address of eth0 is 206.124.146.176 and the ISP's gateway router has IP address 206.124.146.254. eth1 connects to ISP 2. The IP address of eth1 is 130.252.99.27 and the ISP's gateway router has IP address 130.252.99.254. eth2 connects to a local network. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY ISP1 1 1 main eth0 206.124.146.254 track,balance eth2 ISP2 2 2 main eth1 130.252.99.254 track,balance eth2 See http://www.shorewall.net/MultiISP.html for additional information. ################################################################################ /etc/shorewall/proxyarp This file is used to define Proxy ARP. Columns are: ADDRESS IP Address INTERFACE Local interface where system is connected. EXTERNAL External Interface to be used to access this system HAVEROUTE If there is already a route from the firewall to the host whose address is given, enter "Yes" or "yes" in this column. Otherwise, entry "no", "No" or leave the column empty and Shorewall will add the route for you. If Shorewall adds the route,the route will be persistent if the PERSISTENT column contains Yes; otherwise, "shorewall stop" or "shorewall clear" will delete the route. PERSISTENT If HAVEROUTE is No or "no", then the value of this column determines if the route added by Shorewall persists after a "shorewall stop" or a "shorewall clear". If this column contains "Yes" or "yes" then the route persists; If the column is empty or contains "No"or "no" then the route is deleted at "shorewall stop" or "shorewall clear". Example: Host with IP 155.186.235.6 is connected to interface eth1 and we want hosts attached via eth0 to be able to access it using that address. #ADDRESS INTERFACE EXTERNAL 155.186.235.6 eth1 eth0 See http://shorewall.net/ProxyARP.htm for additional information. ################################################################################ /etc/shorewall/rfc1918 Lists the subnetworks that are blocked by the 'norfc1918' interface option. The default list includes those IP addresses listed in RFC 1918. DO NOT MODIFY THIS FILE. IF YOU NEED TO MAKE CHANGES, COPY THE FILE TO /etc/shorewall AND MODIFY THE COPY. Columns are: SUBNETS A comma-separated list of subnet addresses (host addresses also allowed as are IP address ranges provided that your kernel and iptables have iprange match support). TARGET Where to send packets to/from this subnet RETURN - let the packet be processed normally DROP - silently drop the packet logdrop - log then drop By default, the RETURN target causes 'norfc1918' processing to cease for a packet if the packet's source IP address matches the rule. Thus, if you have: SUBNETS TARGET 192.168.1.0/24 RETURN then traffic from 192.168.1.4 to 10.0.3.9 will be accepted even though you also have: SUBNETS TARGET 10.0.0.0/8 logdrop Setting RFC1918_STRICT=Yes in shorewall.conf will cause such traffic to be logged and dropped since while the packet's source matches the RETURN rule, the packet's destination matches the 'logdrop' rule. ################################################################################ /etc/shorewall/route_rules Entries in this file cause traffic to be routed to one of the providers listed in /etc/shorewall/providers. Columns are: SOURCE(optional) An ip address (network or host) that matches the source IP address in a packet. May also be specified as an interface name optionally followed by ":" and an address. If the device 'lo' is specified, the packet must originate from the firewall itself. DEST(optional) An ip address (network or host) that matches the destination IP address in a packet. If you choose to omit either SOURCE or DEST, place "-" in that column. Note that you may not omit both SOURCE and DEST. PROVIDER The provider to route the traffic through. May be expressed either as the provider name or the provider number. May also be 'main' or 254 for the main routing table. This can be used in combination with VPN tunnels, see example 2 below. PRIORITY The rule's priority which determines the order in which the rules are processed. 1000-1999 Before Shorewall-generated 'MARK' rules 11000- 11999 After 'MARK' rules but before Shorewall-generated rules for ISP interfaces. 26000-26999 After ISP interface rules but before 'default' rule. Rules with equal priority are applied in the order in which they appear in the file. Example 1: You want all traffic coming in on eth1 to be routed to the ISP1 provider: #SOURCE DEST PROVIDER PRIORITY eth1 - ISP1 1000 Example 2: You use OpenVPN (routed setup /tunX) in combination with multiple providers. In this case you have to set up a rule to ensure that the OpenVPN traffic is routed back through the tunX interface(s) rather than through any of the providers. 10.8.0.0/24 is the subnet choosen in your OpenVPN configuration (server 10.8.0.0 255.255.255.0) #SOURCE DEST PROVIDER PRIORITY - 10.8.0.0/24 main 1000 For additional information, see http://www.shorewall.net/MultiISP.html ################################################################################ /etc/shorewall/routestopped This file is used to define the hosts that are accessible when the firewall is stopped or when it is in the process of being [re]started. Columns are: INTERFACE - Interface through which host(s) communicate with the firewall HOST(S) - (Optional) Comma-separated list of IP/subnet addresses. If your kernel and iptables include iprange match support, IP address ranges are also allowed. If left empty or supplied as "-", 0.0.0.0/0 is assumed. OPTIONS - (Optional) A comma-separated list of options. The currently-supported options are: routeback - Set up a rule to ACCEPT traffic from these hosts back to themselves. source - Allow traffic from these hosts to ANY destination. Without this option or the 'dest' option, only traffic from this host to other listed hosts (and the firewall) is allowed. If 'source' is specified then 'routeback' is redundant. dest - Allow traffic to these hosts from ANY source. Without this option or the 'source' option, only traffic from this host to other listed hosts (and the firewall) is allowed. If 'dest' is specified then 'routeback' is redundant. critical - Allow traffic between the firewall and these hosts throughout '[re]start', 'stop' and 'clear'. Specifying 'critical' on one or more entries will cause your firewall to be "totally open" for a brief window during each of those operations. NOTE: The 'source' and 'dest' options work best when used in conjunction with ADMINISABSENTMINDED=Yes in /etc/shorewall/shorewall.conf. Example: INTERFACE HOST(S) OPTIONS eth2 192.168.1.0/24 eth0 192.0.2.44 br0 - routeback eth3 - source See http://shorewall.net/Documentation.htm#Routestopped and http://shorewall.net/starting_and_stopping_shorewall.htm for additional information. ################################################################################ /etc/shorewall/rules Rules in this file govern connection establishment. Requests and responses are automatically allowed using connection tracking. For any particular (source,dest) pair of zones, the rules are evaluated in the order in which they appear in this file and the first match is the one that determines the disposition of the request. In most places where an IP address or subnet is allowed, you can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to indicate that the rule matches all addresses except the address/subnet given. Notice that no white space is permitted between "!" and the address/subnet. ------------------------------------------------------------------------------ WARNING: If you masquerade or use SNAT from a local system to the internet, you cannot use an ACCEPT rule to allow traffic from the internet to that system. You *must* use a DNAT rule instead. ------------------------------------------------------------------------------ The rules file is divided into sections. Each section is introduced by a "Section Header" which is a line beginning with SECTION followed by the section name. Sections are as follows and must appear in the order listed: ESTABLISHED Packets in the ESTABLISHED state are processed by rules in this section. The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE There is an implicit ACCEPT rule inserted at the end of this section. RELATED Packets in the RELATED state are processed by rules in this section. The only ACTIONs allowed in this section are ACCEPT, DROP, REJECT, LOG and QUEUE There is an implicit ACCEPT rule inserted at the end of this section. NEW Packets in the NEW and INVALID states are processed by rules in this section. Note: If you are not familiar with Netfilter to the point where you are comfortable with the differences between the various connection tracking states, then I suggest that you omit the ESTABLISHED and RELATED sections and place all of your rules in the NEW section (That's after the line that reads SECTION NEW'). WARNING: If you specify FASTACCEPT=Yes in shorewall.conf then the ESTABLISHED and RELATED sections must be empty. You may omit any section that you don't need. If no Section Headers appear in the file then all rules are assumed to be in the NEW section. Columns are: ACTION ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE, LOG, QUEUE, COMMENT, a , or an . ACCEPT -- allow the connection request ACCEPT+ -- like ACCEPT but also excludes the connection from any subsequent DNAT[-] or REDIRECT[-] rules NONAT -- Excludes the connection from any subsequent DNAT[-] or REDIRECT[-] rules but doesn't generate a rule to accept the traffic. DROP -- ignore the request REJECT -- disallow the request and return an icmp-unreachable or an RST packet. DNAT -- Forward the request to another system (and optionally another port). DNAT- -- Advanced users only. Like DNAT but only generates the DNAT iptables rule and not the companion ACCEPT rule. SAME -- Similar to DNAT except that the port may not be remapped and when multiple server addresses are listed, all requests from a given remote system go to the same server. SAME- -- Advanced users only. Like SAME but only generates the NAT iptables rule and not the companion ACCEPT rule. REDIRECT -- Redirect the request to a local port on the firewall. REDIRECT- -- Advanced users only. Like REDIRET but only generates the REDIRECT iptables rule and not the companion ACCEPT rule. CONTINUE -- (For experts only). Do not process any of the following rules for this (source zone,destination zone). If The source and/or destination IP address falls into a zone defined later in /etc/shorewall/zones, this connection request will be passed to the rules defined for that (those) zone(s). LOG -- Simply log the packet and continue. QUEUE -- Queue the packet to a user-space application such as ftwall (http://p2pwall.sf.net). COMMENT -- the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entres. The comment will appear delimited by "/* ... */" in the output of "shorewall show ". To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. -- The name of an action defined in /etc/shorewall/actions or in /usr/share/shorewall/actions.std. -- The name of a macro defined in a file named macro.. If the macro accepts an action parameter (Look at the macro source to see if it has PARAM in the TARGET column) then the macro name is followed by "/" and the action (ACCEPT, DROP, REJECT, ...) to be substituted for the parameter. Example: FTP/ACCEPT. The ACTION may optionally be followed by ":" and a syslog log level (e.g, REJECT:info or DNAT:debug). This causes the packet to be logged at the specified level. If the ACTION names an action defined in /etc/shorewall/actions or in /usr/share/shorewall/actions.std then: - If the log level is followed by "!' then all rules in the action are logged at the log level. - If the log level is not followed by "!" then only those rules in the action that do not specify logging are logged at the specified level. - The special log level 'none!' suppresses logging by the action. You may also specify ULOG (must be in upper case) as a log level.This will log to the ULOG target for routing to a separate log through use of ulogd (http://www.gnumonks.org/projects/ulogd). Actions specifying logging may be followed by a log tag (a string of alphanumeric characters) are appended to the string generated by the LOGPREFIX (in /etc/shorewall/shorewall.conf). Example: ACCEPT:info:ftp would include 'ftp ' at the end of the log prefix generated by the LOGPREFIX setting. SOURCE Source hosts to which the rule applies. May be a zone defined in /etc/shorewall/zones, $FW to indicate the firewall itself, "all", "all+", "all-", "all+-" or "none". When "none" is used either in the SOURCE or DEST column, the rule is ignored. "all" means "All Zones", including the firewall itself. "all-" means "All Zones, except the firewall itself". When "all[-]" is used either in the SOURCE or DEST column intra-zone traffic is not affected. When "all+[-]" is "used, intra-zone traffic is affected. Except when "all[+][-]" is specified, clients may be further restricted to a list of subnets and/or hosts by appending ":" and a comma-separated list of subnets and/or hosts. Hosts may be specified by IP or MAC address; mac addresses must begin with "~" and must use "-" as a separator. Hosts may be specified as an IP address range using the syntax -. This requires that your kernel and iptables contain iprange match support. If you kernel and iptables have ipset match support then you may give the name of an ipset prefaced by "+". The ipset name may be optionally followed by a number from 1 to 6 enclosed in square brackets ([]) to indicate the number of levels of source bindings to be matched. dmz:192.168.2.2 Host 192.168.2.2 in the DMZ net:155.186.235.0/24 Subnet 155.186.235.0/24 on the Internet loc:192.168.1.1,192.168.1.2 Hosts 192.168.1.1 and 192.168.1.2 in the local zone. loc:~00-A0-C9-15-39-78 Host in the local zone with MAC address 00:A0:C9:15:39:78. net:192.0.2.11-192.0.2.17 Hosts 192.0.2.11-192.0.2.17 in the net zone. Alternatively, clients may be specified by interface by appending ":" to the zone name followed by the interface name. For example, loc:eth1 specifies a client that communicates with the firewall system through eth1. This may be optionally followed by another colon (":") and an IP/MAC/subnet address as described above (e.g., loc:eth1:192.168.1.5). DEST Location of Server. May be a zone defined in /etc/shorewall/zones, $FW to indicate the firewall itself, "all". "all+" or "none". When "none" is used either in the SOURCE or DEST column, the rule is ignored. When "all" is used either in the SOURCE or DEST column intra-zone traffic is not affected. When "all+" is used, intra-zone traffic is affected. Except when "all[+]" is specified, the server may be further restricted to a particular subnet, host or interface by appending ":" and the subnet, host or interface. See above. Restrictions: 1. MAC addresses are not allowed. 2. In DNAT rules, only IP addresses are allowed; no FQDNs or subnet addresses are permitted. 3. You may not specify both an interface and an address. Like in the SOURCE column, you may specify a range of up to 256 IP addresses using the syntax -. When the ACTION is DNAT or DNAT-, the connections will be assigned to addresses in the range in a round-robin fashion. If you kernel and iptables have ipset match support then you may give the name of an ipset prefaced by "+". The ipset name may be optionally followed by a number from 1 to 6 enclosed in square brackets ([]) to indicate the number of levels of destination bindings to be matched. Only one of the SOURCE and DEST columns may specify an ipset name. The port that the server is listening on may be included and separated from the server's IP address by ":". If omitted, the firewall will not modifiy the destination port. A destination port may only be included if the ACTION is DNAT or REDIRECT. Example: loc:192.168.1.3:3128 specifies a local server at IP address 192.168.1.3 and listening on port 3128. The port number MUST be specified as an integer and not as a name from /etc/services. if the ACTION is REDIRECT, this column needs only to contain the port number on the firewall that the request should be redirected to. PROTO Protocol - Must be "tcp", "tcp:syn", "udp", "icmp", "ipp2p", "ipp2p:udp", "ipp2p:all" a number, or "all". "ipp2p*" requires ipp2p match support in your kernel and iptables. "tcp:syn" implies "tcp" plus the SYN flag must be set and the RST,ACK and FIN flags must be reset. DEST PORT(S) Destination Ports. A comma-separated list of Port names (from /etc/services), port numbers or port ranges; if the protocol is "icmp", this column is interpreted as the destination icmp-type(s). If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example "bit" for bit-torrent). If no port is given, "ipp2p" is assumed. A port range is expressed as :. This column is ignored if PROTOCOL = all but must be entered if any of the following ields are supplied. In that case, it is suggested that this field contain "-" If your kernel contains multi-port match support, then only a single Netfilter rule will be generated if in this list and the CLIENT PORT(S) list below: 1. There are 15 or less ports listed. 2. No port ranges are included. Otherwise, a separate rule will be generated for each port. SOURCE PORT(S) (Optional) Port(s) used by the client. If omitted, any source port is acceptable. Specified as a comma- separated list of port names, port numbers or port ranges. If you don't want to restrict client ports but need to specify an ORIGINAL DEST in the next column, then place "-" in this column. If your kernel contains multi-port match support, then only a single Netfilter rule will be generated if in this list and the DEST PORT(S) list above: 1. There are 15 or less ports listed. 2. No port ranges are included. Otherwise, a separate rule will be generated for each port. ORIGINAL DEST (0ptional) -- If ACTION is DNAT[-] or REDIRECT[-] then if included and different from the IP address given in the SERVER column, this is an address on some interface on the firewall and connections to that address will be forwarded to the IP and port specified in the DEST column. A comma-separated list of addresses may also be used. This is usually most useful with the REDIRECT target where you want to redirect traffic destined for particular set of hosts. Finally, if the list of addresses begins with "!" then the rule will be followed only if the original destination address in the connection request does not match any of the addresses listed. For other actions, this column may be included and may contain one or more addresses (host or network) separated by commas. Address ranges are not allowed. When this column is supplied, rules are generated that require that the original destination address matches one of the listed addresses. This feature is most useful when you want to generate a filter rule that corresponds to a DNAT- or REDIRECT- rule. In this usage, the list of addresses should not begin with "!". See http://shorewall.net/PortKnocking.html for an example of using an entry in this column with a user-defined action rule. RATE LIMIT You may rate-limit the rule by placing a value in this colume: /[:] where is the number of connections per ("sec" or "min") and is the largest burst permitted. If no is given, a value of 5 is assumed. There may be no no whitespace embedded in the specification. Example: 10/sec:20 USER/GROUP This column may only be non-empty if the SOURCE is the firewall itself. The column may contain: [!][][:][+] When this column is non-empty, the rule applies only if the program generating the output is running under the effective and/or specified (or is NOT running under that id if "!" is given). Examples: joe #program must be run by joe :kids #program must be run by a member of #the 'kids' group !:kids #program must not be run by a member #of the 'kids' group +upnpd #program named upnpd (This feature was #removed from Netfilter in kernel #version 2.6.14). Example: Accept SMTP requests from the DMZ to the internet #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST ACCEPT dmz net tcp smtp Example: Forward all ssh and http connection requests from the internet to local system 192.168.1.3 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST DNAT net loc:192.168.1.3 tcp ssh,http Example: Forward all http connection requests from the internet to local system 192.168.1.3 with a limit of 3 per second and a maximum burst of 10 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE # PORT PORT(S) DEST LIMIT DNAT net loc:192.168.1.3 tcp http - - 3/sec:10 Example: Redirect all locally-originating www connection requests to port 3128 on the firewall (Squid running on the firewall system) except when the destination address is 192.168.2.2 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST REDIRECT loc 3128 tcp www - !192.168.2.2 Example: All http requests from the internet to address 130.252.100.69 are to be forwarded to 192.168.1.3 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69 Example: You want to accept SSH connections to your firewall only from internet IP addresses 130.252.100.69 and 130.252.100.70 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL # PORT PORT(S) DEST ACCEPT net:130.252.100.69,130.252.100.70 $FW \ tcp 22 See http://www.shorewall.net/Documentation.htm#Rules for additional information. ################################################################################ Based on tc4shorewall version 0.5 by Arne Bernin /etc/shorewall/tcclasses Define the classes used for traffic shaping in this file. A note on the rate/bandwidth definitions used in this file: - don't use a space between the integer value and the unit: 30kbit is valid while 30 kbit is NOT. - you can use one of the following units: kbps Kilobytes per second mbps Megabytes per second kbit Kilobits per second mbit Megabits per second bps or a bare number Bytes per second - if you want the values to be calculated for you depending on the output bandwidth setting defined for an interface in tcdevices, you can use expressions like the following: full/3 causes the bandwidth to be calculated as 3 of the the full outgoing speed that is defined. full*9/10 will set this bandwidth to 9/10 of the full bandwidth DO NOT add a unit to the rate if it is calculated ! Columns are: INTERFACE Name of interface. Each interface may be listed only once in this file. You may NOT specify the name of an alias (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18 You may NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here! Please note that you can only use interface names in here that have a bandwidth defined in the tcdevices file MARK The mark value which is an integer in the range 1-255. You define this marks in the tcrules file, marking the traffic you want to fit in the classes defined in here. You can use the same marks for different interfaces. RATE The minimum bandwidth this class should get, when the traffic load rises. If the sum of the rates in this column exceed the INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be honored. CEIL The maximum bandwidth this class is allowed to use when the link is idle. Useful if you have traffic which can get full speed when more needed services (e.g. ssh) are not used. You can use the value "full" in here for setting the maximum bandwidth to the defined output bandwidth of that interface. PRIORITY The priority in which classes will be serviced by the packet shaping scheduler and also the priority in which bandwidth in excess of the rate will be given to each class. Higher priority classes will experience less delay since they are serviced first. Priority values are serviced in ascending order (e.g. 0 is higher priority than 1). Classes may be set to the same priority, in which case they will be serviced as equals. OPTIONS A comma-separated list of options including the following: default - this is the default class for that interface where all traffic should go, that is not classified otherwise. NOTE: defining default for exactly one class per interface is mandatory! tos=0x[/0x] (mask defaults to 0xff) - this lets you define a classifier for the given / combination of the IP packet's TOS/Precedence/DiffSrv octet (aka the TOS byte). Please note, classifiers override all mark settings, so if you define a classifer for a class, all traffic having that mark will go in it regardless of any mark set on the packet by a firewall/mangle filter. NOTE: multiple tos= statements may be applied per class and per interface, but a given value/mask pair is valid for only ONE class per interface. tos- - aliases for the following TOS octet value and mask encodings. TOS encodings of the "TOS byte" have been deprecated in favor of diffserve classes, but programs like ssh, rlogin, and ftp still use them. tos-minimize-delay 0x10/0x10 tos-maximize-throughput 0x08/0x08 tos-maximize-reliability 0x04/0x04 tos-minimize-cost 0x02/0x02 tos-normal-service 0x00/0x1e NOTE: each of this options is only valid for ONE class per interface. tcp-ack - if defined causes an tc filter to be created that puts all tcp ack packets on that interface that have an size of <=64 Bytes to go in this class. This is useful for speeding up downloads. Please note that the size of the ack packets is limited to 64 bytes as some applications (p2p for example) use to make every packet an ack packet which would cause them all into here. We want only packets WITHOUT payload to match, so the size limit. NOTE: This option is only valid for ONE class per interface. Example 1: Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. You have 4 classes here, the first you can use for voice over IP traffic, the second interactive traffic (e.g. ssh/telnet but not scp), the third will be for all unclassified traffic, and the forth is for low priority traffic (e.g. peer-to-peer). The voice traffic in the first class will be guaranteed a minimum of 100kbps and always be serviced first (because of the low priority number, giving less delay) and will be granted excess bandwidth (up to 180kbps, the class ceiling) first, before any other traffic. A single VOIP stream, depending upon codecs, after encapsulation, can take up to 80kbps on a PPOE/DSL link, so we pad a little bit just in case. (TOS byte values 0xb8 and 0x68 are DiffServ classes EF and AFF3-1 respectively and are often used by VOIP devices). Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP echo traffic if you use the example in tcrules) and any packet with a mark of 2 will be guaranteed 1/4 of the link bandwidth, and may extend up to full speed of the link. Unclassified traffic and packets marked as 3 will be guaranteed 1/4th of the link bandwidth, and may extend to the full speed of the link. Packets marked with 4 will be treated as low priority packets. (The tcrules example marks p2p traffic as such.) If the link is congested, they're only guaranteed 1/8th of the speed, and even if the link is empty, can only expand to 80% of link bandwidth just as a precaution in case there are upstream queues we didn't account for. This is the last class to get additional bandwidth and the last to get serviced by the scheduler because of the low priority. ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay ppp0 3 full/4 full 3 default ppp0 4 full/8 full*8/10 4 See http://shorewall.net/traffic_shaping.htm for additional information. ################################################################################ Based on tc4shorewall version 0.5 by Arne Bernin /etc/shorewall/tcdevices Entries in this file define the bandwidth for interfaces on which you want traffic shaping to be enabled. If you do not plan to use traffic shaping for a device, don't put it in here as it limits the troughput of that device to the limits you set here. Columns are: INTERFACE Name of interface. Each interface may be listed only once in this file. You may NOT specify the name of an alias (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18 You man NOT specify wildcards here, e.g. if you have multiple ppp interfaces, you need to put them all in here! If the device doesn't exist, a warning message will be issued during "shorewall [re]start" and "shorewall refresh" and traffic shaping configuration will be skipped for that device. IN-BANDWIDTH The incoming Bandwidth of that interface. Please note that you are not able to do traffic shaping on incoming traffic, as the traffic is already received before you could do so. But this allows you to define the maximum traffic allowed for this interface in total, if the rate is exceeded, the packets are dropped. You want this mainly if you have a DSL or Cable connection to avoid queuing at your providers side. If you don't want any traffic to be dropped, set this to a value to zero in which case Shorewall will not create an ingress qdisc. Use kbit or kbps(for Kilobytes per second) for speed, and make sure there is NO space between the number and the unit. OUT-BANDWIDTH The outgoing Bandwidth of that interface. This is the maximum speed you connection can handle. It is also the speed you can refer as "full" if you define the tc classes. Outgoing traffic above this rate will be dropped. Use kbit or kbps(for Kilobytes per second) for speed, and make sure there is NO space between the number and the unit. Example 1: Suppose you are using PPP over Ethernet (DSL) and ppp0 is the interface for this. The device has an outgoing bandwidth of 500kbit and an incoming bandwidth of 6000kbit ppp0 6000kbit 500kbit See http://shorewall.net/traffic_shaping.htm for additional information. ################################################################################ /etc/shorewall/tcrules Entries in this file cause packets to be marked as a means of classifying them for traffic control or policy routing. I M P O R T A N T ! ! ! ! Unlike rules in the /etc/shorewall/rules file, evaluation of rules in this file will continue after a match. So the final mark for each packet will be the one assigned by the LAST tcrule that matches. If you use multiple internet providers with the 'track' option, in /etc/shorewall/providers be sure to read the restrictions at http://shorewall.net/MultiISP.html. Columns are: MARK/ a) A mark value which is an integer in the range 1-255. CLASSIFY Normally will set the mark value. If preceded by a vertical bar ("|"), the mark value will be logically ORed with the current mark value to produce a new mark value. If preceded by an ampersand ("&"), will be logically ANDed with the current mark value to produce a new mark value. Both "|" and "&" require Extended MARK Target support in your kernel and iptables; neither may be used with connection marks (see below). If HIGH_ROUTE_MARKS=Yes in shorewall.conf then you may also specify a value in the range 0x0100- 0xFF00 with the low-order byte being zero. Such values may only be used in the PREROUTING chain (value followed by :F or you have set MARK_IN_FORWARD_CHAIN=Yes in shorewall conf and have not followed the value with :P) or the OUTPUT chain (SOURCE is $FW). May optionally be followed by ":P" or ":F" where ":P" indicates that marking should occur in the PREROUTING chain and ":F" indicates that marking should occur in the FORWARD chain. If neither ":P" nor ":F" follow the mark value then the chain is determined by the setting of MARK_IN_FORWARD_CHAIN in /etc/shorewall/shorewall.conf. If your kernel and iptables include CONNMARK support then you can also mark the connection rather than the packet. The mark value may be optionally followed by "/" and a mask value (used to determine those bits of the connection mark to actually be set). The mark and optional mask are then followed by one of: C - Mark the connection in the chain determined by the setting of MARK_IN_FORWARD_CHAIN CF: Mark the connection in the FORWARD chain CP: Mark the connection in the PREROUTING chain. b) A classification (classid) of the form : where and are integers. Corresponds to the 'class' specification in these traffic shaping modules: - atm - cbq - dsmark - pfifo_fast - htb - prio Classification occurs in the POSTROUTING chain except when the SOURCE is $FW[:
] in which case marking occurs in the OUTPUT chain. c) RESTORE[/mask] -- restore the packet's mark from the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support. As in a) above, may be followed by ":P" or ":F c) SAVE[/mask] -- save the packet's mark to the connection's mark using the supplied mask if any. Your kernel and iptables must include CONNMARK support. As in a) above, may be followed by ":P" or ":F d) CONTINUE -- don't process any more marking rules in the table. As in a) above, may be followed by ":P" or ":F". e) COMMENT -- the rest of the line will be attached as a comment to the Netfilter rule(s) generated by the following entries. The comment will appear delimited by "/* ... */" in the output of "shorewall show mangle" To stop the comment from being attached to further rules, simply include COMMENT on a line by itself. SOURCE Source of the packet. A comma-separated list of interface names, IP addresses, MAC addresses and/or subnets for packets being routed through a common path. List elements may also consist of an interface name followed by ":" and an address (e.g., eth1:192.168.1.0/24). For example, all packets for connections masqueraded to eth0 from other interfaces can be matched in a single rule with several alternative SOURCE criteria. However, a connection whose packets gets to eth0 in a different way, e.g., direct from the firewall itself, needs a different rule. Accordingly, use $FW in its own separate rule for packets originating on the firewall. In such a rule, the MARK column may NOT specify either ":P" or ":F" because marking for firewall-originated packets always occurs in the OUTPUT chain. MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 DEST Destination of the packet. Comma separated list of IP addresses and/or subnets. If your kernel and iptables include iprange match support, IP address ranges are also allowed. List elements may also consist of an interface name followed by ":" and an address (e.g., eth1:192.168.1.0/24). If the MARK column specificies a classification of the form : then this column may also contain an interface name. PROTO Protocol - Must be "tcp", "udp", "icmp", "ipp2p", "ipp2p:udp", "ipp2p:all" a number, or "all". "ipp2p" requires ipp2p match support in your kernel and iptables. PORT(S) Destination Ports. A comma-separated list of Port names (from /etc/services), port numbers or port ranges; if the protocol is "icmp", this column is interpreted as the destination icmp-type(s). If the protocol is ipp2p, this column is interpreted as an ipp2p option without the leading "--" (example "bit" for bit-torrent). If no PORT is given, "ipp2p" is assumed. This column is ignored if PROTOCOL = all but must be entered if any of the following field is supplied. In that case, it is suggested that this field contain "-" SOURCE PORT(S) (Optional) Source port(s). If omitted, any source port is acceptable. Specified as a comma- separated list of port names, port numbers or port ranges. USER This column may only be non-empty if the SOURCE is the firewall itself. When this column is non-empty, the rule applies only if the program generating the output is running under the effective user and/or group. It may contain : []:[][+] The colon is optionnal when specifying only a user or a program name. Examples : john: , john , :users , john:users , +mozilla-bin (Support for program names was removed from Netfilter in Kernel version 2.6.14). TEST Defines a test on the existing packet or connection mark. The rule will match only if the test returns true. Tests have the format [!][/][:C] Where: ! Inverts the test (not equal) Value of the packet or connection mark. A mask to be applied to the mark before testing :C Designates a connection mark. If omitted, the packet mark's value is tested. If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. LENGTH (Optional) Packet Length. This field, if present allow you to match the length of a packet against a specific value or range of values. You must have iptables length support for this to work. A range is specified in the form : where either or (but not both) may be omitted. If is omitted, then 0 is assumed; if is omitted, than any packet that is or longer will match. Examples: 1024, 64:1500, :100 (packet of length 100 bytes or less) If you don't want to define a test but need to specify anything in the following columns, place a "-" in this field. TOS Type of service. Either a standard name, or a numeric value to match. Minimize-Delay (16) Maximize-Throughput (8) Maximize-Reliability (4) Minimize-Cost (2) Normal-Service (0) Example 1: Mark all ICMP echo traffic with packet mark 1. Mark all peer to peer traffic with packet mark 4. This is a little more complex than otherwise expected. Since the ipp2p module is unable to determine all packets in a connection are P2P packets, we mark the entire connection as P2P if any of the packets are determined to match. We assume packet/connection mark 0 to means unclassified. 1 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0 CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0 4 0.0.0.0/0 0.0.0.0/0 ipp2p:all SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0 "If a packet hasn't been classifed (packet mark is 0), copy the connection mark to the packet mark. If the packet mark is set, we're done. If the packet is P2P, set the packet mark to 4. If the packet mark has been set, save it to the connection mark." See http://shorewall.net/traffic_shaping.htm for additional information. For usage in selecting among multiple ISPs, see http://shorewall.net/MultiISP.html ################################################################################ /etc/shorewall/tos This file defines rules for setting Type Of Service (TOS) Columns are: SOURCE Name of a zone declared in /etc/shorewall/zones, "all" or $FW. If not "all" or $FW, may optionally be followed by ":" and an IP address, a MAC address, a subnet specification or the name of an interface. Example: loc:192.168.2.3 MAC addresses must be prefixed with "~" and use "-" as a separator. Example: ~00-A0-C9-15-39-78 DEST Name of a zone declared in /etc/shorewall/zones, "all" or $FW. If not "all" or $FW, may optionally be followed by ":" and an IP address or a subnet specification Example: loc:192.168.2.3 PROTOCOL Protocol. SOURCE PORTS Source port or port range. If all ports, use "-". DEST PORTS Destination port or port range. If all ports, use "-" TOS Type of service. Must be one of the following: Minimize-Delay (16) Maximize-Throughput (8) Maximize-Reliability (4) Minimize-Cost (2) Normal-Service (0) See http://shorewall.net/Documentation.htm#TOS for additional information. ################################################################################ /etc/shorewall/tunnels This file defines IPSEC, GRE, IPIP and OPENVPN tunnels. IPIP, GRE and OPENVPN tunnels must be configured on the firewall/gateway itself. IPSEC endpoints may be defined on the firewall/gateway or on an internal system. The columns are: TYPE -- must start in column 1 and be "ipsec", "ipsecnat", "ipip", "gre", "6to4", "pptpclient", "pptpserver", "openvpn", "openvpnclient", "openvpnserver" or "generic" If the type is "ipsec" or "ipsecnat", it may be followed by ":noah" to indicate that the Authentication Header protocol (51) is not used by the tunnel. If type is "openvpn", "openvpnclient" or "openvpnserver" it may optionally be followed by ":" and "tcp" or "udp" to specify the protocol to be used. If not specified, "udp" is assumed. If type is "openvpn", "openvpnclient" or "openvpnserver" it may optionally be followed by ":" and the port number used by the tunnel. if no ":" and port number are included, then the default port of 1194 will be used. . Where both the protocol and port are specified, the protocol must be given first (e.g., openvpn:tcp:4444). If type is "generic", it must be followed by ":" and a protocol name (from /etc/protocols) or a protocol number. If the protocol is "tcp" or "udp" (6 or 17), then it may optionally be followed by ":" and a port number. ZONE -- The zone of the physical interface through which tunnel traffic passes. This is normally your internet zone. GATEWAY -- The IP address of the remote tunnel gateway. If the remote gateway has no fixed address (Road Warrior) then specify the gateway as 0.0.0.0/0. May be specified as a network address and if your kernel and iptables include iprange match support then IP address ranges are also allowed. GATEWAY ZONES -- Optional. If the gateway system specified in the third column is a standalone host then this column should contain a comma-separated list of the names of the zones that the host might be in. This column only applies to IPSEC tunnels where it enables ISAKMP traffic to flow through the tunnel to the remote gateway. Example 1: IPSec tunnel. The remote gateway is 4.33.99.124 and the remote subnet is 192.168.9.0/24. The tunnel does not use the AH protocol ipsec:noah net 4.33.99.124 Example 2: Road Warrior (LapTop that may connect from anywhere) where the "gw" zone is used to represent the remote LapTop. ipsec net 0.0.0.0/0 gw Example 3: Host 4.33.99.124 is a standalone system connected via an ipsec tunnel to the firewall system. The host is in zone gw. ipsec net 4.33.99.124 gw Example 4: Road Warriors that may belong to zones vpn1, vpn2 or vpn3. The FreeS/Wan _updown script will add the host to the appropriate zone using the "shorewall add" command on connect and will remove the host from the zone at disconnect time. ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3 Example 5: You run the Linux PPTP client on your firewall and connect to server 192.0.2.221. pptpclient net 192.0.2.221 Example 6: You run a PPTP server on your firewall. pptpserver net Example 7: OPENVPN tunnel. The remote gateway is 4.33.99.124 and openvpn uses port 7777. openvpn:7777 net 4.33.99.124 Example 8: You have a tunnel that is not one of the supported types. Your tunnel uses UDP port 4444. The other end of the tunnel is 4.3.99.124. generic:udp:4444 net 4.3.99.124 See http://shorewall.net/Documentation.htm#Tunnels for additional information. ################################################################################ /etc/shorewall/zones This file declares your network zones. You specify the hosts in each zone through entries in /etc/shorewall/interfaces or /etc/shorewall/hosts. WARNING: The format of this file changed in Shorewall 3.0.0. You can continue to use your old records provided that you set IPSECFILE=ipsec in /etc/shorewall/shorewall.conf. This will signal Shorewall that the IPSEC-related zone options are still specified in /etc/shorewall/ipsec rather than in this file. To use records in the format described below, you must have IPSECFILE=zones specified in /etc/shorewall/shorewall.conf AND YOU MUST NOT SET THE 'FW' VARIABLE IN THAT FILE!!!!! Columns are: ZONE Short name of the zone. The names "all" and "none" are reserved and may not be used as zone names. The maximum length of a zone name is determined by the setting of the LOGFORMAT option in shorewall.conf. With the default LOGFORMAT, zone names can be at most 5 characters long. Where a zone is nested in one or more other zones, you may follow the (sub)zone name by ":" and a comma-separated list of the parent zones. The parent zones must have been defined in earlier records in this file. Example: #ZONE TYPE OPTIONS a ipv4 b ipv4 c:a,b ipv4 Currently, Shorewall uses this information to reorder the zone list so that parent zones appear after their subzones in the list. The IMPLICIT_CONTINUE option in shorewall.conf can also create implicit CONTINUE policies to/from the subzone. In the future, Shorewall may make additional use of nesting information. TYPE ipv4 - This is the standard Shorewall zone type and is the default if you leave this column empty or if you enter "-" in the column. Communication with some zone hosts may be encrypted. Encrypted hosts are designated using the 'ipsec'option in /etc/shorewall/hosts. ipsec - Communication with all zone hosts is encrypted Your kernel and iptables must include policy match support. firewall - Designates the firewall itself. You must have exactly one 'firewall' zone. No options are permitted with a 'firewall' zone. The name that you enter in the ZONE column will be stored in the shell variable $FW which you may use in other configuration files to designate the firewall zone. OPTIONS, A comma-separated list of options as follows: IN OPTIONS, OUT OPTIONS reqid= where is specified using setkey(8) using the 'unique: option for the SPD level. spi= where is the SPI of the SA used to encrypt/decrypt packets. proto=ah|esp|ipcomp mss= (sets the MSS field in TCP packets) mode=transport|tunnel tunnel-src=
[/] (only available with mode=tunnel) tunnel-dst=
[/] (only available with mode=tunnel) strict Means that packets must match all rules. next Separates rules; can only be used with strict Example: mode=transport,reqid=44 The options in the OPTIONS column are applied to both incoming and outgoing traffic. The IN OPTIONS are applied to incoming traffic (in addition to OPTIONS) and the OUT OPTIONS are applied to outgoing traffic. If you wish to leave a column empty but need to make an entry in a following column, use "-". ------------------------------------------------------------------------------ Example zones: You have a three interface firewall with internet, local and DMZ interfaces. #ZONE TYPE OPTIONS IN OUT # OPTIONS OPTIONS fw firewall net ipv4 loc ipv4 dmz ipv4 For more information, see http://www.shorewall.net/Documentation.htm#Zones ################################################################################