Provided by: shorewall_5.2.8-2_all bug

NAME

       names - Shorewall object names

DESCRIPTION

       When you define an object in Shorewall (Zone[1], Logical Interface, ipsets[2], Actions[3],
       etc., you give it a name. Shorewall names start with a letter and consist of letters,
       digits or underscores ("_"). Except for Zone names, Shorewall does not impose a limit on
       name length.

       When an ipset is referenced, the name must be preceded by a plus sign ("+").

       The last character of an interface may also be a plus sign to indicate a wildcard name.

       Physical interface names match names shown by 'ip link ls'; if the name includes an at
       sign ("@"), do not include that character or any character that follows. For example,
       "sit1@NONE" is referred to as simply 'sit1".

ZONE AND CHAIN NAMES

       For a pair of zones, Shorewall creates two Netfilter chains; one for connections in each
       direction. The names of these chains are formed by separating the names of the two zones
       by either "2" or "-".

       Example: Traffic from zone A to zone B would go through chain A2B (think "A to B") or
       "A-B".

       In Shorewall 4.6, the default separator is "-" but you can override that by setting
       ZONE_SEPARATOR="2" in shorewall.conf[4] (5).

           Note
           Prior to Shorewall 4.6, the default separator was "2".

       Zones themselves have names that begin with a letter and are composed of letters,
       numerals, and "_". The maximum length of a name is dependent on the setting of LOGFORMAT
       in shorewall.conf[4] (5). See shorewall-zones[1] (5) for details.

USING DNS NAMES

           Caution
           I personally recommend strongly against using DNS names in Shorewall configuration
           files. If you use DNS names and you are called out of bed at 2:00AM because Shorewall
           won't start as a result of DNS problems then don't say that you were not forewarned.

       Host addresses in Shorewall configuration files may be specified as either IP addresses or
       DNS Names.

       DNS names in iptables rules aren't nearly as useful as they first appear. When a DNS name
       appears in a rule, the iptables utility resolves the name to one or more IP addresses and
       inserts those addresses into the rule. So changes in the DNS->IP address relationship that
       occur after the firewall has started have absolutely no effect on the firewall's rule set.

       For some sites, using DNS names is very risky. Here's an example:

           teastep@ursa:~$ dig pop.gmail.com

           ; <<>> DiG 9.4.2-P1 <<>> pop.gmail.com
           ;; global options:  printcmd
           ;; Got answer:
           ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1774
           ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 7, ADDITIONAL: 0

           ;; QUESTION SECTION:
           ;pop.gmail.com.               IN A

           ;; ANSWER SECTION:
           pop.gmail.com.          300   IN CNAME gmail-pop.l.google.com.
           gmail-pop.l.google.com. 300   IN A     209.85.201.109
           gmail-pop.l.google.com. 300   IN A     209.85.201.111

       Note that the TTL is 300 -- 300 seconds is only 5 minutes. So five minutes later, the
       answer may change!

       So this rule may work for five minutes then suddently stop working:

           #ACTION        SOURCE               DEST              PROTO             DPORT
           POP(ACCEPT)    loc                  net:pop.gmail.com

       There are two options in shorewall[6].conf(5)[4] that affect the use of DNS names in
       Shorewall[6] config files:

       •   DEFER_DNS_RESOLUTION - When set to No, DNS names are resolved at compile time; when
           set to Yes, DNS Names are resolved at runtime.

       •   AUTOMAKE - When set to Yes, start, restart and reload only result in compilation if
           one of the files on the CONFIG_PATH has changed since the the last compilation.

       So by setting AUTOMAKE=Yes, and DEFER_DNS_RESOLUTION=No, compilation will only take place
       at boot time if a change had been make to the config but no restart or reload had taken
       place. This is clearly spelled out in the shorewall.conf manpage. So with these settings,
       so long as a 'reload' or 'restart' takes place after the Shorewall configuration is
       changes, there should be no DNS-related problems at boot time.

           Important
           When DEFER_DNS_RESOLUTION=No and AUTOMAKE=Yes and a DNS change makes it necessary to
           recompile an existing firewall script, the -c option must be used with the reload or
           restart command to force recompilation.

       If your firewall rules include DNS names then, even if DEFER_DNS_RESOLUTION=No and
       AUTOMAKE=Yes:

       •   If your /etc/resolv.confis wrong then your firewall may not start.

       •   If your /etc/nsswitch.conf is wrong then your firewall may not start.

       •   If your Name Server(s) is(are) down then your firewall may not start.

       •   If your startup scripts try to start your firewall before starting your DNS server
           then your firewall may not start.

       •   Factors totally outside your control (your ISP's router is down for example), can
           prevent your firewall from starting.

       •   You must bring up your network interfaces prior to starting your firewall, or the
           firewall may not start.

       Each DNS name must be fully qualified and include a minimum of two periods (although one
       may be trailing). This restriction is imposed by Shorewall to insure backward
       compatibility with existing configuration files.

       Example 1. Valid DNS Names

       •   mail.shorewall.net

       •   shorewall.net. (note the trailing period).

       Example 2. Invalid DNS Names

       •   mail (not fully qualified)

       •   shorewall.net (only one period)

       DNS names may not be used as:

       •   The server address in a DNAT rule (/etc/shorewall/rules file)

       •   In the ADDRESS column of an entry in /etc/shorewall/masq.

       •

       •   In the /etc/shorewall/nat file.

       These restrictions are imposed by Netfilter and not by Shorewall.

LOGICAL INTERFACE NAMES

       When dealing with a complex configuration, it is often awkward to use physical interface
       names in the Shorewall configuration.

       •   You need to remember which interface is which.

       •   If you move the configuration to another firewall, the interface names might not be
           the same.

       Beginning with Shorewall 4.4.4, you can use logical interface names which are mapped to
       the actual interface using the physical option in shorewall-interfaces[5] (5).

       Here is an example:

           #ZONE  INTERFACE  OPTIONS
           net    COM_IF     dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nosmurfs,logmartians=0,physical=eth0
           net    EXT_IF     dhcp,blacklist,tcpflags,optional,routefilter=0,nosmurfs,logmartians=0,proxyarp=1,physical=eth2
           loc    INT_IF     dhcp,logmartians=1,routefilter=1,tcpflags,nets=172.20.1.0/24,physical=eth1
           dmz    VPS_IF     logmartians=1,routefilter=0,routeback,physical=venet0
           loc    TUN_IF     physical=tun+

       In this example, COM_IF is a logical interface name that refers to Ethernet interface
       eth0, EXT_IF is a logical interface name that refers to Ethernet interface eth2, and so
       on.

       Here are a couple of more files from the same configuration:

       shorewall-masq[6] (5):

           #INTERFACE SOURCE                    ADDRESS

           COMMENT Masquerade Local Network
           COM_IF     0.0.0.0/0
           EXT_IF     !206.124.146.0/24         206.124.146.179:persistent

       shorewall-providers[7] (5)

           #NAME   NUMBER   MARK    DUPLICATE  INTERFACE  GATEWAY         OPTIONS               COPY
           Avvanta 1        0x10000 main       EXT_IF     206.124.146.254 loose,fallback        INT_IF,VPS_IF,TUN_IF
           Comcast 2        0x20000 main       COM_IF     detect          balance               INT_IF,VPS_IF,TUN_IF

       Note in particular that Shorewall translates TUN_IF to tun* in the COPY column.

NOTES

        1. Zone
           https://shorewall.org/manpages/shorewall-zones.html

        2. ipsets
           https://shorewall.org/manpages/ipsets.html

        3. Actions
           https://shorewall.org/manpages/Actions.html

        4. shorewall.conf
           https://shorewall.org/manpages/shorewall.conf.html

        5. shorewall-interfaces
           https://shorewall.org/manpages/shorewall-interfaces.html

        6. shorewall-masq
           https://shorewall.org/manpages/shorewall-masq.html

        7. shorewall-providers
           https://shorewall.org/manpages/shorewall-providers.html