taylorkh wrote: ↑2019/12/26 21:26:45
Zones are simple and I can visualize such a setup. Tables and chains I have some understanding of. How zones, tables, chains and the kernel routing table relate I will admit I can not picture in my mind. Using iptables to plug a rule into the FORWARD chain I can see would stop the traffic as I intend.
Firewalld is a
front-end, an attempt to provide simpler user interface to the netfilter/nftables.
A single firewall-cmd command can create/modify multiple related rules in the netfilter.
Zones are one abstraction used by firewalld.
iptables (aka netfilter) and routing are far older. See Figure 3b in
https://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html
You admit that you don't understand iptables. (To convert from something that you don't understand into something new is the challenge.)
Let say a packet enters from LAN with router as destination.
There is no port-forwarding, so prerouting does not change the packet.
A routing decision is that the packet is for the router. It is directed to the INPUT filter.
Let say a packet enters from LAN with
www.centos.com (a WAN address) as destination.
There is no port-forwarding, so prerouting does not change the packet.
A routing decision is that the packet is to be send out via WAN interface. It is directed to the FORWARD filter.
The FORWARD is set to allow (new) traffic from LAN to WAN.
POSTROUTING is set to masquerade (SNAT) outgoing traffic; the source address in the packet is rewritten to be router's external address.
A reply packet enters from WAN from
www.centos.com and router as destination.
Within prerouting the NAT-engine rewrites the destination to be the LAN device that did send out the initial packet.
A routing decision is that the packet is to be send out via LAN interface. It is directed to the FORWARD filter.
The FORWARD is set to allow replies from WAN to LAN.
Postrouting does nothing.
A packet enters FORWARD chain. The chain is an ordered set of rules. Each rule has a
match and
target.
If packet matches a rule, it will go to the target (and counters for the rule update).
If target is a terminating action: ACCEPT, REJECT, DROP, then the packet's fate is corresponding and no further rules will be checked.
If target is an another chain, the packet will enter that chain. Therein might be a terminating action, or the packet might return to this chain.
An example:
Code: Select all
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6 640 INPUT_direct all -- * * 0.0.0.0/0 0.0.0.0/0
6 640 INPUT_ZONES_SOURCE all -- * * 0.0.0.0/0 0.0.0.0/0
6 640 INPUT_ZONES all -- * * 0.0.0.0/0 0.0.0.0/0
* Six packets have entered the INPUT
* INPUT_direct matches all packets, so all 6 enter chain INPUT_direct
* nothing in INPUT_direct ends the chain traversal
* INPUT_ZONES_SOURCE matches all packets, so all 6 enter chain INPUT_ZONES_SOURCE
* nothing in INPUT_ZONES_SOURCE ends the chain traversal
* INPUT_ZONES all packets, so all 6 enter chain INPUT_ZONES
* We assume that INPUT_ZONES is the last rule
* Chain INPUT has seen 0 packets after the last rule
* Therefore, some rule in chain INPUT_ZONES (or in chains, where its rules send packets to) must have matched and actioned on all those 6 packets
We would have to look at the chain INPUT_ZONES to see what. More likely look at some more chains too.
Notice how INPUT_ZONES_SOURCE is
before INPUT_ZONES?
When a zone has sources, packets from those sources traversing INPUT will enter the chains of that zone from INPUT_ZONES_SOURCES.
Zone should have terminating action by default. (The 'block' has REJECT.)
Therefore, no packets with that source address will ever reach the INPUT_ZONES chain, where packets enter a zone according to their in interface.
Both INPUT_ZONES_SOURCE and INPUT_ZONES can direct packets to same zone. Some due to their source address, some due to interface.
(RHEL 5 had one custom chain "RH-firewall..." and both INPUT and FORWARD did send packets to it. Reuse is good, but that was restrictive.)
The (sub)chains created by firewalld for FORWARD are similar.
