Hello Ian,
On Mon, May 02, 2022 at 06:09:45PM +0100, Ian Chilton wrote:
> Hi,
>
> > sloppy
> > Uses a sloppy TCP connection tracker that does not check sequence
> > numbers at all, which makes insertion and ICMP teardown attacks
> > way
> > easier. This is intended to be used in situations where one does
> > not see all packets of a connection, e.g. in asymmetric routing
> > situations. It cannot be used with modulate state or synproxy
> > state.
>
> The "which makes insertion and ICMP teardown attacks way easier." part
> sounds scary!
those ICMP teardown attacks affect TCP sessions only. The 'keep state
(sloppy)'
relaxes stateful check for icmp, icmp6 only. For TCP pf still performs
strict stateful check.
>
> Just tested... if I replace:
> pass quick proto { icmp, icmp6 }
> with:
> pass quick proto { icmp, icmp6 } no state
> ... it also works.
I would say sloppy vs. no state has little difference for icmp.
>
> I guess this is a more normal behaviour of allowing any ICMP through,
> regardless of sate. As opposed to silently dropping incoming traffic
> for which there is no matching state.
>
> Is that preferable over 'sloppy'?
I don't know. my guess is it is matter of personal taste/preferences.
>
>
> > I believe claudio@ has advice for you based on some of his real life
> > experience.
>
> So he said he forwards traffic with a no state rule...
>
> So I guess I need to allow outgoing with `no state`, but then
> explicitly allow incoming with established,related (some how?) like
> you would with iptables on Linux?
>
I would either stick to 'pass quick ... keep state (sloppy)'
or just use 'pass quick ... no state'.
Also see my other email where I'm asking about pfsync in your
set up. I believe our those troubles come from fact that
the ICMP request got sent by gw2 as local outbound, hence
pf creates just single state for ICMP outbound request.
while gw1 must have pair of states to forward ICMP reply back
to gw2. pfsync delivers just single state from gw2. The state
allows inbound ICMP reply only. And there is no state which
allows outbound ICMP reply at gw1. And there are two possible
workarounds:
either use 'keep state (sloppy)' at gw1
or go with 'no state'
both option will allow outbound icmp replies to leave gw1.
regards
sashan
