PF how do i understand tcp flags

this rule
Code:
pass out all flags SAR/SAFR modulate state
Check if SAR bits all value are 1? are SARFR checked or not checked after the slash? Or does the F bit have to be 0? The front SAR positions should be “&” operator? , is there “or” operation method
 
Code:
     flags ⟨a⟩ /⟨b⟩ | /⟨b⟩ | any
           This rule only applies to TCP packets that have the flags ⟨a⟩ set
           out of set ⟨b⟩.  Flags not specified in ⟨b⟩ are ignored.  For
           stateful connections, the default is flags S/SA.  To indicate that
           flags should not be checked at all, specify flags any.  The flags
           are: (F)IN, (S)YN, (R)ST, (P)USH, (A)CK, (U)RG, (E)CE, and C(W)R.

           flags S/S   Flag SYN is set.  The other flags are ignored.

           flags S/SA  This is the default setting for stateful connections.
                       Out of SYN and ACK, exactly SYN may be set.  SYN,
                       SYN+PSH and SYN+RST match, but SYN+ACK, ACK and ACK+RST
                       do not.  This is more restrictive than the previous
                       example.

           flags /SFRA
                       If the first set is not specified, it defaults to none.
                       All of SYN, FIN, RST and ACK must be unset.

           Because flags S/SA is applied by default (unless no state is
           specified), only the initial SYN packet of a TCP handshake will
           create a state for a TCP connection.  It is possible to be less
           restrictive, and allow state creation from intermediate (non-SYN)
           packets, by specifying flags any.  This will cause pf(4) to
           synchronize to existing connections, for instance if one flushes
           the state table.  However, states created from such intermediate
           packets may be missing connection details such as the TCP window
           scaling factor.  States which modify the packet flow, such as those
           affected by nat, binat or rdr rules, modulate or synproxy state
           options, or scrubbed with reassemble tcp will also not be
           recoverable from intermediate packets.  Such connections will stall
           and time out.
From pf.conf(5).

So, to answer the question, it checks bits S, A, F and R. And of those bits S, A and R have to be set (which is a silly combination).
 
Hmmm, interesting. I see that my outward Nmap tcp sA packets were blocked by PF. Is there any way to allow them pass out? Thankyou.
 
Maybe post your rules? Or do we need to guess how things are configured now?
 
OK. Here is my pf.conf

Code:
# global
block drop all
pass log quick proto tcp from {$home $ipsec $ca} to $gateway port 22 keep state (max-src-conn-rate 3/60)
pass log quick proto tcp from $gateway port 22 to {$home $ipsec $ca}
pass proto tcp from any to {10.0.14.0/24 $ipsec}
pass proto tcp from {10.0.14.0/24 $ipsec} to any
#pass proto tcp from any to {10.0.14.0/24 $ipsec} flags ACK
#pass proto tcp from {10.0.14.0/24 $ipsec} to any flags ACK
pass proto udp from any to {10.0.14.0/24 $ipsec}
pass proto udp from {10.0.14.0/24 $ipsec} to any
pass proto icmp from any to {10.0.14.0/24 $ipsec}
pass proto icmp from {10.0.14.0/24 $ipsec} to any
block drop log proto tcp from any to $gateway port 22
 
Well, none of your rules actually allow the traffic. So it gets dropped.

Note that keep state is implied with a pass rule. So only the first SYN packet is allowed, the rest is allowed due to the state. A single ACK packet won't have a state and doesn't create one either.
 
Thank you for the explicit illustration. Yep, but I wish to use ACK packets derived from Nmap to "explore" the Internet. Is there any way to lets these ACK packets to pass the PF?
 
The best way would be to disable PF. As this will always give you an unfettered path to the outside world. You could probably configure PF to allow this specific traffic but then you will have problems with other flags and/or types of scan. The whole idea behind nmap is to send out all sorts of weird and wonderful packets. Anyone of those could get mangled by a firewall running on the host and skew the results.
 
The best way would be to disable PF. As this will always give you an unfettered path to the outside world. You could probably configure PF to allow this specific traffic but then you will have problems with other flags and/or types of scan. The whole idea behind nmap is to send out all sorts of weird and wonderful packets. Anyone of those could get mangled by a firewall running on the host and skew the results.

Now I see. Thanks, pal.
 
Back
Top