Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #8562
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Newsgroups | comp.os.linux.networking |
| Subject | Re: Need advice solving problems with testing netfilter and ipsets |
| Date | 2026-02-09 18:39 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <10md9lb$2ucqu$3@dont-email.me> (permalink) |
| References | <10md6rs$2ucqu$1@dont-email.me> <10md70n$2ucqu$2@dont-email.me> |
On Mon, 09 Feb 2026 17:54:31 +0000, Lew Pitcher wrote:
> 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
I should add, for completeness that, on the router/firewall system,
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.11.32 netmask 255.255.255.0 broadcast 192.168.11.255
inet6 fe80::3886:c1ff:fe05:7861 prefixlen 64 scopeid 0x20<link>
ether 3a:86:c1:05:78:61 txqueuelen 1000 (Ethernet)
RX packets 15803 bytes 3619618 (3.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 15025 bytes 6675368 (6.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.1 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::1071:8fff:fe62:a88e prefixlen 64 scopeid 0x20<link>
ether 12:71:8f:62:a8:8e txqueuelen 1000 (Ethernet)
RX packets 80 bytes 7000 (6.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 52 bytes 4792 (4.6 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 29275 bytes 8948096 (8.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 29275 bytes 8948096 (8.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.11.3 0.0.0.0 UG 1 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.11.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
where 192.168.55.0/24 represents "my LAN", and 192.168.11.0/24 represents
"the internet".
On the untrusted system,
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.55.10 netmask 255.255.255.0 broadcast 192.168.55.255
inet6 fe80::c09d:fdff:fefe:2ffc prefixlen 64 scopeid 0x20<link>
ether c2:9d:fd:fe:2f:fc txqueuelen 1000 (Ethernet)
RX packets 44 bytes 3784 (3.6 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 59 bytes 5254 (5.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.55.1 0.0.0.0 UG 1 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
192.168.55.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
where 192.168.55.0/24 represents "my LAN"
>> 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.
Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Need advice solving problems with testing netfilter and ipsets Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-09 17:51 +0000
Re: Need advice solving problems with testing netfilter and ipsets Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-09 17:54 +0000
Re: Need advice solving problems with testing netfilter and ipsets Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-09 18:39 +0000
Re: Need advice solving problems with testing netfilter and ipsets David Brown <david.brown@hesbynett.no> - 2026-02-10 10:10 +0100
Re: Need advice solving problems with testing netfilter and ipsets Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-10 15:20 +0000
Re: Need advice solving problems with testing netfilter and ipsets David Brown <david.brown@hesbynett.no> - 2026-02-10 21:13 +0100
Re: Need advice solving problems with testing netfilter and ipsets Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-02-18 19:52 +0000
Re: Need advice solving problems with testing netfilter and ipsets David Brown <david.brown@hesbynett.no> - 2026-02-18 21:12 +0100
csiph-web