Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Lew Pitcher <lew.pitcher@digitalfreehold.ca>
Newsgroups: comp.os.linux.networking
Subject: Need advice solving problems with testing netfilter and ipsets
Date: Mon, 9 Feb 2026 17:51:56 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <10md6rs$2ucqu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 09 Feb 2026 17:51:58 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="b647d841a40346ec54790ce56b749fc9"; logging-data="3093342"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/1epYXcKFSpYcZMwS7Il3ktf880fn54wA="
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2)
Cancel-Lock: sha1:8MP9tYuAhDjqQjHPlEutyiIfq7E=
Xref: csiph.com comp.os.linux.networking:8560

Question: Does anyone see a problem with the ipsets/iptables rules
that I've built, below? 

I run my router/firewall system on 64bit Slackware 14.2 (kernel 4.4.301,
iptables 1.6.0, ipset 6.20) and recently have undertaken a project to
isolate several of my internal hosts through the use of iptables and
ipsets.

The goal is to, without disrupting the lan and internet communication of
the other hosts on my lan networks, ensure that a specified set of hosts
(specified by IP address) can communicate with other hosts on my lan
networks, but NOT with the internet.

The solution I am testing (in a containerize virtual environment modeled
after my lan and router/firewall configuration) utilizes two ipsets and
an iptables rule.

The sets are:
  # Build an ipset list of all the internal hosts that
  # we prevent from obtaining outgoing internet access
  # Only one untrusted device in this list for testing
  ipset create IMMURED hash:ip family inet
  ipset add IMMURED 192.168.55.10

  # Build an ipset list of all the internal networks
  # that we allow the IMMURED host to access
  ipset create LOCALNETS hash:net family inet
  ipset add LOCALNETS 192.168.55.0/24
  ipset add LOCALNETS 192.168.56.0/24

and the model iptables rule is
  iptables -t filter -P FORWARD DROP
  iptables -t filter -A FORWARD -i lo	-j ACCEPT
  iptables -t filter -i eth1				\
	   -m set --match-set IMMURED src 		\
	   -m set ! --match-setset LOCALNETS dst	\
	   -j LOG --log-level notice --log-prefix 'netfilter (immured debug)'
  iptables -t filter -A FORWARD -i eth1	-j ACCEPT
  iptables -t filter -A FORWARD -i eth0	-j ACCEPT

In this version, I simply report attempts, but the final version will,
instead, both report AND reject attempts with an additional rule that
will
  -j REJECT --reject-with icmp-admin-prohibited

In testing this (the "reporting" version) in a virtualized environment,
I can see that iptables invokes my reporting rule by watching the
associated packet count increase appropriately.

However, I /do not/ see my logging sentinal ('netfilter (immured debug)')
in any syslog. 

I can (and will) attempt the "-j REJECT" version, but the problem of
logging remains. In production, I'll use this log to determine which
of these (untrusted) devices attempt to access the internet, so I can
make further network adjustments as necessary.

So, my question:

Does anyone see a problem with the ipsets/iptables rules that I've
generated? Will they do what I want, as I have outlined above?


-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.