* Consolidating rules
@ 2021-12-29 14:09 yves baumes
2022-01-03 14:56 ` Florian Westphal
0 siblings, 1 reply; 2+ messages in thread
From: yves baumes @ 2021-12-29 14:09 UTC (permalink / raw)
To: netfilter
Hello everyone,
I'm using :
```
# iptables -V
iptables v1.8.7 (nf_tables)
```
The machine I'm working on already has a lot of iptables rules
attached to it. The default policies are "DROP":
```
# iptables -t filter -L
Chain INPUT (policy DROP)
target prot opt source destination
[...]
```
Here is my problem: when I create a table to let DHCP and DNS requests
pass through, my packets are still getting dropped.
```
# nft list ruleset
table inet mytable {
chain inbound {
ip protocol . th dport vmap { tcp . 22 : accept, tcp . 53 : accept,
udp . 53 : accept, udp . 67 : accept }
}
chain ssh_inbound {
tcp dport 22 accept
}
chain input {
type filter hook input priority filter - 1; policy drop;
ct state vmap { invalid : drop, established : accept, related : accept }
iifname vmap { "eth2" : jump inbound, "eth2.103" : jump inbound,
"eth2.3163" : jump inbound }
iifname vmap { "eth0" : jump ssh_inbound }
iifname "lo" accept
iifname "tun0" tcp dport 22 accept
}
[...]
```
So I read about that issue in the wiki:
https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority
. Which states that the default filter/INPUT chain will be run either
before or after my own chain (depending on the priority I set) and
will drop the packets silently, since its default policy is DROP and
no rules match the packets in this filter/INPUT chain.
Indeed if I change the default policy of filter/INPUT to ACCEPT, my
DHCP/DNS packets are getting accepted.
So this is the first solution to my issue. But it is not really
satisfactory because my default policy lets *all* packets go through.
Indeed we changed the default policy, so it looks only like a
workaround.
Second solution would be to let the default filter/INPUT policy to
DROP and centralize my configuration into the filter/INPUT chain,
(which means removing the table 'mytable'). I think it's better than
the first solution, but still not satisfactory since I am creating a
big blob containing all my rules (that is the filter/INPUT chain). I
like the idea to distribute my rules in separate chains/tables.
So how would you tackle this issue, that is: letting the packets go
through while still having a default policy to DROP? Is there a
simpler way that I did not find?
Regards
Yves
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Consolidating rules
2021-12-29 14:09 Consolidating rules yves baumes
@ 2022-01-03 14:56 ` Florian Westphal
0 siblings, 0 replies; 2+ messages in thread
From: Florian Westphal @ 2022-01-03 14:56 UTC (permalink / raw)
To: yves baumes; +Cc: netfilter
yves baumes <ybaumes@gmail.com> wrote:
> Here is my problem: when I create a table to let DHCP and DNS requests
> pass through, my packets are still getting dropped.
> ```
> # nft list ruleset
> table inet mytable {
> chain inbound {
> ip protocol . th dport vmap { tcp . 22 : accept, tcp . 53 : accept,
> udp . 53 : accept, udp . 67 : accept }
> }
>
> chain ssh_inbound {
> tcp dport 22 accept
> }
>
> chain input {
> type filter hook input priority filter - 1; policy drop;
> ct state vmap { invalid : drop, established : accept, related : accept }
> iifname vmap { "eth2" : jump inbound, "eth2.103" : jump inbound,
> "eth2.3163" : jump inbound }
> iifname vmap { "eth0" : jump ssh_inbound }
> iifname "lo" accept
> iifname "tun0" tcp dport 22 accept
> }
> [...]
> ```
>
> So I read about that issue in the wiki:
> https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority
> . Which states that the default filter/INPUT chain will be run either
> before or after my own chain (depending on the priority I set) and
> will drop the packets silently, since its default policy is DROP and
> no rules match the packets in this filter/INPUT chain.
> Indeed if I change the default policy of filter/INPUT to ACCEPT, my
> DHCP/DNS packets are getting accepted.
They are accepted regardless, the policy is not relevant for them.
[..]
> Second solution would be to let the default filter/INPUT policy to
> DROP and centralize my configuration into the filter/INPUT chain,
Thats what you are doing?
In the ruleset you provided there is only on base chain (input),
so 'chain inbound' is called in the context of the input base chain.
> So how would you tackle this issue, that is: letting the packets go
> through while still having a default policy to DROP? Is there a
> simpler way that I did not find?
If the 'accept policy' solves your problem, your ruleset is tossing
packets that it should not be dropping.
For example, your ruleset breaks ipv6 since it discards icmpv6
neighbour solicitiation packets.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-01-03 14:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-29 14:09 Consolidating rules yves baumes
2022-01-03 14:56 ` Florian Westphal
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.