On Mon, Mar 31, 2003 at 10:53:09AM -0600, Darley Ware wrote:
> 1. I have webserver on the internal LAN which listens on port 8000. I can
> view the webserver internally by IP and by name (using LMHOST records). I
> have not however been able to access the internal webserver from the
> outside.
On Sun, Mar 30, 2003 at 06:29:09PM +0200, Henning Brauer wrote:
> yes, that is known. I don't see a real world problem with this; the effect
> is zero as skip steps solve that nicely.
Hurray for skip-steps then ;) However, imagine having tons of
aliases; resulting filter rules might get a bit ugl
$ cat /etc/hostname.fxp0
inet 10.0.3.20 255.0.0.0 NONE
inet alias 10.1.3.20 255.0.0.0
inet alias 10.2.3.20 255.0.0.0
inet alias 10.3.3.20 255.0.0.0
inet alias 10.4.3.20 255.0.0.0
inet alias 10.5.3.20 255.0.0.0
$ grep antispoof /etc/pf.c
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 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 situation
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 t
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 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 out all keep state
This is cosmetics. However, whouldn't we
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
On Thu, Mar 20, 2003 at 11:02:03AM -0800, Bryan Irvine wrote:
> no nat on $WAN from $LAN to $DMZ
> no nat on $WAN from $DMZ to $LAN
> nat on $WAN inet from $LAN to any -> ($WAN)
> nat on $WAN inet from $DMZ to any -> ($WAN)
Packets from $LAN to $DMZ and vice versa, never go across $WAN
interface.
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, l
On Thu, Mar 20, 2003 at 12:43:52AM +0100, Henning Brauer wrote:
> > No clear? Let me rephrase. Why not filter on inbound traffic only, even
> > though you have 'block all' in your ruleset?
>
> this is like asking why your car engine doesn't work even given you have
> fuel in a tank on the seat.
>
On Wed, Mar 19, 2003 at 04:23:00PM -0800, Trevor Talbot wrote:
> 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
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 you want to start off with 'block all'.
>
> they come in on one
On Wed, Mar 19, 2003 at 02:15:10PM -0800, Bryan Irvine wrote:
> So would I need to turn on RIP at all? Or would it just "know" because
> it's a directly connected interface?
Sure, if those 2 interfaces are directly connected, then pf(4) can
filter/route traffic (and do translation) without proble
On Wed, Mar 19, 2003 at 01:37:35PM -0800, Bryan Irvine wrote:
> What I want is for the 192.168.0.* and 10.0.*.* networks to see each
> other just fine. Which is possible to do with routing, but then for
> these networks to get onto the internet I have to turn on NAT (or do I?)
> which makes the 2
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. Especially if you want to start off with 'block all'.
2. Say I 'block
Eg, a pf.conf rule like,
rdr on $outside_if proto tcp from any to 10.1.3.20 port smtp ->
192.168.0.3 port smtp
will result in,
$ pfctl -sn | grep smtp
rdr on fxp0 inet proto tcp from any to 10.1.3.20 port = smtp ->
192.168.0.3 por
On Wed, Feb 26, 2003 at 10:46:58AM +0100, Roger Skjetlein wrote:
> Why are the Intel cards better than anything else?
> How does Intel compare to the 3Com905C for instance?
>
> Everyone claims that Intel is the thing, but haven't actualley seen any
> documentation on this yet.
Well, experience
For all you pf firewall builders. I just tried installing a Cisco 4-port
card (PIX-4FE; used in Cisco PIX firewalls) into my OpenBSD-current box
and guess what? It works like a charm, so I wanted to share it.
I know people often ask for this type of devices.
Interfaces are detected as separate fxp
For all you pf firewall builders. I just tried installing a Cisco 4-port
card (PIX-4FE; used in Cisco PIX firewalls) into my OpenBSD-current box
and guess what? It works like a charm, so I wanted to share it.
I know people often ask for this type of devices.
Interfaces are detected as separate fxp
On Fri, Feb 21, 2003 at 02:40:29PM -0500, Jason Dixon wrote:
> I don't want anyone's hair to stand on end, but I was just curious...
> with the clarification recently given by the Linux camp on the
> NFS/DF-bit issue, is there an effort currently under way to recognize
> and support their implement
On Wed, Feb 19, 2003 at 03:08:11PM -0700, [EMAIL PROTECTED] wrote:
> > if you think about it for a minute,
> > $interface/24
> > and
> > $interface:network
> > are not the same.
> > they CAN expand to teh same thing. one possibility. just one.
>
>
> Well true, but in most cases where this is
On Wed, Feb 19, 2003 at 09:26:16PM +0100, Cedric Berger wrote:
> Hmm, you're right.
> And reading from pfvar.h, I believe this should work.
> That's a weird setting, though.
> We really need to reimplement ($int_if:network) someday.
> I wrote a patch for that looong ago.
> Cedric
Is there any rea
On Fri, Feb 07, 2003 at 10:10:34PM -0300, jorge wrote:
> Hi:
> i need the feature and power the "PF", but i need also FreeVRRP...
>
> is possible install PF in FreeBSD ?
>
> (i am install Freevrrp in openbsd 3.1 and 3.2, compiles ok, but a the
> run command "/usr/local/sbin/freevrrpd" say:
>
> f
On Thu, Jan 09, 2003 at 11:13:41PM +0100, Henning Brauer wrote:
> > Didn't know that. So, authpf can insert rules on fly using anchors, but is
> > this possible with arbitrary applications? Say I want my snort box to insert
> > filter rules into pf, by sending a messages (something like
> > 'block
On Thu, Jan 09, 2003 at 09:43:34PM +0100, Daniel Hartmeier wrote:
> As for a library, that would only make sense if it were an additional
> abstraction layer somewhere between pf(4) ioctls and pfctl command line.
> Whether you find a level that changes less often than pf(4) but is more
> generic t
On Thu, Jan 09, 2003 at 09:52:56PM +0100, Cedric Berger wrote:
> There is a "table" feature that has just been commited to the kernel.
> You can write in pf.conf:
>
> table persist
> block in from to any
>
> And then, your snort box can do the following:
> ssh firewall pfctl -t snortblacklis
On Thu, Jan 09, 2003 at 07:50:09PM +0100, Henning Brauer wrote:
> > pfctl does not support inserting rules on the fly and authpf needs that.
> > On the other hand, the overhead of having that would be too big.
>
> h, things changed... authpf uses anchors now, that IS possible with
> pfctl...
On Thu, Jan 09, 2003 at 07:22:14PM +0100, Cedric Berger wrote:
> >If we leave out all the technical challenges involved, the real question
> >is if the pf developers find this idea useful at all?
> >
> A few points, in wrac:
>
> 1) I kind of like libraries, but they are difficult to get right,
>
On Thu, Jan 09, 2003 at 06:34:13PM +0100, Daniel Hartmeier wrote:
> On Thu, Jan 09, 2003 at 06:20:55PM +0100, Srebrenko Sehic wrote:
>
> > What do you think about this?
>
> There is some sharing of pfctl code with authpf already, but it's done
> by compiling and link
I've sent this some time ago to misc@, but didn't get much response. I
thought I might try the pf specific list.
While working on my own tool, rpfcd (remote pf control dameon,
http://www.insecure.dk/rpfcd/) I found myself reusing a lot of code from
pfctl for pf(4) related routines. While some of s
On Tue, Jan 07, 2003 at 04:58:50AM +0100, Daniel Hartmeier wrote:
> > Is scrub logging fully implemented? I have the following rules defined,
>
> The log options was ignored on scrub rules just until a couple of days
> ago. With a recent -current, it works.
My -current is from 04/01/03. Shouldn'
Is scrub logging fully implemented? I have the following rules defined,
$ sudo pfctl -sr -v | head -n 5
scrub in all fragment reassemble
[ Evaluations: 106920Packets: 105000Bytes: 0 States: 0 ]
scrub out log all fragment reassemble
[ Evaluations: 1920 Packets: 1920 B
On Mon, Dec 30, 2002 at 08:37:28PM +0100, Wouter Clarie wrote:
>
> On a related note: the default pf.conf in the distribution, does have:
>
> #set limit { states unlimited, frags 5000 }
>
> which is not parseable if uncommented.
/usr/src/etc/pf.conf also has,
#set loginterface none
#set optimi
On Mon, Dec 30, 2002 at 07:40:23PM +0100, Daniel Hartmeier wrote:
> On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote:
>
> > That should be more flexible eh? I'll see if i can cook up a diff for
> > that tonight.
>
> Yes, it's rather simple to add support for either 'inf' or 'unlimit
On Mon, Dec 30, 2002 at 07:05:40PM +0100, Wouter Clarie wrote:
> On Mon, 30 Dec 2002, Dries Schellekens wrote:
>
> > If you don't specify a limit for states, it will be unlimited. But if you
> > choice a number, there is no way to change it back to unlimited except by
> > rebooting. So there is a
On Mon, Dec 30, 2002 at 05:17:12PM +0100, Dries Schellekens wrote:
> So I guess the correct syntax would be 'set limit states inf'. Can you try
> this?
Doesn't work either. I get,
/etc/pf.conf:15: inf is not a number
pfctl: Syntax error in file: pf rules not loaded
// haver
Isn't 'set limit states unlimited' supposed to work in /etc/pf.conf?
I get this:
root@hellspawn:/root# grep states /etc/pf.conf
set limit { states unlimited, frags 5000 }
root@hellspawn:/root# grep states /usr/src/etc/pf.conf
#set limit { states unlimited, frags 5000 }
root@hellspaw
Following does not work (on -current from today, btw)
EXTIF="xl0"
EXTIP="{ 10.0.3.20, 10.1.3.20, 10.2.3.20 }"
block out log quick on $EXTIF from ! $EXTIP to any
root@hellspawn:/root# pfctl -f pf.conf
pf.conf:3: syntax error
If I remove the !, no problem. This is not normal, right?
// haver
40 matches
Mail list logo
