* Re: Question on rate limiting on nftables
From: Gordon Fisher @ 2026-06-26 17:04 UTC (permalink / raw)
To: Reindl Harald, Andre Rodier, Slavko, netfilter
In-Reply-To: <1bdfe5c3-f889-4464-a28e-9533e209371c@thelounge.net>
On 6/8/26 9:05 AM, Reindl Harald wrote:
>
>
> Am 08.06.26 um 17:01 schrieb Andre Rodier:
>> On Mon, 2026-06-08 at 14:32 +0000, Slavko wrote:
>>> Dňa 8. júna 2026 12:45:55 UTC používateľ Kerin Millar
>>> <kfm@plushkava.net> napísal:
>>>
>>>> If the problem can be characterised as "I endure too much log noise
>>>> from sshd and I find it annoying" then perhaps configure sshd(8) to
>>>> additionally bind to some other random port than 22 and expose only
>>>> that port.
>>>
>>> Not worth of change ports, soon or latter it will be found
>>> and abused as default port.
>>
>> There is a big advantage on changing the port number, though. It is
>> reducing the noise considerably. Also, a connection attempts on a
>> different port should immediately raise attention, as it is involving
>> more than a basic SSH scan bot
>
> and in fact you can have a few ports before as trigger to put the IP
> on a drop-list for a few minutes which isn't possible when you host
> ftp servers
>
Which raises the question, why are people still using ye olde FTP still
instead of, say, SFTP?
--
gfish
^ permalink raw reply
* Re: Question on rate limiting on nftables
From: Gordon Fisher @ 2026-06-25 17:20 UTC (permalink / raw)
To: Lars Noodén, netfilter
In-Reply-To: <6141c93d-ca25-4b3f-8a6b-b048f2ec595f@gmx.com>
On 6/8/26 8:57 AM, Lars Noodén wrote:
> On 6/8/26 18:01, Andre Rodier wrote:
>> Also, a connection attempts on a
>> different port should immediately raise attention, as it is involving
>> more than a basic SSH scan bot.
>
> Shifting ports might quiet the logs somewhat, but your SSH port will
> be found both quickly and easily by bots. That has been the case for
> a long time:
>
> https://bsdly.blogspot.com/2013/02/theres-no-protection-in-high-ports.html
>
>
> It is difficult to fit nftables into mitigations for those probes
> because modern scans usually come from a wide spread of addresses and
> networks. In the case of SSH, using SSH keys (or even SSH
> certificates) and turning off password authentication clears out a lot
> of the bots, but that has been mentioned already.
>
You can just block access (drop) to all and only allow to specific
address(es), then probes are taken out of the picture entirely.
--
gfish
^ permalink raw reply
* Re: Question on rate limiting on nftables
From: Gordon Fisher @ 2026-06-25 16:55 UTC (permalink / raw)
To: Kerin Millar, Andre Rodier, netfilter
In-Reply-To: <8d84a240-b9ae-41f4-b111-33007909b0a2@app.fastmail.com>
On 6/8/26 5:45 AM, Kerin Millar wrote:
> [...]
>
> If the problem can be characterised as "I endure too much log noise from sshd and I find it annoying" then perhaps configure sshd(8) to additionally bind to some other random port than 22 and expose only that port.
>
> [...]
Another way is to simply disallow (drop) all connections to resources
you don't want the random public to access, and only allow the
hosts/networks you actually desire to get in. This has long been my
policy on any server that I administer and thus never had a problem with
random probes.
--
gfish
^ permalink raw reply
* Automated L3 Leak Testing Framework for nftables (Network Sandbox Engine)
From: Atlas @ 2026-06-23 10:04 UTC (permalink / raw)
To: netfilter@vger.kernel.org
[-- Attachment #1.1.1: Type: text/plain, Size: 1406 bytes --]
Hi,
I am writing to share an open-source testing framework that heavily relies on nftables and Linux network namespaces, which might be of interest to those working on automated firewall validation and proxy architectures.
While building a transparent proxy (TransparentTorProxy), I noticed a lack of automated tools to empirically test L3/L4 cleartext leaks during proxy teardown or daemon crashes (e.g., handling asynchronous TCP SYN retransmissions when a ruleset is flushed).
To solve this, I developed the Network Sandbox Engine (NSE). It dynamically spawns isolated network namespaces (ip netns), applies nftables rulesets, injects background traffic, and uses PCAP to verify the absence of leaks during graceful teardowns.
To achieve a zero-leak teardown, the tool relies on a specific LIFO injection of reject with tcp reset rules applied just before flushing the tables, effectively clearing the kernel queues before the firewall goes down.
I thought this community might find the testing methodology-or the specific nftables state transition handling-useful for other proxying or containment projects.
The testing suite (and the resulting transparent proxy architecture) is available here: https://github.com/onyks-os/NetworkSandboxEngine
Feedback on the nftables teardown logic or suggestions for further kernel-level hardening are highly appreciated.
Best regards,
onyks
[-- Attachment #1.1.2.1: Type: text/html, Size: 3080 bytes --]
[-- Attachment #1.2: publickey - atlas-git@proton.me - 0x1F67851E.asc --]
[-- Type: application/pgp-keys, Size: 836 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 343 bytes --]
^ permalink raw reply
* Re: Using NFT for dynamic per-packet traffic load balancing
From: Kerin Millar @ 2026-06-17 21:05 UTC (permalink / raw)
To: Tomas Mudrunka, netfilter
In-Reply-To: <b1e1c08ec510f963bafff40065e8f8c2@spoje.net>
Hi,
On Tue, 14 Apr 2026, at 5:11 PM, Tomas Mudrunka wrote:
> Hello
> I was experimenting with using NFT to balance traffic between several
> links, this is what i came up with:
>
> table bridge balancer {
> chain egress_forward {
> type filter hook forward priority filter; policy accept;
> meta ibrname br0 drop;
> }
> }
>
> table netdev balancer {
> map dispatch_map {
> typeof numgen random mod 100 : oif
> flags interval
> elements = {
> 0-9 : "eth0",
> 10-29 : "eth1",
> 30-99 : "eth2",
> }
> }
>
> chain br_egress {
> type filter hook egress device br0 priority filter; policy drop;
> fwd to numgen random mod 100 map @dispatch_map
> }
> }
>
>
> You create bridge br0 with eth0-eth2 interfaces in it.
> There is a map that sets weights of how much traffic should be directed
> to individual links, so you can fully use multiple links even when the
> bandwidth is not equal.
> For wireless links you can even get signal quality feedback from radio
> hardware and live tune the map based on it. Tried up to 10 times a
> second without any issues using following command:
>
> echo 'flush map netdev balancer dispatch_map; add element netdev
> balancer dispatch_map { 0-32 : "eth0", 33-66 : "eth1", 67-99 : "eth2" }'
> | sudo nft -f -
>
> Being able to dynamicaly fine tune this map from userspace in realtime
> is killer-feature of this approach and cannot be achieved by regular
> linux interface bonding (link aggregation). While it is very important
> for me, i agree this is quite niche requirement.
>
> The nft ruleset prevents bridge from actualy forwarding between ports,
> so each frame is sent only via single randomly selected interface.
> Received packets are not forwarded anywhere except for local ip stack.
>
> I know this setup is still quite rough, but i wonder if there is
> something that can be improved. It seems to be really interresting
> topic.
It is interesting. What makes it rough is that it is an implementation of per-packet load balancing. It might work well enough for many short-lived TCP flows in aggregate, or traffic that is tolerant to reordering (various UDP-based protocols). Otherwise, it might under-perform.
Given that, I would suggest keeping an eye on your reordering/retransmit stats with ss -ti.
>
> Maybe i don't like using "fwd to" and should just drop frames on all
> interfaces except for one. because right now i cannot see egress frames
> on br0 using wireshark, only ingress.
Even so, the use of "fwd to" is probably for the best.
>
> Maybe i can ditch bridge completely and use dummy interface instead? I
> am not sure what is cleanest way. i want to be able to use wireshark to
> see all frames going through the load balancing on single interface,
> which is not really happening right now. but i can observe individual
> interfaces, which is not as useful, but allowed me to verify the
> ballancing works properly and follows weight ratio defined in the map.
A dummy interface wouldn't pair with "fwd to". If you wish to dispense with the bridging aspect, a netdev ingress hook might work.
You could make use of counters in order to track the distribution.
meta mark set numgen random mod 100
meta mark 0-9 counter fwd to "eth0"
meta mark 10-29 counter fwd to "eth1"
meta mark 30-99 counter fwd to "eth2"
--
Kerin Millar
^ permalink raw reply
* Re: "nft list hooks" not showing the custom nat chains, and unexpected priority for nf_nat_ipv4_local_fn
From: Kerin Millar @ 2026-06-17 20:15 UTC (permalink / raw)
To: Binarus, netfilter
In-Reply-To: <41f34484-1a51-4b94-81b5-99a22292b674@binarus.de>
On Mon, 15 Jun 2026, at 2:44 PM, Binarus wrote:
> At first, thank you very much for taking the time.
>
> On 13.06.2026 18:52, Kerin Millar wrote:
>> Hi,
>>
>> On Sat, 13 Jun 2026, at 5:16 PM, Binarus wrote:
>>> Dear all,
>>>
>>> I am still struggling with understanding the packet flow through the
>>> netfilter hooks and chains. Therefore, I have set up a very simple test
>>> scenario. Before listing the ruleset, a few remarks:
>>>
>>> The following relates to netfilter 1.1.3 with kernel 6.12.90 on Debian
>>> trixie. I had to modify the kernel to enable the hook listing, but
>>> that's the only change compared to a Debian trixie vanilla system.
>>>
>>> The test system has a ppp0 interface (default route / internet access)
>>> and a physical NIC interface (network 192.168.20.0/24, IP
>>> 192.168.20.249). The following ruleset is totally useless for any
>>> practical application, but I hope it's appropriate for investigations:
>>>
>>> root@charon /etc/network # nft list ruleset
>>> table ip t_IP {
>>> chain output-route {
>>> type route hook output priority mangle; policy drop;
>>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>>> accept
>>> }
>>>
>>> chain output-filter {
>>> type filter hook output priority filter; policy drop;
>>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>>> accept
>>> }
>>>
>>> chain output-nat {
>>> type nat hook output priority 100; policy drop;
>>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>>> accept
>>> }
>>>
>>> chain postrouting-filter {
>>> type filter hook postrouting priority filter; policy drop;
>>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>>> accept
>>> }
>>>
>>> chain postrouting-nat {
>>> type nat hook postrouting priority srcnat; policy drop;
>>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace
>>> set 1
>>> oifname "ppp0" ip protocol { tcp, udp } masquerade to
>>> :61000-64999
>>> oifname "ppp0" ip protocol icmp masquerade
>>> accept
>>> }
>>> }
>>>
>>> The goal is to investigate the flow of an outbound icmp packet that is
>>> locally generated. I believe that the above ruleset includes all pairs
>>> of hooks and chain types that exist for outbound local packets. I have
>>> included the "nftrace" line in every chain because I wanted to see all
>>> chains the packet goes through even in case I had totally misunderstood
>>> the order.
>>>
>>> But before the actual test, I looked at the output of "nft list hooks".
>>> This is the result:
>>>
>>> root@charon /etc/network # nft list hooks
>>> family ip {
>>> hook prerouting {
>>> -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
>>> -0000000200 ipv4_conntrack_in [nf_conntrack]
>>> -0000000100 nf_nat_ipv4_pre_routing [nf_nat]
>>> }
>>> hook input {
>>> +0000000100 nf_nat_ipv4_local_in [nf_nat]
>>> +2147483647 nf_confirm [nf_conntrack]
>>> }
>>> hook output {
>>> -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
>>> -0000000200 ipv4_conntrack_local [nf_conntrack]
>>> -0000000150 chain ip t_IP output-route [nf_tables]
>>> -0000000100 nf_nat_ipv4_local_fn [nf_nat]
>>> 0000000000 chain ip t_IP output-filter [nf_tables]
>>> }
>>> hook postrouting {
>>> 0000000000 chain ip t_IP postrouting-filter [nf_tables]
>>> +0000000100 nf_nat_ipv4_out [nf_nat]
>>> +2147483647 nf_confirm [nf_conntrack]
>>> }
>>> }
>>>
>>> Now this leaves me totally clueless. Focusing on the output and the
>>> postrouting hook only (because I'd like to learn about these two first):
>>>
>>> 1.
>>> My own custom output-route, output-filter and postrouting-filter are
>>> listed. But neither the output-nat nor the postrouting-nat chain are
>>> listed; at their place, the respective internal netfilter functions are
>>> listed.
>>>
>>> I then have changed the priorities for these two chains (setting them
>>> to the shown value from the ruleset ±1 each) in case the default
>>> priorities must not be used. But that did not change anything: The
>>> custom nat chains still were not listed in the output of "nft list
>>> hooks".
>>>
>>> Could somebody please explain where my misunderstanding is? In further
>>> tests, I have verified that these custom chains were indeed active, so
>>> why aren't they listed?
>>
>> It is enumerating the hook functions registered by the Netfilter core. The names of your nat chains are not shown because they are subordinate to the nf_nat hook functions. In your case, the relevant ones are "nf_nat_ipv4_local_fn" for output, and "nf_nat_ipv4_out" for postrouting.
>
> Thank you very much for the explanation. Then that's obviously also the
> reason why changing the priority didn't change anything.
>
> I suppose that netfilter still takes the chain priority into account
> when calling the subordinate chains. That is, the nat hook functions
> are always at the same priority, but in turn call the registered
> subordinate chains in the order of their priorities. Is this correct?
Provided the word, same, as taken as meaning "at a fixed, per-hook priority" then yes, this is entirely correct.
--
Kerin Millar
^ permalink raw reply
* Re: Is the article "Secure use of iptables and connection tracking helpers" (by Pablo et al.) still relevant?
From: Binarus @ 2026-06-17 10:40 UTC (permalink / raw)
To: netfilter
In-Reply-To: <bb1f251d-fb7e-443f-8e04-8d3ee00bf7ab@binarus.de>
On 17.06.2026 12:29, Binarus wrote:
> [...]
>
> For example, the nf_conntrack module in modern kernels (e.g., 6.12.90 on my Debian trixie system) obviously does not have the "nf_conntrack_helper" parameter the article mentions. Hence, setting it to 0 does not effect anything. Setting the "port" parameter to 0 seems to do the trick, though.
Setting the "port" parameter to 0 does not do the trick, too. Sorry for the wrong statement. I had interpreted a test result in a wrong way.
>
> Background: If finally have upgraded my firewall from iptables to nftables (and have learned a lot in doing so). Now I'd like to improve security further by applying the recommendations from that article to the nf_conntrack_sip helper module (I have an asterisk instance running on my local network that communicates with the internet / the telephony providers via NAT, so I have to use the conntrack sip helper to make telephony work).
>
> In other words, I' like to know whether we should still prevent the automatic loading of the nf_conntrack_sip module, and how we can achieve that.
>
> Thank you very in advance, and best regards,
>
> Binarus
>
>
^ permalink raw reply
* Re: Is the article "Secure use of iptables and connection tracking helpers" (by Pablo et al.) still relevant?
From: Florian Westphal @ 2026-06-17 10:39 UTC (permalink / raw)
To: Binarus; +Cc: netfilter
In-Reply-To: <bb1f251d-fb7e-443f-8e04-8d3ee00bf7ab@binarus.de>
Binarus <lists@binarus.de> wrote:
> I've come across the following article (which has been co-authored by Pablo):
>
> https://github.com/regit/secure-conntrack-helpers/blob/master/secure-conntrack-helpers.rst
>
> All statements of this article make sense in my eyes. I have understood that it relates to iptables, not nftables, but it seems that the underlying reasoning and explanations are valid for nftables as well.
>
> However, since the article is 14 years old (at least), I'd like to know whether it is still up to date and whether we should follow its recommendations.
>
> For example, the nf_conntrack module in modern kernels (e.g., 6.12.90 on my Debian trixie system) obviously does not have the "nf_conntrack_helper" parameter the article mentions. Hence, setting it to 0 does not effect anything. Setting the "port" parameter to 0 seems to do the trick, though.
You don't have to set it to 0, the feature was removed, i.e. the
'Disable helper by default' section no longer applies. All helpers are
off unless there are rules that explicitly activate them ('-j CT
--helper ftp' etc).
> In other words, I' like to know whether we should still prevent the automatic loading of the nf_conntrack_sip module, and how we can achieve that.
No. There is no automatic helper assignement in the kernel anymore and
therefore no helper ever automatically snoops traffic even if the module
is loaded.
The port module arguments are dead-weight and will be removed soon.
They don't do anything these days.
^ permalink raw reply
* Is the article "Secure use of iptables and connection tracking helpers" (by Pablo et al.) still relevant?
From: Binarus @ 2026-06-17 10:29 UTC (permalink / raw)
To: netfilter
Dear all,
I've come across the following article (which has been co-authored by Pablo):
https://github.com/regit/secure-conntrack-helpers/blob/master/secure-conntrack-helpers.rst
All statements of this article make sense in my eyes. I have understood that it relates to iptables, not nftables, but it seems that the underlying reasoning and explanations are valid for nftables as well.
However, since the article is 14 years old (at least), I'd like to know whether it is still up to date and whether we should follow its recommendations.
For example, the nf_conntrack module in modern kernels (e.g., 6.12.90 on my Debian trixie system) obviously does not have the "nf_conntrack_helper" parameter the article mentions. Hence, setting it to 0 does not effect anything. Setting the "port" parameter to 0 seems to do the trick, though.
Background: If finally have upgraded my firewall from iptables to nftables (and have learned a lot in doing so). Now I'd like to improve security further by applying the recommendations from that article to the nf_conntrack_sip helper module (I have an asterisk instance running on my local network that communicates with the internet / the telephony providers via NAT, so I have to use the conntrack sip helper to make telephony work).
In other words, I' like to know whether we should still prevent the automatic loading of the nf_conntrack_sip module, and how we can achieve that.
Thank you very in advance, and best regards,
Binarus
^ permalink raw reply
* Re: No meta ibrindex/obrindex, only meta ibrname/obrname
From: Avinash Duduskar @ 2026-06-17 2:43 UTC (permalink / raw)
To: Corwyn Briggs, netfilter
In-Reply-To: <8400bf65-82b4-495a-a5ef-4ad7a1fafb08@gmail.com>
Doesn't look like anyone's asked for this in the 12+ years since these
keys landed (2014), nice find.
Every meta key that identifies a specific interface comes in a
name/index pair: iif/iifname, oif/oifname, sdif/sdifname.
The bridge-master keys are the only ones that are name-only.
Closing that API asymmetry could be a legit reason to add it, if
someone's keen to write it.
On Tue, 2026-06-16 at 20:34 -0500, Corwyn Briggs wrote:
>
>
> Is this an intentional difference or rather just something which was
> never implemented?
> I wish I could offer a fix, but I haven't the faintest idea how a
> person would go about implementing one, so I appreciate any advice on
> this issue.
> Thank you all!
^ permalink raw reply
* Re: No meta ibrindex/obrindex, only meta ibrname/obrname
From: Kerin Millar @ 2026-06-17 2:03 UTC (permalink / raw)
To: Corwyn Briggs, netfilter
In-Reply-To: <efd80966-8380-4d70-a313-b6d9585ef0b2@app.fastmail.com>
On Wed, 17 Jun 2026, at 2:52 AM, Kerin Millar wrote:
> Hi,
>
> On Wed, 17 Jun 2026, at 2:34 AM, Corwyn Briggs wrote:
>> Hello!
>> I am somewhat new to Linux and am configuring a custom firewall for the
>> first time. I have come across a discrepancy wherein the index of an
>> interface on a bridge (i.e. a veth bonded to the bridge) cannot be used
>> to match in an inet chain, but the name can be used via meta
>> ibrname/obrname. I would like to use the index since it is a bit faster
>> and my interfaces should not be dynamic, but meta ibrindex/obrindex does
>> not exist in any manpages I have read. I checked over the archive as
>> best I could and did not see any discussion about the feature either. Is
>> this an intentional difference or rather just something which was never
>> implemented?
>
> Support for meta ibriport/obriport was introduced by nft v0.3, then
> changed to meta ibrname/obrname by nft v0.8.4. But these are only
> usable within bridge family tables. For the inet family, one would use
> iifname/oifname instead.
>
> One cannot compare against the bridge index; nftables simply doesn't
> support this at the current time.
I may have overstated this. Where iifname/oifname works in an inet table, so should iif and oif. But there is definitely no such analogue for meta ibrname/obrname (which pertains to the bridge family).
--
Kerin Millar
^ permalink raw reply
* Re: No meta ibrindex/obrindex, only meta ibrname/obrname
From: Kerin Millar @ 2026-06-17 1:52 UTC (permalink / raw)
To: Corwyn Briggs, netfilter
In-Reply-To: <8400bf65-82b4-495a-a5ef-4ad7a1fafb08@gmail.com>
Hi,
On Wed, 17 Jun 2026, at 2:34 AM, Corwyn Briggs wrote:
> Hello!
> I am somewhat new to Linux and am configuring a custom firewall for the
> first time. I have come across a discrepancy wherein the index of an
> interface on a bridge (i.e. a veth bonded to the bridge) cannot be used
> to match in an inet chain, but the name can be used via meta
> ibrname/obrname. I would like to use the index since it is a bit faster
> and my interfaces should not be dynamic, but meta ibrindex/obrindex does
> not exist in any manpages I have read. I checked over the archive as
> best I could and did not see any discussion about the feature either. Is
> this an intentional difference or rather just something which was never
> implemented?
Support for meta ibriport/obriport was introduced by nft v0.3, then changed to meta ibrname/obrname by nft v0.8.4. But these are only usable within bridge family tables. For the inet family, one would use iifname/oifname instead.
One cannot compare against the bridge index; nftables simply doesn't support this at the current time. However, the difference between comparing an index and a name is that the former compares 4 bytes, while the latter compares (up to) 16 bytes. The chances are that you would be wholly unable to measure any difference in practice.
--
Kerin Millar
^ permalink raw reply
* No meta ibrindex/obrindex, only meta ibrname/obrname
From: Corwyn Briggs @ 2026-06-17 1:34 UTC (permalink / raw)
To: netfilter
Hello!
I am somewhat new to Linux and am configuring a custom firewall for the
first time. I have come across a discrepancy wherein the index of an
interface on a bridge (i.e. a veth bonded to the bridge) cannot be used
to match in an inet chain, but the name can be used via meta
ibrname/obrname. I would like to use the index since it is a bit faster
and my interfaces should not be dynamic, but meta ibrindex/obrindex does
not exist in any manpages I have read. I checked over the archive as
best I could and did not see any discussion about the feature either. Is
this an intentional difference or rather just something which was never
implemented?
I wish I could offer a fix, but I haven't the faintest idea how a person
would go about implementing one, so I appreciate any advice on this issue.
Thank you all!
^ permalink raw reply
* Re: "nft list hooks" not showing the custom nat chains, and unexpected priority for nf_nat_ipv4_local_fn
From: Binarus @ 2026-06-15 13:44 UTC (permalink / raw)
To: netfilter
In-Reply-To: <f81bb631-3b65-4332-a076-4feae632ab13@app.fastmail.com>
At first, thank you very much for taking the time.
On 13.06.2026 18:52, Kerin Millar wrote:
> Hi,
>
> On Sat, 13 Jun 2026, at 5:16 PM, Binarus wrote:
>> Dear all,
>>
>> I am still struggling with understanding the packet flow through the
>> netfilter hooks and chains. Therefore, I have set up a very simple test
>> scenario. Before listing the ruleset, a few remarks:
>>
>> The following relates to netfilter 1.1.3 with kernel 6.12.90 on Debian
>> trixie. I had to modify the kernel to enable the hook listing, but
>> that's the only change compared to a Debian trixie vanilla system.
>>
>> The test system has a ppp0 interface (default route / internet access)
>> and a physical NIC interface (network 192.168.20.0/24, IP
>> 192.168.20.249). The following ruleset is totally useless for any
>> practical application, but I hope it's appropriate for investigations:
>>
>> root@charon /etc/network # nft list ruleset
>> table ip t_IP {
>> chain output-route {
>> type route hook output priority mangle; policy drop;
>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>> accept
>> }
>>
>> chain output-filter {
>> type filter hook output priority filter; policy drop;
>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>> accept
>> }
>>
>> chain output-nat {
>> type nat hook output priority 100; policy drop;
>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>> accept
>> }
>>
>> chain postrouting-filter {
>> type filter hook postrouting priority filter; policy drop;
>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
>> accept
>> }
>>
>> chain postrouting-nat {
>> type nat hook postrouting priority srcnat; policy drop;
>> ip saddr 192.168.20.249 ip protocol icmp meta nftrace
>> set 1
>> oifname "ppp0" ip protocol { tcp, udp } masquerade to
>> :61000-64999
>> oifname "ppp0" ip protocol icmp masquerade
>> accept
>> }
>> }
>>
>> The goal is to investigate the flow of an outbound icmp packet that is
>> locally generated. I believe that the above ruleset includes all pairs
>> of hooks and chain types that exist for outbound local packets. I have
>> included the "nftrace" line in every chain because I wanted to see all
>> chains the packet goes through even in case I had totally misunderstood
>> the order.
>>
>> But before the actual test, I looked at the output of "nft list hooks".
>> This is the result:
>>
>> root@charon /etc/network # nft list hooks
>> family ip {
>> hook prerouting {
>> -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
>> -0000000200 ipv4_conntrack_in [nf_conntrack]
>> -0000000100 nf_nat_ipv4_pre_routing [nf_nat]
>> }
>> hook input {
>> +0000000100 nf_nat_ipv4_local_in [nf_nat]
>> +2147483647 nf_confirm [nf_conntrack]
>> }
>> hook output {
>> -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
>> -0000000200 ipv4_conntrack_local [nf_conntrack]
>> -0000000150 chain ip t_IP output-route [nf_tables]
>> -0000000100 nf_nat_ipv4_local_fn [nf_nat]
>> 0000000000 chain ip t_IP output-filter [nf_tables]
>> }
>> hook postrouting {
>> 0000000000 chain ip t_IP postrouting-filter [nf_tables]
>> +0000000100 nf_nat_ipv4_out [nf_nat]
>> +2147483647 nf_confirm [nf_conntrack]
>> }
>> }
>>
>> Now this leaves me totally clueless. Focusing on the output and the
>> postrouting hook only (because I'd like to learn about these two first):
>>
>> 1.
>> My own custom output-route, output-filter and postrouting-filter are
>> listed. But neither the output-nat nor the postrouting-nat chain are
>> listed; at their place, the respective internal netfilter functions are
>> listed.
>>
>> I then have changed the priorities for these two chains (setting them
>> to the shown value from the ruleset ±1 each) in case the default
>> priorities must not be used. But that did not change anything: The
>> custom nat chains still were not listed in the output of "nft list
>> hooks".
>>
>> Could somebody please explain where my misunderstanding is? In further
>> tests, I have verified that these custom chains were indeed active, so
>> why aren't they listed?
>
> It is enumerating the hook functions registered by the Netfilter core. The names of your nat chains are not shown because they are subordinate to the nf_nat hook functions. In your case, the relevant ones are "nf_nat_ipv4_local_fn" for output, and "nf_nat_ipv4_out" for postrouting.
Thank you very much for the explanation. Then that's obviously also the reason why changing the priority didn't change anything.
I suppose that netfilter still takes the chain priority into account when calling the subordinate chains. That is, the nat hook functions are always at the same priority, but in turn call the registered subordinate chains in the order of their priorities. Is this correct?
>
>>
>> 2.
>> According to my research, the nat chain in the output hook is for
>> source nat, not for destination nat, and therefore its priority should
>> be 100, as given in the ruleset. The famous "netfilter hooks" graphics
>> in the nftables wiki says the same, at least in my understanding.
>>
>> But "nft list hooks" says that the priority of nf_nat_ipv4_local_fn is
>> -100, as if the nat chain at this hook would be for destination nat
>> instead of source nat.
>>
>> Could somebody please explain which type of nat the nat chain at the
>> output hook is meant for (snat or dnat), and if it is snat, why the
>> priority is -100 instead of 100 as expected?
>
> It is destination NAT (dstnat). To rewrite the source addresses of locally generated packets, you would do it in your "postrouting-nat" chain instead.
Again, thank you very much. This explains a lot of other results that were unexpected to me. There is not much material out there that relates to output-nat, and some of that material is obviously wrong. (Most of) the sources I have come across stated that output-nat is for srcnat. Your correction of that mistake is highly appreciated.
I already had a slight suspicion of that kind, because I had noticed that nft complained about an error when I replaced the literal priority value 100 by the symbolic constant srcnat. However, when I used the symbolic constant dstnat instead, there was no error message.
Best regards, and thanks for your answers to many other posts on this list as well,
Binarus
>
> --
> Kerin Millar
>
^ permalink raw reply
* Re: "nft list hooks" not showing the custom nat chains, and unexpected priority for nf_nat_ipv4_local_fn
From: Kerin Millar @ 2026-06-13 16:52 UTC (permalink / raw)
To: Binarus, netfilter
In-Reply-To: <2b4db6cd-bc9b-47ff-99ee-7c15da7a343f@binarus.de>
Hi,
On Sat, 13 Jun 2026, at 5:16 PM, Binarus wrote:
> Dear all,
>
> I am still struggling with understanding the packet flow through the
> netfilter hooks and chains. Therefore, I have set up a very simple test
> scenario. Before listing the ruleset, a few remarks:
>
> The following relates to netfilter 1.1.3 with kernel 6.12.90 on Debian
> trixie. I had to modify the kernel to enable the hook listing, but
> that's the only change compared to a Debian trixie vanilla system.
>
> The test system has a ppp0 interface (default route / internet access)
> and a physical NIC interface (network 192.168.20.0/24, IP
> 192.168.20.249). The following ruleset is totally useless for any
> practical application, but I hope it's appropriate for investigations:
>
> root@charon /etc/network # nft list ruleset
> table ip t_IP {
> chain output-route {
> type route hook output priority mangle; policy drop;
> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
> accept
> }
>
> chain output-filter {
> type filter hook output priority filter; policy drop;
> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
> accept
> }
>
> chain output-nat {
> type nat hook output priority 100; policy drop;
> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
> accept
> }
>
> chain postrouting-filter {
> type filter hook postrouting priority filter; policy drop;
> ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
> accept
> }
>
> chain postrouting-nat {
> type nat hook postrouting priority srcnat; policy drop;
> ip saddr 192.168.20.249 ip protocol icmp meta nftrace
> set 1
> oifname "ppp0" ip protocol { tcp, udp } masquerade to
> :61000-64999
> oifname "ppp0" ip protocol icmp masquerade
> accept
> }
> }
>
> The goal is to investigate the flow of an outbound icmp packet that is
> locally generated. I believe that the above ruleset includes all pairs
> of hooks and chain types that exist for outbound local packets. I have
> included the "nftrace" line in every chain because I wanted to see all
> chains the packet goes through even in case I had totally misunderstood
> the order.
>
> But before the actual test, I looked at the output of "nft list hooks".
> This is the result:
>
> root@charon /etc/network # nft list hooks
> family ip {
> hook prerouting {
> -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
> -0000000200 ipv4_conntrack_in [nf_conntrack]
> -0000000100 nf_nat_ipv4_pre_routing [nf_nat]
> }
> hook input {
> +0000000100 nf_nat_ipv4_local_in [nf_nat]
> +2147483647 nf_confirm [nf_conntrack]
> }
> hook output {
> -0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
> -0000000200 ipv4_conntrack_local [nf_conntrack]
> -0000000150 chain ip t_IP output-route [nf_tables]
> -0000000100 nf_nat_ipv4_local_fn [nf_nat]
> 0000000000 chain ip t_IP output-filter [nf_tables]
> }
> hook postrouting {
> 0000000000 chain ip t_IP postrouting-filter [nf_tables]
> +0000000100 nf_nat_ipv4_out [nf_nat]
> +2147483647 nf_confirm [nf_conntrack]
> }
> }
>
> Now this leaves me totally clueless. Focusing on the output and the
> postrouting hook only (because I'd like to learn about these two first):
>
> 1.
> My own custom output-route, output-filter and postrouting-filter are
> listed. But neither the output-nat nor the postrouting-nat chain are
> listed; at their place, the respective internal netfilter functions are
> listed.
>
> I then have changed the priorities for these two chains (setting them
> to the shown value from the ruleset ±1 each) in case the default
> priorities must not be used. But that did not change anything: The
> custom nat chains still were not listed in the output of "nft list
> hooks".
>
> Could somebody please explain where my misunderstanding is? In further
> tests, I have verified that these custom chains were indeed active, so
> why aren't they listed?
It is enumerating the hook functions registered by the Netfilter core. The names of your nat chains are not shown because they are subordinate to the nf_nat hook functions. In your case, the relevant ones are "nf_nat_ipv4_local_fn" for output, and "nf_nat_ipv4_out" for postrouting.
>
> 2.
> According to my research, the nat chain in the output hook is for
> source nat, not for destination nat, and therefore its priority should
> be 100, as given in the ruleset. The famous "netfilter hooks" graphics
> in the nftables wiki says the same, at least in my understanding.
>
> But "nft list hooks" says that the priority of nf_nat_ipv4_local_fn is
> -100, as if the nat chain at this hook would be for destination nat
> instead of source nat.
>
> Could somebody please explain which type of nat the nat chain at the
> output hook is meant for (snat or dnat), and if it is snat, why the
> priority is -100 instead of 100 as expected?
It is destination NAT (dstnat). To rewrite the source addresses of locally generated packets, you would do it in your "postrouting-nat" chain instead.
--
Kerin Millar
^ permalink raw reply
* "nft list hooks" not showing the custom nat chains, and unexpected priority for nf_nat_ipv4_local_fn
From: Binarus @ 2026-06-13 16:16 UTC (permalink / raw)
To: netfilter
Dear all,
I am still struggling with understanding the packet flow through the netfilter hooks and chains. Therefore, I have set up a very simple test scenario. Before listing the ruleset, a few remarks:
The following relates to netfilter 1.1.3 with kernel 6.12.90 on Debian trixie. I had to modify the kernel to enable the hook listing, but that's the only change compared to a Debian trixie vanilla system.
The test system has a ppp0 interface (default route / internet access) and a physical NIC interface (network 192.168.20.0/24, IP 192.168.20.249). The following ruleset is totally useless for any practical application, but I hope it's appropriate for investigations:
root@charon /etc/network # nft list ruleset
table ip t_IP {
chain output-route {
type route hook output priority mangle; policy drop;
ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
accept
}
chain output-filter {
type filter hook output priority filter; policy drop;
ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
accept
}
chain output-nat {
type nat hook output priority 100; policy drop;
ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
accept
}
chain postrouting-filter {
type filter hook postrouting priority filter; policy drop;
ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
accept
}
chain postrouting-nat {
type nat hook postrouting priority srcnat; policy drop;
ip saddr 192.168.20.249 ip protocol icmp meta nftrace set 1
oifname "ppp0" ip protocol { tcp, udp } masquerade to :61000-64999
oifname "ppp0" ip protocol icmp masquerade
accept
}
}
The goal is to investigate the flow of an outbound icmp packet that is locally generated. I believe that the above ruleset includes all pairs of hooks and chain types that exist for outbound local packets. I have included the "nftrace" line in every chain because I wanted to see all chains the packet goes through even in case I had totally misunderstood the order.
But before the actual test, I looked at the output of "nft list hooks". This is the result:
root@charon /etc/network # nft list hooks
family ip {
hook prerouting {
-0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
-0000000200 ipv4_conntrack_in [nf_conntrack]
-0000000100 nf_nat_ipv4_pre_routing [nf_nat]
}
hook input {
+0000000100 nf_nat_ipv4_local_in [nf_nat]
+2147483647 nf_confirm [nf_conntrack]
}
hook output {
-0000000400 ipv4_conntrack_defrag [nf_defrag_ipv4]
-0000000200 ipv4_conntrack_local [nf_conntrack]
-0000000150 chain ip t_IP output-route [nf_tables]
-0000000100 nf_nat_ipv4_local_fn [nf_nat]
0000000000 chain ip t_IP output-filter [nf_tables]
}
hook postrouting {
0000000000 chain ip t_IP postrouting-filter [nf_tables]
+0000000100 nf_nat_ipv4_out [nf_nat]
+2147483647 nf_confirm [nf_conntrack]
}
}
Now this leaves me totally clueless. Focusing on the output and the postrouting hook only (because I'd like to learn about these two first):
1.
My own custom output-route, output-filter and postrouting-filter are listed. But neither the output-nat nor the postrouting-nat chain are listed; at their place, the respective internal netfilter functions are listed.
I then have changed the priorities for these two chains (setting them to the shown value from the ruleset ±1 each) in case the default priorities must not be used. But that did not change anything: The custom nat chains still were not listed in the output of "nft list hooks".
Could somebody please explain where my misunderstanding is? In further tests, I have verified that these custom chains were indeed active, so why aren't they listed?
2.
According to my research, the nat chain in the output hook is for source nat, not for destination nat, and therefore its priority should be 100, as given in the ruleset. The famous "netfilter hooks" graphics in the nftables wiki says the same, at least in my understanding.
But "nft list hooks" says that the priority of nf_nat_ipv4_local_fn is -100, as if the nat chain at this hook would be for destination nat instead of source nat.
Could somebody please explain which type of nat the nat chain at the output hook is meant for (snat or dnat), and if it is snat, why the priority is -100 instead of 100 as expected?
Thank you very much in advance, and have a nice weekend,
Binarus
^ permalink raw reply
* Re: Logging SNAT'ed connections
From: Gordon Fisher @ 2026-06-12 17:20 UTC (permalink / raw)
To: netfilter
In-Reply-To: <3c59323d-449d-4f1c-abf3-2df0ada64cbb@app.fastmail.com>
On 6/8/26 1:47 PM, Kerin Millar wrote:
> On Mon, 8 Jun 2026, at 9:11 PM, Jan Kasprzak wrote:
>> Hi, Kerin,
>>
>> Kerin Millar wrote:
>>> Unfortunately, it appears to be a bug affecting ICMP. Possibly here:
>>>
>>> https://git.netfilter.org/libnetfilter_conntrack/tree/src/conntrack/objopt.c?id=7e5397b9167bdd7597be809b8f088ff333e1ad31#n189
>>>
>>> For now, I would suggest filtering with something else.
>>>
>>> conntrack -E -o id,timestamp |
>>> perl -ne 'print if /\bsrc=(\S+).*\bdst=(\S+)/ && $1 ne $2'
>> Oh, I did not expect it to be a bug.
>>
>> Anyway, you probably mean src= in both cases. Using backreferences,
>> I did it this way:
>>
>> perl -nE 'print if /\bsrc=(\S+)\s.*\bsrc=(?!\1\s)/'
> The idea I had in mind was to compare orig.src against reply.dst. Where orig.src != reply.dst, NAT applies. Your approach compares orig.src to reply.src. Those will differ for most flows, whether they were subjected to NAT or not.
>
> I would tend not to use backreferences in that way because it becomes quite easy to make a mistake.
>
> $ printf 'x=123.45 y=123.45\n' | perl -nE 'say "matched: $1" if /x=(\S+).*\by=(?!\1\s)/'
> matched: 123.4
Exactly, great care needs to be taken with back references; also given
'x=123.4 y=123.45', the \1 will match the '123.4' portion of 'y=123.45',
making it seems like they're equal when they're not, so getting it done
properly going that route will be far more complex.
Instead, here ...
$ for s in 'x=123.45 y=123.45' 'x=123.4 y=123.45' 'x=123.45 y=123.4' ; do
printf "%s\n" "$s" | perl -nE 'say "x $1 does not match y $2" if m{
\b x=(\S+) .* \b y=(\S+)
}x && $1 ne $2;'
done
x 123.4 does not match y 123.45
x 123.45 does not match y 123.4
...is a cleaner way if one wants a more readable version.
--
gfish
^ permalink raw reply
* Re: Logging SNAT'ed connections
From: Pablo Neira Ayuso @ 2026-06-12 9:53 UTC (permalink / raw)
To: Kerin Millar; +Cc: Jan Kasprzak, netfilter
In-Reply-To: <ce6502c0-8576-4672-9227-118f515f334c@app.fastmail.com>
On Fri, Jun 12, 2026 at 06:49:00AM +0100, Kerin Millar wrote:
> On Wed, 10 Jun 2026, at 4:31 PM, Pablo Neira Ayuso wrote:
> > Thanks for reviewing, v2 is here:
> >
> > https://patchwork.ozlabs.org/project/netfilter-devel/patch/20260610151735.192168-1-pablo@netfilter.org/
>
> I have now applied this to a production host and tested it in a number of ways, including the use of the --src-nat option, both with and without an option-argument. In all cases, conntrack(8) behaved perfectly.
Thanks for testing, I'll apply this then.
^ permalink raw reply
* Re: Logging SNAT'ed connections
From: Kerin Millar @ 2026-06-12 5:49 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: Jan Kasprzak, netfilter
In-Reply-To: <aimDYp2y_oxSIIzi@chamomile>
On Wed, 10 Jun 2026, at 4:31 PM, Pablo Neira Ayuso wrote:
> Thanks for reviewing, v2 is here:
>
> https://patchwork.ozlabs.org/project/netfilter-devel/patch/20260610151735.192168-1-pablo@netfilter.org/
I have now applied this to a production host and tested it in a number of ways, including the use of the --src-nat option, both with and without an option-argument. In all cases, conntrack(8) behaved perfectly.
--
Kerin Millar
^ permalink raw reply
* Re: "nft list hooks" not working (empty output)
From: Binarus @ 2026-06-11 5:32 UTC (permalink / raw)
To: netfilter
In-Reply-To: <ainwA_Lkyr85C6dB@chamomile>
On 11.06.2026 01:15, Pablo Neira Ayuso wrote:
> On Thu, Jun 11, 2026 at 12:24:28AM +0200, Binarus wrote:
>> Dear all,
>>
>> according to the man page for nft, "nft list hooks" should list all functions registered at each hook, along with their priorities, and including the internal nftables functions. I am understanding this in the sense that "nft list hooks" should output something at least when there actually is a ruleset.
>>
>> But on my test system, that output is always empty. Please consider the following excerpt from a terminal session:
>>
>> root@charon /etc/network # nft list ruleset
>> table ip t_IP {
>> chain input-filter {
>> type filter hook input priority filter; policy accept;
>> ip protocol icmp drop
>> }
>> }
>> root@charon /etc/network # nft list hooks
>> root@charon /etc/network #
>>
>> Of course, that ruleset does not make any sense, but it serves its purpose for testing. "nft list hooks" should output something in that situation, shouldn't it?
>>
>> This happens on Debian trixie, kernel 6.12.90, nftables 1.1.3.
>>
>> I also have tried "nft list hooks inet" with the same result.
>>
>> Furthermore, I have created another ruleset with an ingress filter and have tried "nft list hooks netdev", which also gave no output.
>>
>> Any advice or explanation? Where is my misunderstanding or mistake?
>
> It seems debian kernels do not compile support for this command?
>
> grep CONFIG_NETFILTER_NETLINK_HOOK /boot/config-6.12.74+deb13+1-amd64
> # CONFIG_NETFILTER_NETLINK_HOOK is not set
I see. Obviously, they now finally have lost it. Honestly, I would never have come to that idea.
Thank you very much for the help!
^ permalink raw reply
* Re: prefix len confusion
From: Randy Bush @ 2026-06-11 1:12 UTC (permalink / raw)
To: Kerin Millar; +Cc: Sunny73Cr, netfilter
In-Reply-To: <8057b5ab-29fa-42b9-865f-2fbceaa0e94a@app.fastmail.com>
>> table ip filter {
>> chain forward {
>> type filter hook forward priority filter;
>> iifname "lo" accept # please filter this too, you'll bounce your bushies (brows)
so far we have seen no ill effects from commenting this out
[ joke about man who jumped from the tenth floor ]
randy
^ permalink raw reply
* Re: "nft list hooks" not working (empty output)
From: Kerin Millar @ 2026-06-11 1:10 UTC (permalink / raw)
To: Pablo Neira Ayuso, Binarus; +Cc: netfilter
In-Reply-To: <ainwA_Lkyr85C6dB@chamomile>
On Thu, 11 Jun 2026, at 12:15 AM, Pablo Neira Ayuso wrote:
> On Thu, Jun 11, 2026 at 12:24:28AM +0200, Binarus wrote:
>> Dear all,
>>
>> according to the man page for nft, "nft list hooks" should list all functions registered at each hook, along with their priorities, and including the internal nftables functions. I am understanding this in the sense that "nft list hooks" should output something at least when there actually is a ruleset.
>>
>> But on my test system, that output is always empty. Please consider the following excerpt from a terminal session:
>>
>> root@charon /etc/network # nft list ruleset
>> table ip t_IP {
>> chain input-filter {
>> type filter hook input priority filter; policy accept;
>> ip protocol icmp drop
>> }
>> }
>> root@charon /etc/network # nft list hooks
>> root@charon /etc/network #
>>
>> Of course, that ruleset does not make any sense, but it serves its purpose for testing. "nft list hooks" should output something in that situation, shouldn't it?
>>
>> This happens on Debian trixie, kernel 6.12.90, nftables 1.1.3.
>>
>> I also have tried "nft list hooks inet" with the same result.
>>
>> Furthermore, I have created another ruleset with an ingress filter and have tried "nft list hooks netdev", which also gave no output.
>>
>> Any advice or explanation? Where is my misunderstanding or mistake?
>
> It seems debian kernels do not compile support for this command?
>
> grep CONFIG_NETFILTER_NETLINK_HOOK /boot/config-6.12.74+deb13+1-amd64
> # CONFIG_NETFILTER_NETLINK_HOOK is not set
For that matter, someone asked about this at Libera about three weeks ago. It's a puzzling omission.
--
Kerin Millar
^ permalink raw reply
* Re: prefix len confusion
From: Kerin Millar @ 2026-06-11 1:05 UTC (permalink / raw)
To: Sunny73Cr; +Cc: Randy Bush, netfilter
In-Reply-To: <eo6IAy4tTDDl6AcRVB1pmRAiEEylNBe2EGlUxAsDHSglsWmdaXg-oFwfDcPGyTmYP17SvtgGpOOye8uy2u9lZLgPaxuTnUWPY7jiJEgpdM8=@protonmail.com>
On Thu, 11 Jun 2026, at 12:51 AM, Sunny73Cr wrote:
> Try this:
>
> table ip filter {
> chain forward {
> type filter hook forward priority filter;
> iifname "lo" accept # please filter this too, you'll bounce
> your bushies (brows)
Packets sourced from or destined to 127.0.0.0/8 are not forwarded: they're dropped as martians unless net.ipv4.conf.<iface>.route_localnet is set to 1, where <iface> is the incoming interface. Hence, in most cases, the commented rule there is superfluous.
--
Kerin Millar
^ permalink raw reply
* Re: prefix len confusion
From: Randy Bush @ 2026-06-11 0:25 UTC (permalink / raw)
To: Sunny73Cr; +Cc: Kerin Millar, netfilter
In-Reply-To: <scvzZFFc0YAE7k_JC5BL5RPJaJmJhsP5UHJ8TSZzLVAQohQAdyhlLFw3AV9_oNq6GpFaWI8x4LKNiS4NPqOUZe0gLUhx1G0oRLStKsyGyEw=@protonmail.com>
> chain wan-in {
> ip saddr $BOGONS4 drop
> ip saddr $EXTv4 daddr $VULN4 accept
> ip saddr $JUMP4 daddr $VULN4 accept
> ip daddr $VULN4 drop
> ip protocol icmp accept
> ...
>
> Did you mean to do this instead?
not really. if the source is in the trust boundary, it can access
anything. e.g. there was also a
tcp dport 8006 ip daddr $PROX4 drop
in there which is yet more dests allowed to trusted sources
randy
^ permalink raw reply
* Re: prefix len confusion
From: Sunny73Cr @ 2026-06-11 0:06 UTC (permalink / raw)
To: Randy Bush; +Cc: Kerin Millar, netfilter
In-Reply-To: <m233yu0x0g.wl-randy@psg.com>
chain wan-in {
ip saddr $BOGONS4 drop
ip saddr $EXTv4 daddr $VULN4 accept
ip saddr $JUMP4 daddr $VULN4 accept
ip daddr $VULN4 drop
ip protocol icmp accept
...
Did you mean to do this instead?
You should discriminate about which machines can send forwardable icmp, though.
CONFIDENTIALITY NOTICE: as prior.
SIGNATURE NOTICE: as prior.
Regards,
sunny
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox