shorewall-files

title: shorewall-files(5)

summary: Shorewall Configuration Files

text:
# shorewall-files(5)

## NAME
files - Shorewall Configuration Files

## SYNOPSIS
/etc/shorewall[6]/*

## DESCRIPTION
The following are the Shorewall[6] configuration files:

•/etc/shorewall/shorewall.conf and /etc/shorewall6/shorewall6.conf[1] - used to set global firewall parameters.

•/etc/shorewall[6]/params[2] - use this file to set shell variables that you will expand in other files. It is always processed by /bin/sh or by the shell specified through SHOREWALL_SHELL in /etc/shorewall/shorewall.conf.

•/etc/shorewall[6]/zones[3] - partition the firewall's view of the world into zones.

•/etc/shorewall[6]/policy[4] - establishes firewall high-level policy.

•/etc/shorewall[6]/initdone - An optional Perl script that will be invoked by the Shorewall rules compiler when the compiler has finished it's initialization.

•/etc/shorewall[6]/interfaces[5] - describes the interfaces on the firewall system.

•/etc/shorewall[6]/hosts[6] - allows defining zones in terms of individual hosts and subnetworks.

•/etc/shorewall[6]/masq[7] - directs the firewall where to use many-to-one (dynamic) Network Address Translation (a.k.a. Masquerading) and Source Network Address Translation (SNAT). Superseded by /etc/shorewall[6]/snat in Shorewall 5.0.14 and not supported in Shorewall 5.1.0 and later versions.

•/etc/shorewall[6]/mangle[8] - supersedes /etc/shorewall/tcrules in Shorewall 4.6.0. Contains rules for packet marking, TTL, TPROXY, etc.

•/etc/shorewall[6]/rules[9] - defines rules that are exceptions to the overall policies established in /etc/shorewall/policy.

•/etc/shorewall[6]/nat[10] - defines one-to-one NAT rules.

•/etc/shorewall6/proxyarp[11] - defines use of Proxy ARP.

•/etc/shorewall6/proxyndp[12] - defines use of Proxy NDP.

•/etc/shorewall[6]/routestopped - defines hosts accessible when Shorewall is stopped. Superseded in Shorewall 4.6.8 by /etc/shorewall/stoppedrules. Not supported in Shorewall 5.0.0 and later versions.

•/etc/shorewall[6]/tcrules[13]- The file has a rather unfortunate name because it is used to define marking of packets for later use by both traffic control/shaping and policy routing. This file is superseded by /etc/shorewall/mangle in Shorewall 4.6.0. Not supported in Shorewall 5.0.0 and later releases.

•/etc/shorewall[6]/tos[14] - defines rules for setting the TOS field in packet headers. Superseded in Shorewall 4.5.1 by the TOS target in /etc/shorewall/tcrules (which file has since been superseded by /etc/shorewall/mangle). Not supported in Shorewall 5.0.0 and later versions.

•/etc/shorewall[6]/tunnels[15] - defines tunnels (VPN) with end-points on the firewall system.

•/etc/shorewall[6]/blacklist[16] - Deprecated in favor of /etc/shorewall/blrules. Lists blacklisted IP/subnet/MAC addresses. Not supported in Shorewall 5.0.0 and later releases.

•/etc/shorewall[6]/blrules — Added in Shorewall 4.5.0. Define blacklisting and whitelisting. Supersedes /etc/shorewall/blacklist.

•/etc/shorewall[6]/init - shell commands that you wish to execute at the beginning of a “shorewall start”, "shorewall reload" or “shorewall restart”.

•/etc/shorewall[6]/start - shell commands that you wish to execute near the completion of a “shorewall start”, "shorewall reload" or “shorewall restart”

•/etc/shorewall[6]/started - shell commands that you wish to execute after the completion of a “shorewall start”, "shorewall reload" or “shorewall restart”

•/etc/shorewall[6]/stop- commands that you wish to execute at the beginning of a “shorewall stop”.

•/etc/shorewall[6]/stopped - shell commands that you wish to execute at the completion of a “shorewall stop”.

•/etc/shorewall/ecn[17] - disable Explicit Congestion Notification (ECN - RFC 3168) to remote hosts or networks. Superseded by ECN entries in /etc/shorewall/mangle in Shorewall 5.0.6.

•/etc/shorewall/accounting[18] - define IP traffic accounting rules

•/etc/shorewall[6]/actions[19] and /usr/share/shorewall[6]/action.template allow user-defined actions.

•/etc/shorewall[6]/providers[20] - defines alternate routing tables.

•/etc/shorewall[6]/rtrules[21] - Defines routing rules to be used in conjunction with the routing tables defined in /etc/shorewall/providers.

•/etc/shorewall[6]/tcdevices[22], /etc/shorewall[6]/tcclasses[23], /etc/shorewall[6]/tcfilters[24] - Define complex traffic shaping.

•/etc/shorewall[6]/tcrules[13] - Mark or classify traffic for traffic shaping or multiple providers. Deprecated in Shorewall 4.6.0 in favor of /etc/shorewall/mangle. Not supported in Shorewall 5.0.0 and later releases.

•/etc/shorewall[6]/tcinterfaces[25] and /etc/shorewall[6]/tcpri[26] - Define simple traffic shaping.

•/etc/shorewall[6]/secmarks[27] - Added in Shorewall 4.4.13. Attach an SELinux context to selected packets.

•/etc/shorewall[6]/vardir[28] - Determines the directory where Shorewall maintains its state.

•/etc/shorewall/arprules[29] — Added in Shorewall 4.5.12. Allows specification of arptables rules.

•/etc/shorewall/mangle[8] -- Added in Shorewall 4.6.0. Supersedes/etc/shorewall/tcrules.

•/etc/shorewall[6]/snat[30] - directs the firewall where to use many-to-one (dynamic) Network Address Translation (a.k.a. Masquerading) and Source Network Address Translation (SNAT). Superseded /etc/shorewall[6]/masq in Shorewall 5.0.14

•/usr/share/shorewall[6]/actions.std - Actions defined by Shorewall.

•/usr/share/shorewall[6]/action.* - Details of actions defined by Shorewall.

•/usr/share/shorewall[6]/macro.* - Details of macros defined by Shorewall.

•/usr/share/shorewall[6]/modules — Specifies the kernel modules to be loaded during shorewall start/restart.

•/usr/share/shorewall[6]/helpers — Added in Shorewall 4.4.7. Specifies the kernel modules to be loaded during shorewall start/restart when LOAD_HELPERS_ONLY=Yes in shorewall.conf.

## CONFIG_PATH
The CONFIG_PATH option in shorewall[6].conf(5)[20] determines where the compiler searches for configuration files. The default setting is CONFIG_PATH=/etc/shorewall:/usr/share/shorewall which means that the compiler first looks in /etc/shorewall and if it doesn't find the file, it then looks in /usr/share/shorewall.

You can change this setting to have the compiler look in different places. For example, if you want to put your own versions of standard macros in /etc/shorewall/Macros, then you could set CONFIG_PATH=/etc/shorewall:/etc/shorewall/Macros:/usr/share/shorewall and the compiler will use your versions rather than the standard ones.

## COMMENTS
You may place comments in configuration files by making the first non-whitespace character a pound sign (“#”). You may also place comments at the end of any line, again by delimiting the comment from the rest of the line with a pound sign.

Example 1. Comments in a Configuration File

```
# This is a comment
ACCEPT  net     $FW      tcp     www     #This is an end-of-line comment
```

Important

Except in shorewall.conf(5)[1] and params(5)[2], if a comment ends with a backslash ("\"), the next line will also be treated as a comment. See Line Continuation below.

## BLANK LINES
Most of the configuration files are organized into space-separated columns. If you don't want to supply a value in a column but want to supply a value in a following column, simply enter '-' to make the column appear empty.

Example:

```
#INTERFACE         BROADCAST            OPTIONS
br0                -                    routeback
```

## LINE CONTINUATION
Lines may be continued using the usual backslash (“\”) followed immediately by a new line character (Enter key).

```
ACCEPT  net     $FW      tcp \↵
smtp,www,pop3,imap  #Services running on the firewall
```

Important

What follows does NOT apply to shorewall-params(5)[31] and shorewall.conf(5)[1].

In certain cases, leading white space is ignored in continuation lines:

1.The continued line ends with a colon (":")

2.The continued line ends with a comma (",")

Example (/etc/shorewall/rules):

```
#ACTION     SOURCE          DEST            PROTO           DPORT
ACCEPT      net:\

            206.124.146.177,\

            206.124.146.178,\

            206.124.146.180\

                            dmz             tcp             873
```

The leading white space on the first through third continuation lines is ignored so the SOURCE column effectively contains "net:206.124.146.177,206.124.147.178,206.124.146.180". Because the third continuation line does not end with a comma or colon, the leading white space in the last line is not ignored.

Important

A trailing backslash is not ignored in a comment. So the continued rule above can be commented out with a single '#' as follows:

```
#ACTION     SOURCE          DEST            PROTO           DPORT
#ACCEPT     net:\

            206.124.146.177,\

            206.124.146.178,\

            206.124.146.180\

                            dmz             tcp             873
```

## ALTERNATIVE SPECIFICATION OF COLUMN VALUES
Some of the configuration files now have a large number of columns. That makes it awkward to specify a value for one of the right-most columns as you must have the correct number of intervening '-' columns.

This problem is addressed by allowing column values to be specified as column-name/value pairs.

There is considerable flexibility in how you specify the pairs:

•At any point, you can enter a left curly bracket ('{') followed by one or more specifications of the following forms: column-name=value

column-name=>value

column-name:value

The pairs must be followed by a right curly bracket ("}"). The value may optionally be enclosed in double quotes.

The pairs must be separated by white space, but you can add a comma adjacent to the values for readability as in:

{ proto=>udp, port=1024

}

•You can also separate the pairs from columns by using a semicolon: ; proto:udp,

port:1024

In Shorewall 5.0.3, the sample configuration files and the man pages were updated to use the same column names in both the column headings and in the alternate specification format. The following table shows the column names for each of the table-oriented configuration files.

Note

Column names are case-insensitive.

File

Column names

accounting

action,chain, source, dest, proto, dport, sport, user, mark, ipsec, headers

conntrack

action,source,dest,proto,dport,sport,user,switch

blacklist

networks,proto,port,options

blrules

action,source,dest,proto,dport,sport,origdest,rate,user,mark,connlimit,time,headers,switch,helper

ecn

interface,hosts. Beginning with Shorewall 4.5.4, 'host' is a synonym for 'hosts'.

hosts

zone,hosts,options. Beginning with Shorewall 4.5.4, 'host' is a synonym for 'hosts'.

interfaces

zone,interface,broadcast,options

maclist

disposition,interface,mac,addresses

mangle

action,source,dest,proto,dport,sport,user,test,length,tos,connbytes,helper,headers

masq

interface,source,address,proto,port,ipsec,mark,user,switch

nat

external,interface,internal,allints,local

netmap

type,net1,interface,net2,net3,proto,dport,sport

notrack

source,dest,proto,dport,sport,user

policy

source,dest,policy,loglevel,limit,connlimit

providers

table,number,mark,duplicate,interface,gateway,options,copy

proxyarp and proxyndp

address,interface,external,haveroute,persistent

rtrules

source,dest,provider,priority

routes

provider,dest,gateway,device

routestopped

interface,hosts,options,proto,dport,sport

rules

action,source,dest,proto,dport,sport,origdest,rate,user,mark,connlimit,time,headers,switch,helper

secmarks

secmark,chain,source,dest,proto,dport,sport,user,mark

tcclasses

interface,mark,rate,ceil,prio,options

tcdevices

interface,in_bandwidth,out_bandwidth,options,redirect

tcfilters

class,source,dest,proto,dport,sport,tos,length

tcinterfaces

interface,type,in_bandwidth,out_bandwidth

tcpri

band,proto,port,address,interface,helper

tcrules

mark,source,dest,proto,dport,sport,user,test,length,tos,connbytes,helper,headers. Beginning with Shorewall 4.5.3, 'action' is a synonym for 'mark'.

tos

source,dest,proto,dport,sport,tos,mark

tunnels

type,zone,gateway,gateway_zone. Beginning with Shorewall 4.5.3, 'gateways' is a synonym for 'gateway'. Beginning with Shorewall 4.5.4, 'gateway_zones' is a synonym for 'gateway_zone'.

zones

zone,type,options,in_options,out_options

Example (rules file):

```
#ACTION         SOURCE            DEST            PROTO   DPORT
DNAT            net               loc:10.0.0.1    tcp     80    ; mark="88"
```

Here's the same line in several equivalent formats:

```
{ action=>DNAT, source=>net, dest=>loc:10.0.0.1, proto=>tcp, dport=>80, mark=>88 }
; action:"DNAT" source:"net"  dest:"loc:10.0.0.1" proto:"tcp" dport:"80" mark:"88"
DNAT { source=net dest=loc:10.0.0.1 proto=tcp dport=80 mark=88 }
```

Beginning with Shorewall 5.0.11, ip[6]table comments can be attached to individual rules using the comment keyword.

Example from the rules file:

```
        ACCEPT net $FW { proto=tcp, dport=22, comment="Accept \"SSH\"" }
```

As shown in that example, when the comment contains whitespace, it must be enclosed in double quotes and any embedded double quotes must be escaped using a backslash ("\").

## TIME COLUMNS
Several of the files include a TIME column that allows you to specify times when the rule is to be applied. Contents of this column is a list of timeelements separated by apersands (&).

Each timeelement is one of the following:

timestart=hh:mm[:ss]

Defines the starting time of day.

timestop=hh:mm[:ss]

Defines the ending time of day.

contiguous

Added in Shoreawll 5.0.12. When timestop is smaller than timestart value, match this as a single time period instead of distinct intervals. See the Examples below.

utc

Times are expressed in Greenwich Mean Time.

localtz

Deprecated by the Netfilter team in favor of kerneltz. Times are expressed in Local Civil Time (default).

kerneltz

Added in Shorewall 4.5.2. Times are expressed in Local Kernel Time (requires iptables 1.4.12 or later).

weekdays=ddd[,ddd]...

where ddd is one of Mon, Tue, Wed, Thu, Fri, Sat or Sun

monthdays=dd[,dd],...

where dd is an ordinal day of the month

datestart=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]

Defines the starting date and time.

datestop=yyyy[-mm[-dd[Thh[:mm[:ss]]]]]

Defines the ending date and time.

Examples:

To match on weekends, use:

weekdays=Sat,Sun

Or, to match (once) on a national holiday block:

datestart=2016-12-24&datestop=2016-12-27

Since the stop time is actually inclusive, you would need the following stop time to not match the first second of the new day:

datestart=2016-12-24T17:00&datestop=2016-12-27T23:59:59

During Lunch Hour

The fourth Friday in the month:

weekdays=Fri&monthdays=22,23,24,25,26,27,28

Matching across days might not do what is expected. For instance,

weekdays=Mon&timestart=23:00&timestop=01:00

Will match Monday, for one hour from midnight to 1 a.m., and then again for another hour from 23:00 onwards. If this is unwanted, e.g. if you would like 'match for two hours from Montay 23:00 onwards' you need to also specify the contiguous option in the example above.

## SWITCHES
here are times when you would like to enable or disable one or more rules in the configuration without having to do a shorewall reload or shorewall restart. This may be accomplished using the SWITCH column in shorewall-rules[32] (5) or shorewall6-rules[33] (5). Using this column requires that your kernel and iptables include Condition Match Support and you must be running Shorewall 4.4.24 or later. See the output of shorewall show capabilities and shorewall version to determine if you can use this feature.

The SWITCH column contains the name of a switch. Each switch is initially in the off position. You can turn on the switch named switch1 by:

echo 1 >

/proc/net/nf_condition/switch1

You can turn it off again by:

echo 0 >

/proc/net/nf_condition/switch1

If you simply include the switch name in the SWITCH column, then the rule is enabled only when the switch is on. If you precede the switch name with ! (e.g., !switch1), then the rule is enabled only when the switch is off. Switch settings are retained over shorewall restart.

Shorewall requires that switch names:

•begin with a letter and be composed of letters, digits, underscore ('_') or hyphen ('-'); and

•be 30 characters or less in length.

Multiple rules can be controlled by the same switch.

Example:

Forward port 80 to dmz host $BACKUP if switch 'primary_down' is on.

```
#ACTION     SOURCE          DEST        PROTO       DPORT        SPORT     ORIGDEST   RATE      USER      MARK    CONNLIMIT     TIME     HEADERS    SWITCH
DNAT        net             dmz:$BACKUP tcp         80           -         -          -         -         -       -             -        -          primary_down
```

## FILES
/etc/shorewall[6]/*

## NOTES
1.

/etc/shorewall/shorewall.conf

and /etc/shorewall6/shorewall6.conf

http://www.shorewall.netshorewall.conf.html

2.

/etc/shorewall[6]/params

http://www.shorewall.netshorewall-params.html

3.

/etc/shorewall[6]/zones

http://www.shorewall.netshorewall-zones.html

4.

/etc/shorewall[6]/policy

http://www.shorewall.netshorewall-policy.html

5.

/etc/shorewall[6]/interfaces

http://www.shorewall.netshorewall-interfaces.html

6.

/etc/shorewall[6]/hosts

http://www.shorewall.netshorewall-hosts.html

7.

/etc/shorewall[6]/masq

http://www.shorewall.netshorewall-masq.html

8.

/etc/shorewall[6]/mangle

http://www.shorewall.netshorewall-mangle.html

9.

/etc/shorewall[6]/rules

http://www.shorewall.netshorewall-rules.html

10.

/etc/shorewall[6]/nat

http://www.shorewall.netshorewall-nat.html

11.

/etc/shorewall6/proxyarp

http://www.shorewall.netshorewall-proxyarp.html

12.

/etc/shorewall6/proxyndp

http://www.shorewall.netshorewall-proxyndp.html

13.

/etc/shorewall[6]/tcrules

http://www.shorewall.netshorewall-tcrules.html

14.

/etc/shorewall[6]/tos

http://www.shorewall.netshorewall-tos.html

15.

/etc/shorewall[6]/tunnels

http://www.shorewall.netshorewall-tunnels.html

16.

/etc/shorewall[6]/blacklist

http://www.shorewall.netshorewall-blacklist.html

17.

/etc/shorewall/ecn

http://www.shorewall.netshorewall-ecn.html

18.

/etc/shorewall/accounting

http://www.shorewall.netshorewall-accounting.html

19.

/etc/shorewall[6]/actions

http://www.shorewall.netshorewall-actions.html

20.

/etc/shorewall[6]/providers

http://www.shorewall.net???

21.

/etc/shorewall[6]/rtrules

http://www.shorewall.netshorewall-rtrules.html

22.

/etc/shorewall[6]/tcdevices

http://www.shorewall.netshorewall-tcdevices.html

23.

/etc/shorewall[6]/tcclasses

http://www.shorewall.netshorewall-tcclasses.html

24.

/etc/shorewall[6]/tcfilters

http://www.shorewall.netshorewall-tcfilters.html

25.

/etc/shorewall[6]/tcinterfaces

http://www.shorewall.netshorewall-tcinterfaces.html

26.

/etc/shorewall[6]/tcpri

http://www.shorewall.netshorewall-tcpri.html

27.

/etc/shorewall[6]/secmarks

http://www.shorewall.netshorewall-secmarks.html

28.

/etc/shorewall[6]/vardir

http://www.shorewall.netshorewall-vardir.html

29.

/etc/shorewall/arprules

http://www.shorewall.netshorewall-arprules.html

30.

/etc/shorewall[6]/snat

http://www.shorewall.netshorewall-snat.html

31.

shorewall-params(5)

http://www.shorewall.netmanpages/shorewall-params.html

32.

shorewall-rules

http://www.shorewall.netmanpages/shorewall-rules.html

33.

shorewall6-rules

http://www.shorewall.netmanpages6/shorewall6-rules.html


shorewall-hosts

package: shorewall

title: shorewall-hosts(5)

summary: Shorewall file

text:
# shorewall-hosts(5)

## NAME
hosts - Shorewall file

## SYNOPSIS
/etc/shorewall[6]/hosts

## DESCRIPTION
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 declared in shorewall-zones[1](5) determines the order in which the records in this file are interpreted.

Warning

The only time that you need this file is when you have more than one zone connected through a single interface.

Warning

If you have an entry for a zone and interface in shorewall-interfaces[2](5) then do not include any entries in this file for that same (zone, interface) pair.

The columns in the file are as follows.

ZONE - zone-name

The name of a zone declared in shorewall-zones[1](5). You may not list the firewall zone in this column.

HOST(S) - interface:{[{address-or-range[,address-or-range]...|+ipset|dynamic}[exclusion]

The name of an interface defined in the shorewall-interfaces[2](5) file followed by a colon (":") and a comma-separated list whose elements are either:

1.The IP address of a host.

2.A network in CIDR format.

3.An IP address range of the form low.address-high.address. Your kernel and iptables must have iprange match support.

4.The name of an ipset.

5.The word dynamic which makes the zone dynamic in that you can use the shorewall add and shorewall delete commands to change to composition of the zone.

You may also exclude certain hosts through use of an exclusion (see shorewall-exclusion[3](5).

OPTIONS (Optional) - [option[,option]...]

A comma-separated list of options from the following list. The order in which you list the options is not significant but the list must have no embedded white-space. blacklist

Check packets arriving on this port against the shorewall-blacklist[4](5) file.

broadcast

Used when you want to include limited broadcasts (destination IP address 255.255.255.255) from the firewall to this zone. Only necessary when:

1.The network specified in the HOST(S) column does not include 255.255.255.255.

2.The zone does not have an entry for this interface in shorewall-interfaces[2](5).

destonly

Normally used with the Multi-cast IP address range (224.0.0.0/4). Specifies that traffic will be sent to the specified net(s) but that no traffic will be received from the net(s).

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 shorewall-zones[1](5) file then you do NOT need to specify the 'ipsec' option here.

maclist

Connection requests from these hosts are compared against the contents of shorewall-maclist[5](5). If this option is specified, the interface must be an Ethernet NIC or equivalent and must be up before Shorewall is started.

mss=mss

Added in Shorewall 4.5.2. When present, causes the TCP mss for new connections to/from the hosts given in the HOST(S) column to be clamped at the specified mss.

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[6](5). After logging, the packets are dropped.

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.

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.

## EXAMPLES
Example 1

The firewall runs a PPTP server which creates a ppp interface for each remote client. The clients are assigned IP addresses in the network 192.168.3.0/24 and in a zone named 'vpn'.

```
#ZONE       HOST(S)               OPTIONS
vpn         ppp+:192.168.3.0/24
```

## FILES
/etc/shorewall/hosts

/etc/shorewall6/hosts

## SEE ALSO
http://www.shorewall.net/configuration_file_basics.htm#Pairs[7]

shorewall(8)

## NOTES
1.

shorewall-zones

http://www.shorewall.net/manpages/shorewall-zones.html

2.

shorewall-interfaces

http://www.shorewall.net/manpages/shorewall-interfaces.html

3.

shorewall-exclusion

http://www.shorewall.net/manpages/shorewall-exclusion.html

4.

shorewall-blacklist

http://www.shorewall.net/manpages/shorewall-blacklist.html

5.

shorewall-maclist

http://www.shorewall.net/manpages/shorewall-maclist.html

6.

shorewall.conf

http://www.shorewall.net/manpages/shorewall.conf.html

7.

http://www.shorewall.net/configuration_file_basics.htm#Pairs

http://www.shorewall.net/configuration_file_basics.htm#Pairs


shorewall-interfaces

title: shorewall-interfaces(5)

summary: Shorewall interfaces file

text:
# shorewall-interfaces(5)

## NAME
interfaces - Shorewall interfaces file

## SYNOPSIS
/etc/shorewall[6]/interfaces

## DESCRIPTION
The interfaces file serves to define the firewall's network interfaces to Shorewall. The order of entries in this file is not significant in determining zone composition.

Beginning with Shorewall 4.5.3, the interfaces file supports two different formats:

FORMAT 1 (default - deprecated)

There is a BROADCAST column which can be used to specify the broadcast address associated with the interface.

FORMAT 2

The BROADCAST column is omitted.

The format is specified by a line as follows:

?FORMAT {1|2}

The columns in the file are as follows.

ZONE - zone-name

Zone for this interface. Must match the name of a zone declared 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 shorewall-hosts[1](5) file, you should place "-" in this column.

If there are multiple interfaces to the same zone, you must list them in separate entries.

Example:

```
#ZONE   INTERFACE       BROADCAST
loc     eth1            -
loc     eth2            -
```

INTERFACE - interface[:port]

Logical name of interface. Each interface may be listed only once in this file. You may NOT specify the name of a "virtual" interface (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18[2]. If the physical option is not specified, then the logical name is also the name of the actual interface. You may use wildcards here by specifying a prefix followed by the plus sign ("+"). For example, if you want to make an entry that applies to all PPP interfaces, use 'ppp+'; that would match ppp0, ppp1, ppp2, ...

When using Shorewall versions before 4.1.4, care must be exercised when using wildcards where there is another zone that uses a matching specific interface. See shorewall-nesting[3](5) for a discussion of this problem.

Shorewall allows '+' as an interface name, but that usage is deprecated. A better approach is to specify 'physical=+' in the OPTIONS column (see below).

There is no need to define the loopback interface (lo) in this file.

If a port is given, then the interface must have been defined previously with the bridge option. The OPTIONS column may not contain the following options when a port is given.

arp_filter

arp_ignore

bridge

log_martians

mss

optional

proxyarp

required

routefilter

sourceroute

upnp

wait

Beginning with Shorewall 4.5.17, if you specify a zone for the 'lo' interface, then that zone must be defined as type local in shorewall6-zones[4](5).

BROADCAST (Optional) - {-|detect|address[,address]...}

Only available if FORMAT 1. If you use the special value detect, Shorewall will detect the broadcast address(es) for you if your iptables and kernel include Address Type Match support.

If your iptables and/or kernel lack Address Type Match support then you may list the broadcast address(es) for the network(s) 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 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 (Optional) - [option[,option]...]

A comma-separated list of options from the following list. The order in which you list the options is not significant but the list should have no embedded white-space. accept_ra[={0|1|2}]

IPv6 only; added in Shorewall 4.5.16. Values are: 0

Do not accept Router Advertisements.

1

Accept Route Advertisements if forwarding is disabled.

2

Overrule forwarding behavior. Accept Route Advertisements even if forwarding is enabled.

If the option is specified without a value, then the value 1 is assumed.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

arp_filter[={0|1}]

IPv4 only. 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. Only those interfaces with the arp_filter option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

arp_ignore[=number]

IPv4 only. If specified, this interface will respond to arp requests based on the value of number (defaults to 1). 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 the sender's IP address is part from same subnet on this interface's address

3 - do not reply for local addresses configured with scope host, only resolutions for global and link

4-7 - reserved

8 - do not reply for all local addresses

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

Warning

Do not specify arp_ignore for any interface involved in Proxy ARP[5].

blacklist

Checks packets arriving on this interface against the shorewall-blacklist[6](5) file. Beginning with Shorewall 4.4.13:

•If a zone is given in the ZONES column, then the behavior is as if blacklist had been specified in the IN_OPTIONS column of shorewall-zones[7](5).

•Otherwise, the option is ignored with a warning: WARNING: The 'blacklist' option is ignored on multi-zone interfaces

bridge

Designates the interface as a bridge. Beginning with Shorewall 4.4.7, setting this option also sets routeback.

Note

If you have a bridge that you don't intend to define bport zones on, then it is best to omit this option and simply specify routeback.

dbl={none|src|dst|src-dst}

Added in Shorewall 5.0.10. This option defined whether or not dynamic blacklisting is applied to packets entering the firewall through this interface and whether the source address and/or destination address is to be compared against the ipset-based dynamic blacklist (DYNAMIC_BLACKLIST=ipset... in shorewall.conf(5)[8]). The default is determine by the setting of DYNAMIC_BLACKLIST: DYNAMIC_BLACKLIST=No

Default is none (e.g., no dynamic blacklist checking).

DYNAMIC_BLACKLIST=Yes

Default is src (e.g., the source IP address is checked).

DYNAMIC_BLACKLIST=ipset[-only]

Default is src.

DYNAMIC_BLACKLIST=ipset[-only],src-dst...

Default is src-dst (e.g., the source IP addresses in checked against the ipset on input and the destination IP address is checked against the ipset on packets originating from the firewall and leaving through this interface).

The normal setting for this option will be dst or none for internal interfaces and src or src-dst for Internet-facing interfaces.

destonly

Added in Shorewall 4.5.17. Causes the compiler to omit rules to handle traffic from this interface.

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.the interface has a static IP but is on a LAN segment with lots of DHCP clients.

4.the interface is a simple bridge[9] with a DHCP server on one port and DHCP clients on another port.

Note

If you use Shorewall-perl for firewall/bridging[10], then you need to include DHCP-specific rules in shorewall-rules[11](5). DHCP uses UDP ports 67 and 68.

This option allows DHCP datagrams to enter and leave the interface.

forward[={0|1}]

IPv6 only Sets the /proc/sys/net/ipv6/conf/interface/forwarding option to the specified value. If no value is supplied, then 1 is assumed.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

ignore[=1]

When specified, causes the generated script to ignore up/down events from Shorewall-init for this device. Additionally, the option exempts the interface from hairpin filtering. When '=1' is omitted, the ZONE column must contain '-' and ignore must be the only OPTION. Beginning with Shorewall 4.5.5, may be specified as 'ignore=1' which only causes the generated script to ignore up/down events from Shorewall-init; hairpin filtering is still applied. In this case, the above restrictions on the ZONE and OPTIONS columns are lifted.

loopback

Added in Shorewall 4.6.6. Designates the interface as the loopback interface. This option is assumed if the interface's physical name is 'lo'. Only one interface man have the loopback option specified.

logmartians[={0|1}]

IPv4 only. Turn on kernel martian logging (logging of packets with impossible source addresses. It is strongly suggested that if you set routefilter on an interface that you also set logmartians. Even if you do not specify the routefilter option, it is a good idea to specify logmartians because your distribution may have enabled route filtering without you knowing it. Only those interfaces with the logmartians option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

To find out if route filtering is set on a given interface, check the contents of /proc/sys/net/ipv4/conf/interface/rp_filter - a non-zero value indicates that route filtering is enabled.

Example:

```
        teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter

        1

        teastep@lists:~$
```

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

This option may also be enabled globally in the shorewall.conf[8](5) file.

maclist

Connection requests from this interface are compared against the contents of shorewall-maclist[12](5). If this option is specified, the interface must be an Ethernet NIC and must be up before Shorewall is started.

mss=number

Added in Shorewall 4.0.3. Causes forwarded TCP SYN packets entering or leaving on this interface to have their MSS field set to the specified number.

nets=(net[,...])

Limit the zone named in the ZONE column to only the listed networks. The parentheses may be omitted if only a single net is given (e.g., nets=192.168.1.0/24). Limited broadcast to the zone is supported. Beginning with Shorewall 4.4.1, multicast traffic to the zone is also supported.

nets=dynamic

Defines the zone as dynamic. Requires ipset match support in your iptables and kernel. See http://www.shorewall.net/Dynamic.html[13] for further information.

nodbl

Added in Shorewall 5.0.8. When specified, dynamic blacklisting is disabled on the interface. Beginning with Shorewall 5.0.10, nodbl is equivalent to dbl=none.

nosmurfs

IPv4 only. 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[8](5). After logging, the packets are dropped.

optional

When optional is specified for an interface, Shorewall will be silent when:

•a /proc/sys/net/ipv[46]/conf/ entry for the interface cannot be modified (including for proxy ARP or proxy NDP).

•The first address of the interface cannot be obtained.

May not be specified with required.

physical=name

Added in Shorewall 4.4.4. When specified, the interface or port name in the INTERFACE column is a logical name that refers to the name given in this option. It is useful when you want to specify the same wildcard port name on two or more bridges. See http://www.shorewall.net/bridge-Shorewall-perl.html#Multiple[14]. If the interface name is a wildcard name (ends with '+'), then the physical name must also end in '+'. The physical name may end in '+' (or be exactly '+') when the interface name is not a wildcard name.

If physical is not specified, then it's value defaults to the interface name.

proxyarp[={0|1}]

IPv4 only. Sets /proc/sys/net/ipv4/conf/interface/proxy_arp. Do NOT use this option if you are employing Proxy ARP through entries in shorewall-proxyarp[15](5). This option is intended solely for use with Proxy ARP sub-networking as described at: http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html.[16]

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

Only those interfaces with the proxyarp option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

proxyndp[={0|1}]

IPv6 only. Sets /proc/sys/net/ipv6/conf/interface/proxy_ndp.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

Only those interfaces with the proxyndp option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

required

Added in Shorewall 4.4.10. If this option is set, the firewall will fail to start if the interface is not usable. May not be specified together with optional.

routeback[={0|1}]

If specified, indicates that Shorewall should include rules that allow traffic arriving on this interface to be routed back out that same interface. This option is also required when you have used a wildcard in the INTERFACE column if you want to allow traffic between the interfaces that match the wildcard. Beginning with Shorewall 4.4.20, if you specify this option, then you should also specify either sfilter (see below) or routefilter on all interfaces (see below).

Beginning with Shorewall 4.5.18, you may specify this option to explicitly reset (e.g., routeback=0). This can be used to override Shorewall's default setting for bridge devices which is routeback=1.

routefilter[={0|1|2}]

IPv4 only. Turn on kernel route filtering for this interface (anti-spoofing measure). Only those interfaces with the routefilter option will have their setting changes; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

The value 2 is only available with Shorewall 4.4.5.1 and later when the kernel version is 2.6.31 or later. It specifies a loose form of reverse path filtering.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

This option can also be enabled globally via the ROUTE_FILTER option in the shorewall.conf[8](5) file.

Important

If ROUTE_FILTER=Yes in shorewall.conf[8](5), or if your distribution sets net.ipv4.conf.all.rp_filter=1 in /etc/sysctl.conf, then setting routefilter=0 in an interface entry will not disable route filtering on that interface! The effective setting for an interface is the maximum of the contents of /proc/sys/net/ipv4/conf/all/rp_filter and the routefilter setting specified in this file (/proc/sys/net/ipv4/conf/interface/rp_filter).

Note

There are certain cases where routefilter cannot be used on an interface:

•If USE_DEFAULT_RT=Yes in shorewall.conf[8](5) and the interface is listed in shorewall-providers[17](5).

•If there is an entry for the interface in shorewall-providers[17](5) that doesn't specify the balance option.

•If IPSEC is used to allow a road-warrior to have a local address, then any interface through which the road-warrior might connect cannot specify routefilter.

Beginning with Shorewall 5.1.1, when routefilter is set to a non-zero value, the logmartians option is also implicitly set. If you actually want route filtering without logging, then you must also specify logmartians=0 after routefilter.

rpfilter

Added in Shorewall 4.5.7. This is an anti-spoofing measure that requires the 'RPFilter Match' capability in your iptables and kernel. It provides a more efficient alternative to the sfilter option below. It performs a function similar to routefilter (see above) but works with Multi-ISP configurations that do not use balanced routes.

sfilter=(net[,...])

Added in Shorewall 4.4.20. This option provides an anti-spoofing alternative to routefilter on interfaces where that option cannot be used, but where the routeback option is required (on a bridge, for example). On these interfaces, sfilter should list those local networks that are connected to the firewall through other interfaces.

sourceroute[={0|1}]

If this option is not specified for an interface, then source-routed packets will not be accepted from that interface unless it has been explicitly enabled via sysconf. Only set this option to 1 (enable source routing) if you know what you are doing. This might represent a security risk and is usually unneeded. Only those interfaces with the sourceroute option will have their setting changed; the value assigned to the setting will be the value specified (if any) or 1 if no value is given.

Note

This option does not work with a wild-card physical name (e.g., eth0.+). Beginning with Shorewall 5.1.10, If this option is specified, a warning is issued and the option is ignored.

tcpflags[={0|1}]

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. Beginning with Shorewall 4.6.0, tcpflags=1 is the default. To disable this option, specify tcpflags=0.

unmanaged

Added in Shorewall 4.5.18. Causes all traffic between the firewall and hosts on the interface to be accepted. When this option is given:

•The ZONE column must contain '-'.

•Only the following other options are allowed with unmanaged: arp_filter

arp_ignore

ignore

routefilter

optional

physical

routefilter

proxyarp

proxyudp

sourceroute

upnp

Incoming requests from this interface may be remapped via UPNP (upnpd). See http://www.shorewall.net/UPnP.html[18]. Supported in IPv4 and in IPv6 in Shorewall 5.1.4 and later.

upnpclient

This option is intended for laptop users who always run Shorewall on their system yet need to run UPnP-enabled client apps such as Transmission (BitTorrent client). The option causes Shorewall to detect the default gateway through the interface and to accept UDP packets from that gateway. Note that, like all aspects of UPnP, this is a security hole so use this option at your own risk. Supported in IPv4 and in IPv6 in Shorewall 5.1.4 and later.

wait=seconds

Added in Shorewall 4.4.10. Causes the generated script to wait up to seconds seconds for the interface to become usable before applying the required or optional options.

## EXAMPLE
IPv4 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 its 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 iptables and/or kernel do not support "Address Type Match" and you prefer to specify broadcast addresses explicitly rather than having Shorewall detect them. Your entries for this setup would look like:

```
?FORMAT 1
#ZONE   INTERFACE BROADCAST        OPTIONS
net     eth0      206.191.149.223  dhcp
loc     eth1      192.168.1.255
dmz     eth2      192.168.2.255
```

Example 2:

The same configuration without specifying broadcast addresses is:

```
?FORMAT 2
#ZONE   INTERFACE OPTIONS
net     eth0      dhcp
loc     eth1
dmz     eth2
```

Example 3:

You have a simple dial-in system with no Ethernet connections.

```
?FORMAT 2
#ZONE   INTERFACE OPTIONS
net     ppp0      -
```

Example 4 (Shorewall 4.4.9 and later):

You have a bridge with no IP address and you want to allow traffic through the bridge.

```
?FORMAT 2
#ZONE   INTERFACE OPTIONS
-       br0       bridge
```

## FILES
/etc/shorewall/interfaces

/etc/shorewall6/interfaces

## SEE ALSO
http://www.shorewall.net/configuration_file_basics.htm#Pairs[19]

shorewall(8)

## NOTES
1.

shorewall-hosts

http://www.shorewall.net/manpages/shorewall-hosts.html

2.

http://www.shorewall.net/FAQ.htm#faq18

http://www.shorewall.net/FAQ.htm#faq18

3.

shorewall-nesting

http://www.shorewall.net/manpages/shorewall-nesting.html

4.

shorewall6-zones

http://www.shorewall.net/manpages6/shorewall6-zones.html

5.

Proxy ARP

http://www.shorewall.net/ProxyARP.htm

6.

shorewall-blacklist

http://www.shorewall.net/manpages/shorewall-blacklist.html

7.

shorewall-zones

http://www.shorewall.net/manpages/shorewall-zones.html

8.

shorewall.conf(5)

http://www.shorewall.net/manpages/shorewall.conf.html

9.

simple bridge

http://www.shorewall.net/SimpleBridge.html

10.

Shorewall-perl for firewall/bridging

http://www.shorewall.net/bridge-Shorewall-perl.html

11.

shorewall-rules

http://www.shorewall.net/manpages/shorewall-rules.html

12.

shorewall-maclist

http://www.shorewall.net/manpages/shorewall-maclist.html

13.

http://www.shorewall.net/Dynamic.html

http://www.shorewall.net/Dynamic.html

14.

http://www.shorewall.net/bridge-Shorewall-perl.html#Multiple

http://www.shorewall.net/bridge-Shorewall-perl.html#Multiple

15.

shorewall-proxyarp

http://www.shorewall.net/manpages/shorewall-proxyarp.html

16.

http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html.

http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html

17.

shorewall-providers

http://www.shorewall.net/manpages/shorewall-providers.html

18.

http://www.shorewall.net/UPnP.html

http://www.shorewall.net/UPnP.html

19.

http://www.shorewall.net/configuration_file_basics.htm#Pairs

http://www.shorewall.net/configuration_file_basics.htm#Pairs


shorewall-ipsets

title: shorewall-ipsets(5)

text:
# shorewall-ipsets(5)

## NAME
ipsets - Specifying the name if an ipset in Shorewall configuration files

## SYNOPSIS
+ipsetname

+ipsetname[flag,...]

+[ipsetname,...]

## DESCRIPTION
Note: In the above syntax descriptions, the square brackets ("[]") are to be taken literally rather than as meta-characters.

In most places where a network address may be entered, an ipset may be substituted. Set names must be prefixed by the character "+", must start with a letter and may be composed of alphanumeric characters, "-" and "_".

Whether the set is matched against the packet source or destination is determined by which column the set name appears (SOURCE or DEST). For those set types that specify a tuple, two alternative syntaxes are available:

[number] - Indicates that 'src' or

'dst' should be repeated number times.

Example: myset[2].

[flag,...] where

flag is src or

dst. Example: myset[src,dst].

In a SOURCE or SPORT column, the following pairs are equivalent:

•+myset[2] and +myset[src,src]

In a DEST or DPORT column, the following pairs are equivalent:

•+myset[2] and +myset[dst,dst]

Beginning with Shorewall 4.4.14, multiple source or destination matches may be specified by enclosing the set names within +[...]. The set names need not be prefixed with '+'. When such a list of sets is specified, matching packets must match all of the listed sets.

For information about set lists and exclusion, see shorewall-exclusion[1] (5).

Beginning with Shorewall 4.5.16, you can increment one or more nfacct objects each time a packet matches an ipset. You do that by listing the objects separated by commas within parentheses.

Example:

+myset[src](myobject)

In that example, when the source address of a packet matches the myset ipset, the myobject nfacct counter will be incremented.

Beginning with Shorewall 4.6.0, an ipset name (and src/dst list, if any) can be immediately be followed by a list of match options.

Important

These additional match options are not available in shorewall-tcfilters(5)[2].

Available options are:

nomatch

If the set type supports the nomatch flag, then the matching is reversed: a match with an element flagged with nomatch returns true, while a match with a plain element returns false. This option requires the 'Ipset Match nomatch' capability in your kernel and ip[6]tables.

no-update-counters

The packet and byte counters of the matching element in the set won't be updated. By default, the packet and byte counters are updated. This option and those that follow require the 'Ipset Match counters' capability in your kernel and ip[6]tables.

no-update-subcounters

The packet and byte counters of the matching element in the member set of a list type of set won't be updated. Default the packet and byte counters are updated.

packets=value

If the packet is matched an element in the set, match only if the packet counter of the element matches the given value also.

packets<value

If the packet is matched an element in the set, match only if the packet counter of the element is less than the given value as well.

packets>value

If the packet is matched an element in the set, match only if the packet counter of the element is greater than the given value as well.

packets!=value

If the packet is matched an element in the set, match only if the packet counter of the element does not match the given value also.

bytes=value

If the packet is matched an element in the set, match only if the byte counter of the element matches the given value also.

bytes<value

If the packet is matched an element in the set, match only if the byte counter of the element is less than the given value as well.

bytes>value

If the packet is matched an element in the set, match only if the byte counter of the element is greater than the given value as well.

bytes<>value

If the packet is matched an element in the set, match only if the byte counter of the element does not match the given value also.

## EXAMPLES
In the examples that follow, myset, myset1 and myset2 are ipsets and myObject is an NFacct object name.

+myset

+myset[src]

+myset[2]

+[myset1,myset2[dst]]

+myset[src](myObject)

+myset[src,nomatch,packets>100]

+myset[nomatch,no-update-counters](myObject)

## FILES
/etc/shorewall/accounting

/etc/shorewall6/accounting

/etc/shorewall/blrules

/etc/shorewall6/blrules

/etc/shorewall/hosts -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall6/hosts -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall/maclist -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall6/maclist -- Note: Multiple matches enclosed in +[...] may not be used in this file.

/etc/shorewall/rules

/etc/shorewall6/rules

/etc/shorewall/secmarks

/etc/shorewall6/secmarks

/etc/shorewall/mangle

/etc/shorewall6/mangle

/etc/shorewall/snat

/etc/shorewall6/snat

## SEE ALSO
shorewall(8)

## NOTES
1.

shorewall-exclusion

http://www.shorewall.net/manpages/shorewall-exclusion.html

2.

shorewall-tcfilters(5)

http://www.shorewall.net/manpages/shorewall-tcfilters.html


shorewall-logging

title: shorewall-logging(5)

summary: Shorewall logging

text:
# shorewall-logging(5)

## NAME
logging - Shorewall logging

## SYNOPSIS
action:level

NFLOG(nflog-parameters)

ULOG(ulog-parameters)

## DESCRIPTION
The disposition of packets entering a Shorewall firewall is determined by one of a number of Shorewall facilities. Only some of these facilities permit logging.

1.The packet is part of an established connection. While the packet can be logged using LOG rules in the ESTABLISHED section of /etc/shorewall/rules[1], that is not recommended because of the large amount of information that may be logged.

2.The packet represents a connection request that is related to an established connection (such as a data connection associated with an FTP control connection[2]). These packets may be logged using LOG rules in the RELATED section of shorewall-rules(5)[1].

3.The packet is rejected because of an option in shorewall.conf[3](5) or shorewall-interfaces(5)[4]. These packets can be logged by setting the appropriate logging-related option in /etc/shorewall/shorewall.conf[3].

4.The packet matches a rule in shorewall-rules[1](5). By including a syslog level (see below) in the ACTION column of a rule (e.g., “ACCEPT:info net $FW tcp 22”), the connection attempt will be logged at that level.

5.The packet doesn't match a rule so it is handled by a policy defined in shorewall-policy(5)[5]. These may be logged by specifying a syslog level in the LOG LEVEL column of the policy's entry (e.g., “loc net ACCEPT info”).

## DEFAULT LOGGING
By default, Shorewall directs Netfilter to log using syslog (8). Syslog classifies log messages by a facility and a priority (using the notation facility.priority).

The facilities defined by syslog are auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, syslog, user, uucp and local0 through local7.

Throughout the Shorewall documentation, the term level rather than priority is used, since level is the term used by Netfilter. The syslog documentation uses the term priority.

## SYSLOG LEVELS
Syslog levels are a method of describing to syslog (8) the importance of a message. A number of Shorewall parameters have a syslog level as their value.

Valid levels are:

7 - debug (Debug-level

messages)

6 - info

(Informational)

5 - notice (Normal but

significant Condition)

4 - warning (Warning

Condition)

3 - err (Error

Condition)

2 - crit (Critical

Conditions)

1 - alert (must be handled

immediately)

0 - emerg (System is

unusable)

For most Shorewall logging, a level of 6 (info) is appropriate. Shorewall log messages are generated by Netfilter and are logged using the kern facility and the level that you specify. If you are unsure of the level to choose, 6 (info) is a safe bet. You may specify levels by name or by number.

Beginning with Shorewall 4.5.5, the level name or number may be optionally followed by a comma-separated list of one or more log options. The list is enclosed in parentheses. Log options cause additional information to be included in each log message.

Valid log options are:

ip_options

Log messages will include the option settings from the IP header.

macdecode

Decode the MAC address and protocol.

tcp_sequence

Include TCP sequence numbers.

tcp_options

Include options from the TCP header.

uid

Include the UID of the sending program; only valid for packets originating on the firewall itself.

Example: info(tcp_options,tcp_sequence)

Syslogd writes log messages to files (typically in /var/log/*) based on their facility and level. The mapping of these facility/level pairs to log files is done in /etc/syslog.conf (5). If you make changes to this file, you must restart syslogd before the changes can take effect.

Syslog may also write to your system console. See Shorewall FAQ 16[6] for ways to avoid having Shorewall messages written to the console.

## CONFIGURING A SEPARATE LOG FOR SHOREWALL MESSAGES (ULOGD)
There are a couple of limitations to syslogd-based logging:

1.If you give, for example, kern.info its own log destination then that destination will also receive all kernel messages of levels 5 (notice) through 0 (emerg).

2.All kernel.info messages will go to that destination and not just those from Netfilter.

3.Netfilter (Shorewall) messages show up in dmesg.

If your kernel has NFLOG target support (and most vendor-supplied kernels do), you may also specify a log level of NFLOG (must be all caps). When NFLOG is used, Shorewall will direct Netfilter to log the related messages via the NFLOG target which will send them to a process called “ulogd”. The ulogd program is included in most distributions.

Note

The NFLOG logging mechanism is completely separate from syslog. Once you switch to NFLOG, the settings in /etc/syslog.conf have absolutely no effect on your Shorewall logging (except for Shorewall status messages which still go to syslog).

You will need to change all instances of log levels (usually “info”) in your Shorewall configuration files to “NFLOG” - this includes entries in the policy, rules and shorewall.conf files. If you initially installed using Shorewall 5.1.2 or later, you can simply change the setting of LOG_LEVEL in shorewall.conf.

## UNDERSTANDING THE CONTENTS OF SHOREWALL LOG MESSAGES
For general information on the contents of Netfilter log messages, see http://logi.cc/en/2010/07/netfilter-log-format/.

For Shorewall-specific information, see FAQ #17[7].

## CUSTOMIZING THE CONTENT OF SHOREWALL LOG MESSAGES
In a Shorewall logging rule, the log level can be followed by a log tag as in "DROP:NFLOG:junk". The generated log message will include "chain-name junk DROP".

By setting the LOGTAGONLY option to Yes in shorewall.conf(5)[8] or shorewall6.conf(5)[9], the disposition ('DROP' in the above example) will be omitted. Consider the following rule:

```
#ACTION                                    SOURCE          DEST           PROTO
REJECT(icmp-proto-unreachable):notice:IPv6 loc             net            41      # who's using IPv6 tunneling
```

This rule generates the following warning at compile time:

WARNING: Log Prefix shortened to "Shorewall:IPv6:REJECT(icmp-p "

/etc/shorewall/rules (line 212)

and produces the rather ugly prefix "Shorewall:IPv6:REJECT(icmp-p ".

Now consider this similar rule:

```
#ACTION                                              SOURCE          DEST           PROTO
REJECT(icmp-proto-unreachable):notice:IPv6,tunneling loc             net            41      # who's using IPv6 tunneling
```

With LOGTAGONLY=Yes, no warning is generated and the prefix becomes "Shorewall:IPv6:tunneling:"

See the shorewall[6].conf man page[10] for further information about how LOGTAGONLY=Yes can be used.

## LOG BACKENDS
Netfilter logging allows configuration of multiple backends. Logging backends provide the The low-level forward of log messages. There are currently three backends:

LOG (ipt_LOG and ip6t_LOG).

Normal kernel-based logging to a syslog daemon.

ULOG (ipt_ULOG)

ULOG logging as described ablve. Only available for IPv4.

netlink (nfnetlink_log)

The logging backend behind NFLOG, defined above.

The currently-available and currently-selected IPv4 and IPv6 backends are shown in /proc/sys/net/netfilter/nf_log:

```
cat /proc/net/netfilter/nf_log

 0 NONE (nfnetlink_log)

 1 NONE (nfnetlink_log)

 2 ipt_ULOG (ipt_ULOG,ipt_LOG,nfnetlink_log)

 3 NONE (nfnetlink_log)

 4 NONE (nfnetlink_log)

 5 NONE (nfnetlink_log)

 6 NONE (nfnetlink_log)

 7 NONE (nfnetlink_log)

 8 NONE (nfnetlink_log)

 9 NONE (nfnetlink_log)
10 ip6t_LOG (ip6t_LOG,nfnetlink_log)
11 NONE (nfnetlink_log)
12 NONE (nfnetlink_log)
```

The magic numbers (0-12) are Linux address family numbers (AF_INET is 2 and AF_INET6 is 10).

The name immediately following the number is the currently-selected backend, and the ones in parentheses are the ones that are available. You can change the currently selected backend by echoing it's name into /proc/net/netfilter/nf_log.number.

Example - change the IPv4 backend to LOG:

```
sysctl net.netfilter.nf_log.2=ipt_LOG
```

Beginning with Shorewall 4.6.4, you can configure the backend using the LOG_BACKEND option in shorewall.conf(5)[3] and shorewall6.conf(5)[11].

## SEE ALSO
http://www.shorewall.net/shorewall_logging.html[12]

## NOTES
1.

/etc/shorewall/rules

http://www.shorewall.netmanpages/shorewall-rules.html

2.

data connection associated with an FTP control connection

http://www.shorewall.netFTP.html

3.

shorewall.conf

http://www.shorewall.netmanpages/shorewall.conf.html

4.

shorewall-interfaces(5)

http://www.shorewall.netmanpages/shorewall-interfaces.html

5.

shorewall-policy(5)

http://www.shorewall.netmanpages/shorewall-policy.html

6.

Shorewall FAQ 16

http://www.shorewall.netFAQ.htm#faq16

7.

FAQ #17

http://www.shorewall.net/FAQ.htm#faq17

8.

shorewall.conf(5)

http://www.shorewall.net/manpages/shorewall.conf.html

9.

shorewall6.conf(5)

http://www.shorewall.net/manpages6/shorewall6.conf.html

10.

shorewall[6].conf man page

http://www.shorewall.netshorewall.conf.html

11.

shorewall6.conf(5)

http://www.shorewall.netmanpages6/shorewall6.conf.html

12.

http://www.shorewall.net/shorewall_logging.html

http://www.shorewall.net/shorewall_logging.htm


shorewall-maclist

title: shorewall-maclist(5)

summary: Shorewall MAC Verification file

text:
# shorewall-maclist(5)

## NAME
maclist - Shorewall MAC Verification file

## SYNOPSIS
/etc/shorewall[6]/maclist

## DESCRIPTION
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 shorewall-interfaces[1](5) or shorewall-hosts[2](5) configuration file.

The columns in the file are as follows (where the column name is followed by a different name in parentheses, the different name is used in the alternate specification syntax).

DISPOSITION - {ACCEPT|DROP|REJECT}[:log-level]

ACCEPT or DROP (if MACLIST_TABLE=filter in shorewall.conf[3](5), then REJECT is also allowed). If specified, the log-level causes packets matching the rule to be logged at that level.

INTERFACE - interface

Network interface to a host.

MAC - address

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 (addresses) - [address[,address]...]

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. Similarly, if your kernel and iptables include ipset support than set names (prefixed by "+") are also allowed.

## FILES
/etc/shorewall/maclist

/etc/shorewall6/maclist

## SEE ALSO
http://www.shorewall.net/MAC_Validation.html[4]

http://www.shorewall.net/configuration_file_basics.htm#Pairs[5]

shorewall(8)

## NOTES
1.

shorewall-interfaces

http://www.shorewall.net/manpages/shorewall-interfaces.html

2.

shorewall-hosts

http://www.shorewall.net/manpages/shorewall-hosts.html

3.

shorewall.conf

http://www.shorewall.net/manpages/shorewall.conf.html

4.

http://www.shorewall.net/MAC_Validation.html

http://www.shorewall.net/MAC_Validation.html

5.

http://www.shorewall.net/configuration_file_basics.htm#Pairs

http://www.shorewall.net/configuration_file_basics.htm#Pairs