On Fri, Sep 21, 2007 at 11:55:36PM +0800, Ilya A. Kovalenko wrote: > >> block in inet from 192.168.0.1 to 192.168.114.31 > >> pass in inet from 192.168.114.31 to 192.168.0.1 flags S/SA keep state > >> (does not work - neither pings nor TCP) > > Here, you only pass the *inbound* packets; you also must > > pass the outbound packets on the opposite interface. > > So, single state entry affects traffic on single interface only ?
It is little a bit different than that. A state also has a 'direction' associated with it. So, a state matches either incoming or outgoing traffic. As long as the direction matches, the interface does not really matter. Sometimes, rarely, you have to enforce the interface (usually only useful for IPSec (enc0) traffic) this is what the ifbound states (check pf.conf man page) are for. To summarize, you need two states to forward a traffic. The ruleset is traversed twice. First at the inbound interface, second at the outbound interface. Once the states are created, no more rule lookups are done for this particular connection. Some people use: pass out all keep state at the start and filter the inbound traffic (this would allow connections originating from the firewall itself though) For most cases, you can get away with not specifying a direction and an interface. An exception is NAT and Redirection where you have to use rules for both the original and transformed traffic. Keep in mind that address translation is done before matching rules. NAT changes the source and always done at the outgoing interface. RDR changes destination, at the incoming interface. > >> Preferred version, because it does not affect queueing > > I think you'll find the complication comes from queueing. > > hell, yes ... states vs queueing ... but it's another story Actually, once you are comfortable with states, queueing is very flexible and powerful. Can
