Re: [nftables v0.9.2 | kernel 4.19.93] ICMPv6 ingress dropped despite accept rule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/02/2020 11:20, ѽ҉ᶬḳ℠ wrote:
On 03/02/2020 11:15, kfm@xxxxxxxxxxxxx wrote:
On 03/02/2020 11:12, Kerin Millar wrote:
On 03/02/2020 10:56, ѽ҉ᶬḳ℠ wrote:
Appreciate if someone could be obliged and have a look at the below ruleset and let me know where I am going wrong since ICMPv6 is being (policy) dropped:

DROP_WAN_IN IN=pppoe-wan OUT= MAC= SRC=fe80:0000:0000:0000:e2ac:f1ff:fe65:51ba DST=ff02:0000:0000:0000:0000:0000:0000:0001 LEN=72 TC=224 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=134 CODE=0

despite an accept statement

--- ruleset

table arp filter { # handle 141
         chain input { # handle 1
                 type filter hook input priority filter; policy accept;
                 iif "eth2" drop # handle 3
         }

         chain output { # handle 2
                 type filter hook output priority filter; policy accept;
                 oif "eth2" drop # handle 4
         }
}
table inet filter { # handle 142
         chain input { # handle 1
                 type filter hook input priority filter; policy drop;
                 ct state established,related accept # handle 4
                 ct state invalid drop # handle 5
                 iif "lo" accept # handle 6
                 iif "br-lan" accept # handle 7
                 iif "lan0" accept # handle 8
                 iif "lan1" accept # handle 9
                 iif "lan2" accept # handle 10
                 iif "lan3" accept # handle 11
                 iif "lan4" accept # handle 12
                 log prefix "DROP_WAN_IN " # handle 13
         }
}
table ip6 filter { # handle 145
         chain input { # handle 1

This particular chain is not hooked.


Re-posting the above as I accidentally replied off-list.

But it is through

table inet filter { # handle 142
          chain input { # handle 1
                  type filter hook input priority filter; policy drop;

This is not the chain in question. For a chain to be utilised, it must either be hooked or be referenced - whether directly or indirectly - by a rule within a chain that is hooked. Your "ip6 filter input" chain currently does not fulfil either of these requirements.


or is it not? inet applies to both families IPv4 and IPv6, least that is my understanding. Or do the chains have to be defined again for ip and ip6?

Yes, the inet table covers both families. As such, you have the option of relocating your icmpv6-filtering rules from the ip6 to the inet table. Doing so would not obviate the aformentioned requirements, though.

--
Kerin Millar



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux