On Thu, Mar 20, 2003 at 09:01:22PM +0100, Srebrenko Sehic wrote:
On Thu, Mar 20, 2003 at 12:32:50PM -0700, [EMAIL PROTECTED] wrote:
Okay, I think I'm starting to understand what you want. (because I
believe we tossed the idea around at the last hackathon)
Basically, you want a
On 20/03/2003, Srebrenko Sehic [EMAIL PROTECTED] wrote To [EMAIL PROTECTED]:
Or even better, dis the keep state on {$ext_if $int_if}; keep
state should be enough, since pf(4) should take care of that. Now
this feature would be _very_ nice.
Any chance this could be implemented, say post 3.3?
On Thu, Mar 20, 2003 at 06:27:04PM -0800, Kyle R. Hofmann wrote:
So far everyone who has responded to you has been polite, despite your
inability to comprehend what they're telling you. Now, in the proud
tradition of OpenBSD lusers everywhere, I will flame you:
I don't recall _you_ being a
On Thu, Mar 20, 2003 at 04:13:04PM -0700, [EMAIL PROTECTED] wrote:
I assume that 'pass out all keep state' makes pf(4), at least, do a
state lookup in the table? AFAIK, that's, in worst case scenario, 16
searches down the binary tree? That ought to eat a few cycles.
I really doubt there
On Fri, Mar 21, 2003 at 12:52:14PM +0100, Henning Brauer wrote:
On Thu, Mar 20, 2003 at 11:16:10PM +0100, Srebrenko Sehic wrote:
This is cosmetics. However, whouldn't we get some performance increase
if pf(4) didn't bother looking at packets (in certain situations) going
'out' at all?
On Fri, Mar 21, 2003 at 12:50:43PM +0100, Henning Brauer wrote:
I'm close to give up on you wrt to that. SOmehow it seems you don't _want_
to see why the filtering outbond on an interface is so important. I gave a
very good example why that is absolutely needed.
Bla, bla, since traffic can
On Fri, Mar 21, 2003 at 06:47:44PM +0100, Srebrenko Sehic wrote:
On Fri, Mar 21, 2003 at 12:52:14PM +0100, Henning Brauer wrote:
On Thu, Mar 20, 2003 at 11:16:10PM +0100, Srebrenko Sehic wrote:
This is cosmetics. However, whouldn't we get some performance increase
if pf(4) didn't bother
On Fri, Mar 21, 2003 at 06:44:37PM +0100, Srebrenko Sehic wrote:
On Fri, Mar 21, 2003 at 12:50:43PM +0100, Henning Brauer wrote:
I'm close to give up on you wrt to that. SOmehow it seems you don't _want_
to see why the filtering outbond on an interface is so important. I gave a
very good
On Fri, Mar 21, 2003 at 06:44:37PM +0100, Srebrenko Sehic wrote:
On Fri, Mar 21, 2003 at 12:50:43PM +0100, Henning Brauer wrote:
I'm close to give up on you wrt to that. SOmehow it seems you don't _want_
to see why the filtering outbond on an interface is so important. I gave a
very good
Okay, I think I'm starting to understand what you want. (because I
believe we tossed the idea around at the last hackathon)
Basically, you want a state-creating packet to be able to create state
on multiple interfaces, like:
pass in on $ext_if proto tcp from any to $webserver port 80 \
keep
On Thu, Mar 20, 2003 at 12:32:50PM -0700, [EMAIL PROTECTED] wrote:
Okay, I think I'm starting to understand what you want. (because I
believe we tossed the idea around at the last hackathon)
Basically, you want a state-creating packet to be able to create state
on multiple interfaces, like:
Yes, thank you. I also still mean that pf(4) should not care about
packets going 'out' of an interface, only in, but let's kill this
thread.
Again: traffic can originate on the firewall box. Since this traffic
never passes inbound on an interface, filtering MUST be done
on the outbound
On Thu, Mar 20, 2003 at 02:16:02PM -0700, [EMAIL PROTECTED] wrote:
Again: traffic can originate on the firewall box. Since this traffic
never passes inbound on an interface, filtering MUST be done
on the outbound direction. (ie - transparent proxies).
Yes, but it could be nice if one could
Yes, but it could be nice if one could choose, eg.
set filter-policy {in, out, both} or something.
You can choose. Either type:
block out all
or
pass out all keep state
I do not understand this part of your argument at all.
-kj
This is cosmetics. However, whouldn't we get some performance increase
if pf(4) didn't bother looking at packets (in certain situations) going
'out' at all?
I assume that 'pass out all keep state' makes pf(4), at least, do a
state lookup in the table? AFAIK, that's, in worst case scenario,
On Thu, 20 Mar 2003 23:16:10 +0100, Srebrenko Sehic wrote:
On Thu, Mar 20, 2003 at 02:49:37PM -0700, [EMAIL PROTECTED] wrote:
Yes, but it could be nice if one could choose, eg.
set filter-policy {in, out, both} or something.
You can choose. Either type:
block out all
or
pass
Kyle R. Hofmann said:
So far everyone who has responded to you has been polite, despite your
inability to comprehend what they're telling you. Now, in the proud
tradition of OpenBSD lusers everywhere, I will flame you:
) ( ((
On Wed, Mar 19, 2003 at 11:04:26PM +0100, Srebrenko Sehic wrote:
While working on a pf(4) tutorial/article, I started wondering about the following,
1. What's the reason why packets 'travel' across an interface twice
(both in and out)? This makes, IMHO, writing very tight rules a bit
tricky.
On Thu, Mar 20, 2003 at 12:19:13AM +0100, Srebrenko Sehic wrote:
On Wed, Mar 19, 2003 at 11:27:26PM +0100, Henning Brauer wrote:
1. What's the reason why packets 'travel' across an interface twice
(both in and out)? This makes, IMHO, writing very tight rules a bit
tricky. Especially if
On Wednesday, Mar 19, 2003, at 15:19 US/Pacific, Srebrenko Sehic wrote:
block in all
block out all
## allow traffic on $ext_if to $webserver on 80/tcp and 443/tcp
pass in on $ext_if proto tcp from any to $webserver port {80, 443} \
keep state
This would not work. Why? We need to pass out
20 matches
Mail list logo
