"keep state" does not work

[Kajetan Staszkiewicz]

Dnia wtorek, 1 lipca 2014 o 14:40:47 Spenst, Aleksej napisał(a):
> Hi All,
> 
> I have a problem that when I use the rules with "keep state" my use case
> does not work. When I use two rules "pass out" and "pass in" (instead of
> one "pass out" rule with keep state) then everything works.
> 
> These rules work fine:
> 
> pass out quick on wfd0 proto tcp from (self) to 172.16.222/24 port 7236
> pass in quick on wfd0 proto tcp from 172.16.222/24 port 7236 to (self)

When displaying states, add -v. You will see which rule really created them.

You should need only one of those rules. Judging from where port number is 
specified, I guess that it is (self) creating connections to hosts in 
172.16.222/24. In that case you should only need "out" rule. Each new TCP 
connection should then create a state and next packets in those connections 
should be passed by matching a state instead of being pushed down firewall rule 
list.

One more thing, such passing rules in fact are created with requirement for TCP 
flags to be SYN or SYN+ACK. This means that when you first start pf, existing 
TCP sessions will not match those rules at all and will not create new states.
 
> Now, instead of these two rules I write the following rule with "keep
> state" and it does not work:
> 
> pass out quick on wfd0 proto tcp from (self) to 172.16.222/24 port 7236
> keep state
 
> The strange thing is that in this case I don't see any blocked packets in
> logs!

You have presented just one (or two) lines of firewall. If there is nothing 
else, there is no blocking. If there are more rules, presenting your whole 
firewall will greatly help to investigate the issue.

> I also see that the state "self -> 172.16.222/24 port 7236" always
> exists.

Just a moment ago you've said that "it does not work". Now you say that states 
are created. Those statements are quite opposing eachother.
 
> Does anyone have experience that "keep state" does not work as expected for
> some reason?

Broken tcp packets, asymetric routing (usually fixed with sloppy tracking), 
change of routing when pf is already running (fixed with sloppy + flags==any 
but this costs you security), finally some bugs in pf. But probably not in this 
case.

-- 
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
|  Kajetan Staszkiewicz  | jabber,email: vegeta()tuxpowered net  |
|        Vegeta          | www: http://vegeta.tuxpowered.net     |
`------------------------^---------------------------------------'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20140706/16951045/attachment.sig>