ѽ҉ᶬḳ℠ <vtol@xxxxxxx> wrote:
moving to nf-devel.
> Having this very simple setup icmp is not getting through at the target
> machine. Flushing the nft ruleset the icmp traffic is getting through.
Yes, this set
> table inet filter {
> chain input {
> type filter hook input priority 0; policy drop;
> icmp type { 0, 3, 11, 12, 14, 16, 18 } accept
> }
>
is
icmp type { echo-reply, destination-unreachable,
time-exceeded, parameter-problem,
timestamp-reply, info-reply, address-mask-reply
} accept
so rule won't trigger (missing echo-request).
> A trace does not seem reveal /show the |accept| verdict but neither any
> |drop|.
> trace id 3409361b inet filter input packet: iif "ens3" ether saddr
> 00:23:dc:01:18:96 ether daddr 00:16:3e:22:4e:9d ip saddr 149.x.x.x ip
> daddr 179.x.x.x ip dscp cs0 ip ecn not-ect ip ttl 55 ip id 57831 ip
> length 84 icmp type echo-request icmp code 0 icmp id 47 icmp sequence 1
> trace id 3409361b inet filter input rule nftrace set 1 (verdict continue)
> trace id 3409361b inet filter input verdict continue
Thats a bug. The last line should read
trace id 3409361b inet filter input policy drop
kernel part of the bug:
....
nft_trace_packet(&info, basechain, NULL, NFT_TRACETYPE_POLICY);
if (static_branch_unlikely(&nft_counters_enabled))
nft_update_chain_stats(basechain, pkt);
return nft_base_chain(basechain)->policy;
}
so when we emit 'trace' message, verdict register still contains
'continue', because we return ->policy but don't update internal
register beforehand.
We can fix this either in kernel (update verdict register), or in
userspace (by figuring out the current chain policy ourselves).
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
