Groups | Search | Server Info | Login | Register
Groups > comp.os.linux.networking > #8564
| 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 | Re: Need advice solving problems with testing netfilter and ipsets |
| Date | Tue, 10 Feb 2026 15:20:36 -0000 (UTC) |
| Organization | A noiseless patient Spider |
| Lines | 93 |
| Message-ID | <10mfic4$3n91g$1@dont-email.me> (permalink) |
| References | <10md6rs$2ucqu$1@dont-email.me> <10mesld$3g28q$1@dont-email.me> |
| MIME-Version | 1.0 |
| Content-Type | text/plain; charset=UTF-8 |
| Content-Transfer-Encoding | 8bit |
| Injection-Date | Tue, 10 Feb 2026 15:20:38 +0000 (UTC) |
| Injection-Info | dont-email.me; posting-host="eed837717e87c0a0a4487fba31a0ef26"; logging-data="3908656"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/EjBfijrgCMcy3EkgwI+QyYEmdLQr27MU=" |
| User-Agent | Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) |
| Cancel-Lock | sha1:nRRP3kR55sL3FZ1Ir4ld7e2qI8s= |
| Xref | csiph.com comp.os.linux.networking:8564 |
Show key headers only | View raw
Hi, David
On Tue, 10 Feb 2026 10:10:05 +0100, David Brown wrote:
> On 09/02/2026 18:51, 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.
[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.
[snip]
>> 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
--
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
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