Hi all,
After upgrading a production machine from 6.x to 7.x,
I noticed that pf would create states from rules without
"keep state". IMSMR, it hadn't happened before, and
the pf.conf(5) manpage still says one has to specify
"keep state" explicitly for pf to create states.
Just examined this iss
On Sep 7, 2008, at 7:31 PM, Olli Hauer wrote:
Looks like pfctl or pf itself added stateful semantics to my pf.conf
that weren't there initially. Is this effect intended and, if so,
how
can I tell pf not to create states from certain rules?
Thanks! And excuse me if I'm just missing somethin
On Sep 8, 2008, at 1:09 AM, Chris Smith wrote:
On Sunday 07 September 2008 04:53:20 pm Yar Tikhiy wrote:
And in OpenBSD-current the manpage still reads: "...keep state
must be specified explicitly to apply [stateful tracking] options
to a rule."
Not in the -current running here. T
Hi folks,
I know I'm unoriginal in my trying to use pf + pfsync + carp :-)
But am I unique in observing the following trouble?
I have two symmetric routers running rather fresh RELENG_5 (just a
few days old) and CARP from the patch by Glebius. As soon as I
enable pfsync between them over a dedic
Hi there,
Some time ago I complained here that in my environment state entries
would expire too fast when pfsync was active. I've just upgraded
my production routers to FreeBSD 5.4-STABLE + PF 3.7 and I no longer
can observe the problem, pfsync working like a charm now. Many
thanks to Max Laier
couple of weeks, when I get some free time, because it really
bites me in my network setup.
- Forwarded message from Yar Tikhiy <[EMAIL PROTECTED]> -
Let's consider the following reference configuration:
net2net1
|+-+|
Excuse me for a late reply, I missed your mail.
On Fri, Jun 03, 2005 at 02:07:41PM +0100, Greg Hennessy wrote:
>
> > Is it by design? I'd like to make the asymmetric
> > configuration functional if possible at all, but I've been
> > unable to find any background information on the issue, such
On Mon, Jun 13, 2005 at 10:10:54AM -0400, Josh Kayse wrote:
> One last comment,
>
> I managed to fix it so that carp runs on the plip interface by adding:
> ifp->if_flags = LINK_STATE_UP;
>
> Here is the diff:
>
> diff -Nur /usr.orig/src/sys/dev/ppbus/if_plip.c
> /usr/src/sys/dev/ppbus/if_plip.
On Mon, Jun 13, 2005 at 12:00:36PM -0400, Josh Kayse wrote:
> Definitely a typo on my part. It should be
> ifp->if_link_state = LINK_STATE_UP
>
> The reason we are using CARP on a PLIP interface is to allow us to
> have redundant connections between 2 transparent bridging firewalls.
> Instead of
On Wed, Jun 15, 2005 at 02:32:19PM -0400, Josh Kayse wrote:
> On 6/15/05, Gleb Smirnoff <[EMAIL PROTECTED]> wrote:
>
> > AFAIU, you use PLIP line as some flag that triggers suppression. If
> > slave "sees" master via PLIP, it keeps itself in slave mode. May be
> > I don't understand you right.
>
On Sun, Jul 03, 2005 at 09:50:48PM +0400, alex-bsd wrote:
> I am adherent BSD of systems, in the last time have passed with IPFW to use
> PF, other useful and interesting opportunities have liked in it Firewall,
> more convenient syntax and many.
> I wish to offer developers PF, to add new (IMHO
Hi there,
I think we have a couple of issues regarding PF set-up during the
system boot process.
First, in the presence of vlan's or other dynamic interfaces it can
be hard to ensure that pfsync0 will appear after its syncdev on the
final list of interfaces built inside /etc/network.subr from sev
All,
While making an rc.d script for pfsync as I had promised here, I
noticed that pf.ko didn't include support for pfsync. Closer study
revealed that it would be better to split pf.ko in separate modules
for pf itself, pflog, and pfsync. The reason is as follows.
As MODULES_WITH_WORLD are abou
On Thu, Sep 22, 2005 at 02:12:52PM +0200, Max Laier wrote:
> On Thursday 22 September 2005 13:20, Yar Tikhiy wrote:
>
> > First, in the presence of vlan's or other dynamic interfaces it can
> > be hard to ensure that pfsync0 will appear after its syncdev on the
> > f
On Sun, Oct 02, 2005 at 08:51:57PM +0200, Max Laier wrote:
>
> There is one big issue with PFSYNC as a module. pfsync needs to register a
> kernel level multicast protocol. This is not (yet) possible at runtime, but
> needs to happen statically. So in order to use pfsync you need a pfsync
>
On Mon, Oct 31, 2005 at 11:01:15AM +0100, Antoine Brodin wrote:
> I wrote:
> > Hi,
> >
> > I use pf as a module on -current and it worked well until recently.
> > Today I noticed that pflogd didn't log anything. It worked correctly
> > a month ago.
> >
> > This seems to be related to revision 1.
[moving this thread to freebsd-pf]
On Mon, Mar 06, 2006 at 04:10:19PM +, Max Laier wrote:
> mlaier 2006-03-06 16:10:19 UTC
>
> FreeBSD src repository
>
> Modified files:(Branch: RELENG_6)
> etc/rc.d pflog
> sys/contrib/pf/net if_pflog.c if_pflog.h pf_i
On Wed, Mar 08, 2006 at 04:21:44PM +0100, Max Laier wrote:
> On Wednesday 08 March 2006 08:12, Yar Tikhiy wrote:
> > [moving this thread to freebsd-pf]
> >
> > On Mon, Mar 06, 2006 at 04:10:19PM +, Max Laier wrote:
> > > mlaier 2006-03-06 16:10:19 UTC
> &
On Tue, Feb 13, 2007 at 10:26:31PM +0100, Max Laier wrote:
> Does anyone have time to get something like this going for FreeBSD as
> well?
IMHO it's a restricted solution to a more general problem. Other
firewall types can suffer from it, too. While there is no single
cure for using DNS names i
19 matches
Mail list logo
