Re: State table across reboots

2004-03-03 Thread Daniel Hartmeier
On Tue, Mar 02, 2004 at 09:27:48AM -0800, Getchell, Adam wrote:

 I'm under the impression pf keeps the state table across reboots, but
 Googling for it just gives Darren Reed's response:
 http://monkey.org/openbsd/archive/misc/0201/msg01135.html
 
 Does it?

No, the state table is not stored in a file and reloaded on reboot,
though that wouldn't be hard to do (the ioctl API is there already), I
guess it's just not generally useful enough.

If you filter TCP statefully and create state only on SYN packets (using
flags S/SA keep state), a reboot will stall or reset your existing
connections.

If you allow non-SYN packets to create state (without flags S/SA), the
next packet seen after reboot for an existing connection will create a
new state entry, and the connections continues to work (assuming the
next packet, which can be coming from either direction, on more than one
interface possibly, actually matches a pass keep state rule).

Some features like modulate state, syn-proxy or window scaling support
only work when pf creates state on the initial SYN and sees the TCP
handshake. So creating state from non-SYN will not work properly when
these features are used/needed.

Daniel


Re: State table across reboots

2004-03-03 Thread Ryan McBride
On Tue, Mar 02, 2004 at 09:27:48AM -0800, Getchell, Adam wrote:
 I'm under the impression pf keeps the state table across reboots, but

It does not.


State table across reboots

2004-03-02 Thread Getchell, Adam
Hi all,

I'm under the impression pf keeps the state table across reboots, but
Googling for it just gives Darren Reed's response:
http://monkey.org/openbsd/archive/misc/0201/msg01135.html

Does it?

Thanks,

***
* Adam Getchell
* Application Developer
* College of Agricultural  Environmental Sciences Deans' Office
* [EMAIL PROTECTED]  (530)752-9284
***
Invincibility is in oneself, vulnerability in the opponent. -- Sun Tzu