packet filter does not keep state

[Josh Paetzel]

On Wednesday 02 April 2008 09:03:06 am Erik Norgaard wrote:
> Hi,
>
> I have a problem connecting from one local subnet to another
> crossing an FBSD box with pf. Should be trivial, I have the
> following ruleset:
>
> <snip>
> # Local services accessible from wlan
> block in log on $wlan_if inet from $wlan_net to <local_net>
> pass  in log quick on $wlan_if inet proto tcp  from $wlan_net to \
>       <local_net> port $local_tcp flags S/SA keep state
> pass  in log quick on $wlan_if inet proto udp  from $wlan_net to \
>       <local_net> port $local_udp keep state
> pass  in log quick on $wlan_if inet proto icmp from $wlan_net to \
>       <local_net> icmp-type $local_icmp keep state
> block in log quick on $wlan_if inet from $wlan_net to <local_net>
>
> block out log on $srv_if
> pass out quick on $srv_if inet from $srv_ip to $srv_net keep state
> pass out quick on $srv_if inet from $srv_ip to !<local_net> \
>       keep state
> block out log quick on $srv_if
> </snip>
>
> <local_net> is a table of the directly attached local networks, I
> try to connect from my wireless to a wired lan.
>
> But, tcpdump on pflog0 shows this:
>
> 000000 rule 54/0(match): pass in on ath0: 172.17.1.254.49347 >
>      192.168.0.254.80: [|tcp]
> 000081 rule 94/0(match): block out on vr0: 172.17.1.254.49347 >
>      192.168.0.254.80:  tcp 44 [bad hdr length 0 - too short, < 20]
>
> Evidently, the packet is matched by the correct pass in rule, yet
> no state is created and it is subsequently blocked by the block
> out rule.
>
> I can add a pass out rule to get through, but that shouldn't be
> the correct solution, why does pf not keep state?
>
> Thanks, Erik

Is there an entry for the connection in the state table?  And does PF complain 
about the header length when what it really means to say is there's no state?  
It seems to me that a packet with no header might have trouble with the state 
table even if there's an entry for it.

I've had trouble wih PF acting in non-intuitive ways before, especially 
concerning nat, binat, and rdr rules, which it's hard to tell if you're 
dealing with due to the <snip>.

-- 
Thanks,

Josh Paetzel

PGP: 8A48 EF36 5E9F 4EDA 5A8C 11B4 26F9 01F1 27AF AECB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20080402/7eea33e9/attachment.pgp