The first few rules of my INPUT and FORWARD chains are identical.
In nftables, as in xtables, I can create a common chain and jump to it explicitly:
table ip filter {
chain prologue {
continue comment "deal with ct state, loopback, ICMP"
}
chain input {
type filter hook input priority filter; policy drop;
jump prologue
tcp dport ssh accept
jump epilogue
}
chain forward {
type filter hook input priority filter; policy drop;
jump prologue
ip daddr www.example.com tcp dport { http, https } accept
iifname lan ip daddr ds.example.com tcp dport { ldap, ldaps } accept
jump epilogue
}
chain epilogue {
reject
}
}
However, its more "intuitive" to me to hook the prologue chain directly,
with an earlier priority. This avoids the need for explicit jumps in
the main input/forward chains.
table ip filter {
chain prologue {
type filter hook input | forward priority filter - 1; policy continue;
continue comment "allow CT established, ICMP, lo, &c here"
}
chain input {
type filter hook input priority filter; policy drop;
tcp dport ssh accept
}
chain forward {
type filter hook input priority filter; policy drop;
ip daddr www.example.com tcp dport { http, https } accept
iifname lan ip daddr ds.example.com tcp dport { ldap, ldaps } accept
}
chain epilogue {
type filter hook input | forward priority filter + 1; policy continue;
reject
}
}
This isn't allowed as at nftables 0.9.1 / linux 4.19, because (I think):
* "hook X" can't take BOTH input AND forward; and
* "policy X" has to be accept or drop (not continue or return).
Is this an interesting thing to want?
Or should I just HTFU and live with those "extra" jumps? :-)
