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

Groups > comp.os.linux.networking > #8560 > unrolled thread

Need advice solving problems with testing netfilter and ipsets

Started byLew Pitcher <lew.pitcher@digitalfreehold.ca>
First post2026-02-09 17:51 +0000
Last post2026-02-18 21:12 +0100
Articles 8 — 2 participants

Back to article view | Back to comp.os.linux.networking

Contents

  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

#8560 — Need advice solving problems with testing netfilter and ipsets

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2026-02-09 17:51 +0000
SubjectNeed advice solving problems with testing netfilter and ipsets
Message-ID<10md6rs$2ucqu$1@dont-email.me>
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.

[toc] | [next] | [standalone]

#8561

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2026-02-09 17:54 +0000
Message-ID<10md70n$2ucqu$2@dont-email.me>
In reply to#8560
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?




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

[toc] | [prev] | [next] | [standalone]

#8562

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2026-02-09 18:39 +0000
Message-ID<10md9lb$2ucqu$3@dont-email.me>
In reply to#8561
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.

[toc] | [prev] | [next] | [standalone]

#8563

FromDavid Brown <david.brown@hesbynett.no>
Date2026-02-10 10:10 +0100
Message-ID<10mesld$3g28q$1@dont-email.me>
In reply to#8560
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.
> 
> 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?
> 
> 

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.

[toc] | [prev] | [next] | [standalone]

#8564

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2026-02-10 15:20 +0000
Message-ID<10mfic4$3n91g$1@dont-email.me>
In reply to#8563
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.

[toc] | [prev] | [next] | [standalone]

#8565

FromDavid Brown <david.brown@hesbynett.no>
Date2026-02-10 21:13 +0100
Message-ID<10mg3ge$3umbh$1@dont-email.me>
In reply to#8564
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!

[toc] | [prev] | [next] | [standalone]

#8567

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2026-02-18 19:52 +0000
Message-ID<10n55ab$2p9q6$1@dont-email.me>
In reply to#8563
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?
[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
>> 
[snip]
> 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?

[snip]

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

[toc] | [prev] | [next] | [standalone]

#8568

FromDavid Brown <david.brown@hesbynett.no>
Date2026-02-18 21:12 +0100
Message-ID<10n56fq$2uej6$1@dont-email.me>
In reply to#8567
On 18/02/2026 20:52, Lew Pitcher wrote:
> 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?
> [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
>>>
> [snip]
>> 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?
> 

I believe so, yes.  (I am confident enough for my own use, but I am 
always wary of being over-confident when giving advice to others.) 
FORWARD is for packets moving through the system, not originating on it. 
  Your packets from local services do not start at the "lo" interface - 
they are OUTPUT from your local service or program on whatever interface 
fits the target, according to routing tables.

<https://www.baeldung.com/linux/iptables-output-vs-forward-chains>
<https://www.baeldung.com/linux/iptables-chains-tables-traversal>
<https://dtsec.us/2022-03-28-iptables/>

You can also test this quite easily, as iptables rules keep counters. 
Set up your rules, send some packets back and forth, then use "iptables 
-v -n -L FORWARD" to look at the counters for the rules.  If the counter 
is 0, the rule is never being hit.

(The modern tool to use is "nftables" rather than "iptables".  I have 
not moved over as yet - I am too used to iptables.)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web