Daniel, thanks for the quick response!

> > pass in quick on $int_if proto tcp from $int_nets to any
> flags S keep
> > state
>
> As per pf.conf(5), 'flags S' means 'flags S/FSRPAU', meaning only
> packets that have SYN set and all other bits unset will
> match. Some stacks set PUSH or URG on SYNs (check with
> tcpdump), you really want to use 'flags S/SA' or 'flags S/S'
> instead of 'flags S'.

Granted. But all the internal clients I am using, when initiating a tcp
session only set the SYN flag, so that should be inconequential.
 
> > More specifically, I have noticed that traffic flows in the
> internal
> > interface, out the external interface, and the return
> traffic from the
> > destination host is blocked attempting to enter the external
> > interface. I'm guessing this is because state info is kept on a
> > specific interface only, so by filtering inbound on the internal
> > interface the state information is non-existent on the external
> > interface and the return traffic is consequently dropped.
>
> Yes, but your rules already create state on both interfaces.
> The only obvious reason why your 'keep state' doesn't work is
> the 'flags S'.
>

They create states on both interfaces? Where?? The only rules relating to
this are

pass in quick on $int_if proto tcp from $int_nets to any flags S keep state
pass in quick on $int_if proto { icmp, udp } from $int_nets to any keep
state

As for flags S being the reason, the same problem happens when you are soley
dealing with icmp traffic, i.e

pass in quick on $int_if proto icmp from $int_nets to any keep state

With that rule a ping doesn't even work. The response is blocked at the
firewall.

> > Why then does this work correctly when running in NAT mode?? Does
> > anyone know if Ipfilter exhibited similar behaviour?
>
> NATed packets implicitely create state. Without NAT, your
> filter rules must explicitely create state using 'keep
> state'. In other words, if a NATed packet gets passed by a
> filter rules that doesn't have 'keep state', pf will still
> create state for it (because it needs a state table entry to
> store the translation).
>
> Daniel

So, this means I have to keep state on the external interface else the
return traffic is dropped?

Cheers,
Adrian.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]