SHOREWALL-NAMES(5)
okay bestie, sit down, hydrate π β this is the shorewall-names page, section 5 of the Configuration Files manual, aka the one that tells you what you're actually allowed to call your Shorewall stuff. no cap, naming is a whole vibe check. π
β¨ NAME β¨
names β Shorewall object names π
π¦ DESCRIPTION π¦
So when you define an object in Shorewall (a Zone, a Logical Interface, ipsets, Actions, etc.) you give it a name. and Shorewall names have RULES, bestie:
- They start with a letter and they consist of letters, digits or underscores (
"_"). - Except for Zone names, Shorewall does not impose a limit on name length. go feral, the sky's the limit π
Other name-ish facts you need in your notes app:
- When an ipset is referenced, the name must be preceded by a plus sign (
"+"). it's giving β¨VIPβ¨. - 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". (yes, you chop the@and everything after it. bye π)
π 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 (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 (5). See shorewall-zones (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. read that twice, bestie π
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.conf(5) that affect the use of DNS names in Shorewall config files:
DEFER_DNS_RESOLUTIONβ When set toNo, DNS names are resolved at compile time; when set toYes, DNS Names are resolved at runtime.AUTOMAKEβ When set toYes,start,restartandreloadonly result in compilation if one of the files on theCONFIG_PATHhas 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: WhenDEFER_DNS_RESOLUTION=NoandAUTOMAKE=Yesand a DNS change makes it necessary to recompile an existing firewall script, the-coption must be used with thereloadorrestartcommand 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.confis 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.netshorewall.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/rulesfile) - In the
ADDRESScolumn of an entry in/etc/shorewall/masq. - (the original has a literally empty bullet right here and I'm keeping it, because I keep every single thing π)
- In the
/etc/shorewall/natfile.
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).
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. iconic, honestly π
Here are a couple of more files from the same configuration:
shorewall-masq (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 (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. cute lil glow-up β¨
πΈ NOTES πΈ
- Zone
https://shorewall.org/manpages/shorewall-zones.html - ipsets
https://shorewall.org/manpages/ipsets.html - Actions
https://shorewall.org/manpages/Actions.html - shorewall.conf
https://shorewall.org/manpages/shorewall.conf.html - shorewall-interfaces
https://shorewall.org/manpages/shorewall-interfaces.html - shorewall-masq
https://shorewall.org/manpages/shorewall-masq.html - shorewall-providers
https://shorewall.org/manpages/shorewall-providers.html
and that's the whole thing, bestie π this page lives in the Configuration Files manual, it's dated 09/24/2020, and its very own name is SHOREWALL-NAMES(5) β go name something responsibly, mwah ππ¦
π¦ where this page comes from
- alpine 3.22: shorewall-doc 5.2.8-r1 Β· GPL-2.0-or-later
- alpine 3.23: shorewall-doc 5.2.8-r1 Β· GPL-2.0-or-later
- alpine 3.24: shorewall-doc 5.2.8-r1 Β· GPL-2.0-or-later
- debian bookworm: shorewall 5.2.8-2 Β· GPL-2.0-or-later
- debian trixie: shorewall 5.2.8-6 Β· GPL-2.0-or-later
- fedora 43: shorewall 5.2.8-17.fc43 Β· GPL-2.0-or-later
- fedora 44: shorewall 5.2.8-18.fc44 Β· GPL-2.0-or-later
- nixos 26.05: shorewall 5.2.8
- nixpkgs unstable: shorewall 5.2.8
- ubuntu noble: shorewall 5.2.8-5 Β· GPL-2.0-or-later
- ubuntu questing: shorewall 5.2.8-6
- ubuntu resolute: shorewall 5.2.8-6build1 Β· GPL-2.0-or-later
- ubuntu stonking: shorewall 5.2.8-6build1 Β· GPL-2.0-or-later
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms