[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netfilter
Subject:    Re: Validating this is the right conntrack ruleset
From:       Kerin Millar <kfm () plushkava ! net>
Date:       2022-06-07 16:15:13
Message-ID: 20220607171513.b90501912e97d0e3e39a2cfe () plushkava ! net
[Download RAW message or body]

On Tue, 7 Jun 2022 12:08:48 -0400
Gio <gioflux@gmail.com> wrote:

> Thank you; I appreciate the help with clarity. The most important
> takeaway for me was that there are implicit return packet/replies
> rules that don't need to be in the opposite hook (output for input,
> etc).
> 
> The example was excellent to illustrate this too.
> 
> For the sake of completeness; would the 'implicit' return packet rule
> be 'ct state established,related ct direction reply' ? Example:
> 
> table inet legacy {
> chain root_in {
> type filter hook input priority filter; policy drop;
> ct state established,related accept
> iifname "lo" accept
> meta l4proto ipv6-icmp accept
> tcp dport 80 fib daddr type local ct state new accept
> }
> chain root_out {
> type filter hook output priority filter; policy drop;
> ct state established,related ct direction reply accept
> iifname "lo" accept
> }
> }

Yes, I believe it would be. Incidentally, the second rule in the root_out chain \
should be using oifname, rather than iifname.

-- 
Kerin Millar


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic