I'm running firewalld in a router that connects the devices in my home LAN
I have recently added IPv6 DHCPv6 config to the router, and prefix
delegation works, so
the devices in my home LAN get proper IPv6 addresses.
However, I don't like the idea that all IPv6 enabled devices in my home LAN
IPv6 addresses. I'd very much prefer simple IPv4 -style NAT approach to
devices in home LAN from being accessed from the internet.
How do I implement something like this with firewalld in the router?
ip6tables -A FORWARD -m state --state NEW -i $lanif -o $wanif -j ACCEPT
ip6tables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
ip6tables -P FORWARD DROP
Other ways to protect the devices in my home LAN being accessed from the
Sorry if this has already been answered, but I haven't been able to
If I have a rule with a LOG argument, in what file can I see the logs
of connections that match that rule? (In case it makes a difference,
I'm using firewalld 0.4.4.4 on RHEL 7.)
I'm new to firewalld, adapting my env for SLE15 release.
I have a set of zones based on source which selectively open services. They
all use target default.
I want to enable LogDenied but I wish to filter out some sources (that
frequently scans for open ports).
Also, I want to limit the amount of LogDenied msg per time (to avoid DoS
caused by logs).
I tested these solutions:
1) Issue direct passthough commands to insert the filter just before log
reject rule. I need to previously know the
rulenum position that is before log reject rule;
2) Add 0.0.0.0/0 to a zone foo and use it as the default zone. Default zone
is then used as a drop/reject only zone. Configure logs as needed using
rich rules in drop/reject only zone.
I think that this breaks the logic what default zone is.
The problems I face:
a) LogDenied is opaque. You cannot change it but with direct passthough.
Maybe it could be configured as a "special zone";
b) Direct passthough depends on a variable rulenum that can change
depending on env setup. I cannot use relative positions like "before the
last two rules";
c) Rich rules cannot be used to log connections that did not match (not
allowed) in the zone as IN_<zone>_log comes before IN_<zone>_reject and
(OK, I could reimplement the opposite of all rules that accepts connections
but it would be too complex to manage)
Is there a better solution for all this? A trick with rich rules?
Maybe it would be nice if LogDenied would be a dedicated target chain in
INPUT/FORWARD (i.e.: IN_public_log_denied) or even a generic
IN_public_missed (for connections that did not match any rule inside this
chain, independently from LogDenied value). This way I could insert with
direct passthough rules into this chain for default zone just before
logging (from zone_reject or final_reject).
Luiz Angelo Daros de Luca