ѽ҉ᶬḳ℠ <vtol@xxxxxxx> wrote:
> I was trying to concatenate { udp, tcp } but that does not seem to work,
> or this something only available from 0.8.3 onward?
>
> add rule bridge filter input { tcp, udp } dport 53 accept
> add rule bridge filter input meta protocol { tcp, udp } dport 53 accept
> add rule bridge filter input meta nfproto { tcp, udp } dport 53 accept
> add rule bridge filter input inet_proto { tcp, udp } dport 53 accept
> add rule bridge filter input type inet_proto { tcp, udp } dport 53 accept
This doesn't work in any version of nftables.
The dport keyword is only valid after "udp", "tcp", or any other protcol
that has a notion of a "destination port".
The only way to express this at the moment is the use of the raw payload
notion, which works from 0.8.3 onwards.
This is a limitation of nftables parser..
Suggestions or patches to fix this welcome.
> Bridge filtering is then on OSI model level 4 compared to Netdev on OSI
> level 2 or is Bridge filtering relying entirely on the TCP/IP model
> layers? That does not seem really/very clear in the NFT wiki/man pages.
Neither. Bridge filtering only means that such tables get packets
that pass any linux bridge.
netdev ingress only means such tables get packets when they arrive on
that particular device.
Asking for "tcp port 53" tells nft to make sure the test is only done
for tcp packets, how this is done inernally depends on the hooking
point, but it will work in any family.
You can use netdev ingress to attach a base chain to a particular bridge
port, for instance.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
