Re: PF gateway problems.. return traffic blocked (but not if in N AT m ode!)

[Adrian Buxton <Adrian.Buxton@team.ozemail.com.au>]

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.