Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #8565

Re: Need advice solving problems with testing netfilter and ipsets

Show all headers | View raw

On 10/02/2026 16:20, Lew Pitcher wrote:
> 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 did not know that either.  But then, I have not (yet) had occasion to 
use much in the way of iptables in a container - I have the blocking and 
restrictions on a system before traffic gets to the containers' 
networks.  I do some "experiments" planned for playing around with 
different network ideas, and it is not inconceivable that I will do some 
of it from within containers (rather than just small kvm virtual 
machines), so I that is a handy tip.

> 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

Thanks for posting the "this is how I fixed it" follow-up.  Not everyone 
bothers to do that!

Back to comp.os.linux.networking | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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