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?
On Mon, 09 Feb 2026 17:51:56 +0000, Lew Pitcher wrote:
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)'
Yes, there's a typo. I fixed it on the host, but forgot to fix
my records. The real statement reads
iptables -t filter -i eth1 \
-m set --match-set IMMURED src \
-m set ! --match-set 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?
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?
On 09/02/2026 18:51, Lew Pitcher wrote:[snip]
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.
[snip]
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-sets 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
[snip]
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.
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?
I'm not sure if I'm being much help here, but maybe a reply can
encourage others...
I don't see anything immediately wrong with your rules here (other than
the typo you found yourself). I think the rule forwarding packets from
"lo" is redundant (local packets go out on OUTPUT, not FORWARD), but I
don't imagine it is doing any harm.
Were I doing this, the next steps would be to split the match rule into
two, with different logging on each, to see if those showed matches.
And I'd check the hit counters for the iptables rules after sending some test pings from the IMMURED machine, to trace which rules were triggered.
Hi, David
On Tue, 10 Feb 2026 10:10:05 +0100, David Brown wrote:
On 09/02/2026 18:51, Lew Pitcher wrote:[snip]
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.
[snip]
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-sets 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
[snip]
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.
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?
I'm not sure if I'm being much help here, but maybe a reply can
encourage others...
I don't see anything immediately wrong with your rules here (other than
the typo you found yourself). I think the rule forwarding packets from
"lo" is redundant (local packets go out on OUTPUT, not FORWARD), but I
don't imagine it is doing any harm.
Were I doing this, the next steps would be to split the match rule into
two, with different logging on each, to see if those showed matches.
And I'd check the hit counters for the iptables rules after sending some
test pings from the IMMURED machine, to trace which rules were triggered.
Thanks for the advice. I will follow up on your comment regarding 'lo' and see if it is as redundant as you say. If so, then I'll drop that rule out.
I /did/ find out why my logging wasn't working. It was, but it was suppressed.
For kernels below 4.11 (which my production system is) netfilter logging from containers is suppressed /by the kernel/ (for performance and security reasons). For kernels >= 4.11 (which my development system uses), netfilter logging from containers is suppressed by the kernel, UNLESS you explicitly permit it by setting /proc/sys/net/netfilter/nf_log_all_netns
This, I didn't know.
I retested my test rule in a container on my development system, this time with /proc/sys/net/netfilter/nf_log_all_netns set to 1, and got the expected log message when the iptables rule fired (the log message does not appear
in the container's syslog, but in the host's syslog).
With that little bit of testing proven, I can now move on to the "drop packet" rule, and know that, when I get to production both the log
and drop rules will work.
Thanks again for the assist
On 09/02/2026 18:51, Lew Pitcher wrote:[snip
Question: Does anyone see a problem with the ipsets/iptables rules
that I've built, below?
[snip]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
I don't see anything immediately wrong with your rules here (other than
the typo you found yourself). I think the rule forwarding packets from
"lo" is redundant (local packets go out on OUTPUT, not FORWARD), but I
don't imagine it is doing any harm.
On Tue, 10 Feb 2026 10:10:05 +0100, David Brown wrote:
On 09/02/2026 18:51, Lew Pitcher wrote:[snip
Question: Does anyone see a problem with the ipsets/iptables rules
that I've built, below?
[snip]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
I don't see anything immediately wrong with your rules here (other than
the typo you found yourself). I think the rule forwarding packets from
"lo" is redundant (local packets go out on OUTPUT, not FORWARD), but I
don't imagine it is doing any harm.
The key here is "local packets". I wrote these rules as bullet-proof as
I could make them. One scenario that I considered was "process bind()s to localhost, sends packets to host on external network".
If I understand the sequence of events properly, in this scenario, packets originating from the localhost address would traverse
- the OUTPUT chain,
- the POSTROUTING chain,
- the lo interface
- the PREROUTING chain,
- the FORWARD chain (because the packets are destined for an external address),
- the POSTROUTING chain (again), and
- the interface that hosts the route to the next hop.
and, thus I wanted a rule that overrode the default "DROP" rule I had imposed on the FORWARD chain.
I know that "lo" and 127.0.0.1 are special cases that would preclude TCP (return routing wouldn't work properly), but I don't know if it also affects UDP or raw packets, were return routing isn't expected by the protocol.
Was I mistaken in this?
| Sysop: | Luis Silva |
|---|---|
| Location: | Lisbon |
| Users: | 768 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 22:35:44 |
| Calls: | 608 |
| Files: | 46,973 |
| Messages: | 14,928 |