Re: RDR for internal machine
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. I saw a post the weekend about name based virtualhosting on web servers. This does not seem to apply to me as I have the server setup to respond to IP and have no virtualdomains configured. So I guess my question is do I have my redirect setup correctly, and if so where lies the problem? And you permit packets on $internal_if going to internal web server? rdr rules are not enough. Btw, filtering happens _after_ rdr, so you have to permit packets after the translation. What does tcpdump on webserver shows? Do you see any packets? 2. (and this one really is not that important) I can not seem to get a response to ICMP to outside addresses. I can ping both directions from the firewall and I believe my pings are getting out, but the responses to not return to the internal clients. Lemme get this right. You ping hosts outside your LANs and don't get responses back to the clients, but from the firewall itself, it works? Check your rules. If you 'block all on $inside_if' or something, you have to explicitly pass in/out icmp traffic on $inside_if. Again, tcpdump output could be nice. // haver
antispoof vs. ip aliases
$ 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.conf antispoof for fxp0 Loading this ruleset will result in, $ pfctl -sr | grep '10.0.0.0/8' block drop in on ! fxp0 inet from 10.0.0.0/8 to any block drop in on ! fxp0 inet from 10.0.0.0/8 to any block drop in on ! fxp0 inet from 10.0.0.0/8 to any block drop in on ! fxp0 inet from 10.0.0.0/8 to any block drop in on ! fxp0 inet from 10.0.0.0/8 to any block drop in on ! fxp0 inet from 10.0.0.0/8 to any Hence, we get a block statement for each alias, which is I guess fine if aliases have different masks, but in this case, it's kind a unneccesary. No? This is on x86/-current from 4 days ago. // haver
Re: antispoof vs. ip aliases
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 ugly. Without checking, can't this be fixed rather easily? Check on the netmask; if same as non-aliased mask, skip it.
Re: pf(4) schemantics
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 part of the discussion. So shut up flamer ;)
Re: pf(4) schemantics
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 is a performance issue here, or really, that this would be the bottleneck. If it is, show the facts, and we (I use the royal we here, meaning Daniel or Henning) can address it then. Hmm? It might not be a major bottleneck, but keeping state for nothing and on _two_ interfaces, must cost something. Let's not forget about memory cost also.
Re: pf(4) schemantics
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? please show me where that tiny little state search is a problem in real world. We want pf(4) to outperform those nifty FWSM/5Gbps firewall blades. No? ;)
Re: pf(4) schemantics
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 originate from the firewall itself. In a lot of
cases, it doesn't, though.
it would be keep state on { interface-list }, to make that clear.
I don't like the idea too much. I see _very_ little gain, but enough pain.
I mean, it's not knew. We talked about that during c2k2. That is a year ago
soon. If that idea had been so good we would have added it already, no? ;-)
I'm sure you guys will make the right judgement. I'm just tossing ideas
around.
Re: pf(4) schemantics
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:
pass in on $ext_if proto tcp from any to $webserver port 80 \
keep state on {$ext_if $int_if} flags S/SAFR
(The way I had envisioned it, this would only occur for the
state-creating packet, and it would only do so for the interfaces
indicated.)
Is this what you mean?
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.
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?
Henning? Others?
Re: pf(4) schemantics
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 choose, eg.
set filter-policy {in, out, both} or something.
pf(4) schemantics
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 all' and then want to pass some traffic from $net_a to
$net_b. First, I need 2 rules to allow {in,out} traffic from $net_a and
then 2 rules to allow {in,out} traffic back from $net_b. Sure, you can
group the {in,out} rules in one, i.e. pass from $net_a to $net_b.
Now, what could be very nice is to pf(4) behave more like the following,
- from pf(4) point of view, there is only inbound traffic from an
interface. I.e. all traffic originating from $net_a towards other
networks is always inbound for pf(4).
- when I write a rule like 'pass from $net_a to $net_b', I don't need
to write another rule saying 'pass from $net_b to $net_a'. pf(4) takes
care of that (we are statefull, right?)
- say I have 5 interfaces (or 10 VLANs) I filter on. However, not all of
the networks need to talk to each other. I.e. I could have a $net_c
that will not talk to $net_a, but will talk to $net_b. It could be
nice to be able to define this. Otherwise, the traffic never gets
routed by pf(4).
People that know a certain commerical firewall will recognize this
behaviour. Don't get me wrong, I love pf(4), but there might be room for
improvement.
Comments?
// haver
Re: Routing private networks
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 networks invisible to each other except via rdr rules, which won't work for this scenario. Look at 'no nat ...' in pf.conf(5). You can define a rule saying, if 192.168.0.* and 10.0.*.* need to talk to public addresses, nat them, otherwise, don't.
Cisco PIX 4-port 10/100 card in OpenBSD-current
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(4) cards (we all know how good they are). Dmesg is below. I haven't had a chance to test it in detail, but so far, they seem to work VERY good. The PCI bus might turn out to be a bottleneck, though! Dmesg is below. // haver OpenBSD 3.3-beta (GENERIC) #1: Thu Feb 20 18:12:15 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD K6-2 (AuthenticAMD 586-class) 451 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX real mem = 268005376 (261724K) avail mem = 242663424 (236976K) using 3297 buffers containing 13504512 bytes (13188K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(06) BIOS, date 07/16/99, BIOS32 rev. 0 @ 0xf0690 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown pcibios0 at bios0: rev. 2.1 @ 0xf/0xd42 pcibios0: PCI IRQ Routing Table rev. 1.0 @ 0xf0ca0/160 (8 entries) pcibios0: PCI Interrupt Router at 000:07:0 (Acer Labs M1543 PCI-ISA rev 0x00) pcibios0: PCI bus #2 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x3000 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Acer Labs M1541 Host-PCI rev 0x04 ppb0 at pci0 dev 1 function 0 Acer Labs M5243 AGP/PCI-PCI rev 0x04 pci1 at ppb0 bus 1 Acer Labs M7101 Power Mgmt rev 0x00 at pci0 dev 3 function 0 not configured pcib0 at pci0 dev 7 function 0 Acer Labs M1543 PCI-ISA rev 0xc3 adv0 at pci0 dev 9 function 0 Advansys ABP-930/40UA rev 0x02: irq 7 scsibus0 at adv0: 7 targets ppb1 at pci0 dev 10 function 0 DEC 21154 PCI-PCI rev 0x02 pci2 at ppb1 bus 2 fxp0 at pci2 dev 0 function 0 Intel 82557 rev 0x05: irq 3, address 00:e0:b6:01:07:82 inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 0 fxp1 at pci2 dev 1 function 0 Intel 82557 rev 0x05: irq 7, address 00:e0:b6:01:07:81 inphy1 at fxp1 phy 1: i82555 10/100 media interface, rev. 0 fxp2 at pci2 dev 2 function 0 Intel 82557 rev 0x05: irq 11, address 00:e0:b6:01:07:80 inphy2 at fxp2 phy 1: i82555 10/100 media interface, rev. 0 fxp3 at pci2 dev 3 function 0 Intel 82557 rev 0x05: irq 10, address 00:e0:b6:01:07:7f inphy3 at fxp3 phy 1: i82555 10/100 media interface, rev. 0 vga1 at pci0 dev 12 function 0 Matrox MGA G200 PCI rev 0x01 wsdisplay0 at vga1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) eap0 at pci0 dev 13 function 0 Ensoniq AudioPCI rev 0x00: irq 7 audio0 at eap0 pciide0 at pci0 dev 15 function 0 Acer Labs M5229 UDMA IDE rev 0xc1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: IBM-DTLA-307045 wd0: 16-sector PIO, LBA, 32253MB, 16383 cyl, 16 head, 63 sec, 66055244 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 wd1 at pciide0 channel 1 drive 0: IBM-DTTA-351010 wd1: 16-sector PIO, LBA, 9671MB, 16383 cyl, 16 head, 63 sec, 19807200 sectors atapiscsi0 at pciide0 channel 1 drive 1 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: TOSHIBA, CD-ROM XM-6402B, 1008 SCSI0 5/cdrom removable wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 cd0(pciide0:1:1): using PIO mode 4 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker sysbeep0 at pcppi0 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask c0c0 netmask ccc8 ttymask dcca pctr: user-level cycle counter enabled mtrr: K6-family MTRR support (2 registers) dkcsum: wd0 matched BIOS disk 80 dkcsum: wd1 matched BIOS disk 81 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302
Cisco PIX 4-port 10/100 card in OpenBSD-current
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(4) cards (we all know how good they are). Dmesg is below. I haven't had a chance to test it in detail, but so far, they seem to work VERY good. The PCI bus might turn out to be a bottleneck, though! Dmesg is below. // haver OpenBSD 3.3-beta (GENERIC) #1: Thu Feb 20 18:12:15 CET 2003 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: AMD K6-2 (AuthenticAMD 586-class) 451 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX real mem = 268005376 (261724K) avail mem = 242663424 (236976K) using 3297 buffers containing 13504512 bytes (13188K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(06) BIOS, date 07/16/99, BIOS32 rev. 0 @ 0xf0690 apm0 at bios0: Power Management spec V1.2 apm0: AC on, battery charge unknown pcibios0 at bios0: rev. 2.1 @ 0xf/0xd42 pcibios0: PCI IRQ Routing Table rev. 1.0 @ 0xf0ca0/160 (8 entries) pcibios0: PCI Interrupt Router at 000:07:0 (Acer Labs M1543 PCI-ISA rev 0x00) pcibios0: PCI bus #2 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x3000 pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Acer Labs M1541 Host-PCI rev 0x04 ppb0 at pci0 dev 1 function 0 Acer Labs M5243 AGP/PCI-PCI rev 0x04 pci1 at ppb0 bus 1 Acer Labs M7101 Power Mgmt rev 0x00 at pci0 dev 3 function 0 not configured pcib0 at pci0 dev 7 function 0 Acer Labs M1543 PCI-ISA rev 0xc3 adv0 at pci0 dev 9 function 0 Advansys ABP-930/40UA rev 0x02: irq 7 scsibus0 at adv0: 7 targets ppb1 at pci0 dev 10 function 0 DEC 21154 PCI-PCI rev 0x02 pci2 at ppb1 bus 2 fxp0 at pci2 dev 0 function 0 Intel 82557 rev 0x05: irq 3, address 00:e0:b6:01:07:82 inphy0 at fxp0 phy 1: i82555 10/100 media interface, rev. 0 fxp1 at pci2 dev 1 function 0 Intel 82557 rev 0x05: irq 7, address 00:e0:b6:01:07:81 inphy1 at fxp1 phy 1: i82555 10/100 media interface, rev. 0 fxp2 at pci2 dev 2 function 0 Intel 82557 rev 0x05: irq 11, address 00:e0:b6:01:07:80 inphy2 at fxp2 phy 1: i82555 10/100 media interface, rev. 0 fxp3 at pci2 dev 3 function 0 Intel 82557 rev 0x05: irq 10, address 00:e0:b6:01:07:7f inphy3 at fxp3 phy 1: i82555 10/100 media interface, rev. 0 vga1 at pci0 dev 12 function 0 Matrox MGA G200 PCI rev 0x01 wsdisplay0 at vga1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) eap0 at pci0 dev 13 function 0 Ensoniq AudioPCI rev 0x00: irq 7 audio0 at eap0 pciide0 at pci0 dev 15 function 0 Acer Labs M5229 UDMA IDE rev 0xc1: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: IBM-DTLA-307045 wd0: 16-sector PIO, LBA, 32253MB, 16383 cyl, 16 head, 63 sec, 66055244 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2 wd1 at pciide0 channel 1 drive 0: IBM-DTTA-351010 wd1: 16-sector PIO, LBA, 9671MB, 16383 cyl, 16 head, 63 sec, 19807200 sectors atapiscsi0 at pciide0 channel 1 drive 1 scsibus1 at atapiscsi0: 2 targets cd0 at scsibus1 targ 0 lun 0: TOSHIBA, CD-ROM XM-6402B, 1008 SCSI0 5/cdrom removable wd1(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 cd0(pciide0:1:1): using PIO mode 4 isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pmsi0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pmsi0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker sysbeep0 at pcppi0 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask c0c0 netmask ccc8 ttymask dcca pctr: user-level cycle counter enabled mtrr: K6-family MTRR support (2 registers) dkcsum: wd0 matched BIOS disk 80 dkcsum: wd1 matched BIOS disk 81 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302
Re: Linux NFS no-DF status
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 implementation for 3.3 -release? Meaning, PF won't break it anymore? AFAIK, this issue is fixed -current and will be in 3.3. // haver
Re: Syntax error in Snapshot pf.conf
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 used, the intent is the latter (the network $interface sits on). I would expect :network and :broadcast syntax to satisfy just about everyone. Agree. Flexibility is great, but it just might get too flexible. KISS. // haver
RFC: libpf, simplifying pf(4) access to userland apps
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 stuff is rather straighforward, some other (like printing filter rules, i.e. pfctl -sr) is quite hard. A library implementing these commonly used routines, integrated/developed in the official tree, would help a lot. Userland tools would have a common framework for manipulating pf(4). Eg. pfctl would be much smaller, including other tools like newly introduced pftop and my own utility rpfcd. And yes, I'm aware of libdnet. However, this is not pf specific and is lacking a lot of features and is broken most of the time, since a lot changes are happening to pf(4) code. What do you think about this? // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
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 linking some source modules of pfctl from authpf. I guess you could try and move those shared functions into a library, whether it's a good idea will be visible by how well authpf can use it. If the library API is significantly different from the API of the currently shared source modules (share function prototypes, etc.), that might be a problem when the pf(4) ioctl interface changes and the library API would have to be adjusted. But it would be worth carefully looking at the currently shared modules, and sorting all functions and shared globals to into either shared or private modules. Whether you put the shared code into a library or just link an object file from pfctl is then just a detail. :) If we leave out all the technical challenges involved, the real question is if the pf developers find this idea useful at all? The only way libpf whould ever be a hit is if it was developed/maintained in the official tree. Otherwise, libpf maintainer would need to do spend a lot of time figuring out the changes happening to pf, pfctl, authpf, etc. How often do pf(4) structures changes? 5 times a week? IMHO, it would be a mission impossible to maintain it externally. // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
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, and probably more difficult is to have people agree to use it. In case of pf(4), I don't see why anybody would object to using it. If it is done correctly, of course. E.g. I had to write 500+ lines of code just to get a list of currently loaded filter rules. If we had a library, I bet 20 lines would've been enough. 2) Theo doesn't like libraries too much. Imagine what would OpenBSD look like if it didn't have any libraries ;) Again, if done properly, I doubt even Theo would have anything against it. 3) The current way file are shared between pfctl, authpf and tcpdump is kind of ugly IMHO. Can't really tell, but a library would've been nicer, for sure. 4) I've never used authpf, but I wonder why authpf does not call the pfctl binary, to have the benefit of code reuse without that tricky sharing of files. Combining binaries is usually the Unix way, I believe. 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. // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
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 snortblacklist persist block in from snortblacklist to any And then, your snort box can do the following: ssh firewall pfctl -t snortblacklist -Ta 192.168.0.1 Nic. Btw, what's the main difference between tables and anchors? // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
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 than pfctl decides how useful it would be. If it changes with each pf(4) change, it will just be another piece in the puzzle to update everytime, increasing the amount of work caused by changes. Good abstraction layer is possible. I don't really see why a library 'hiding' the behind the scene changes happening to pf could cause more grief. In fact, even the in tree things (authpf, pfsync, whatever) might benefit from that. Imagine, #include libpf.h int ret = insert_pf_rule(block in from 192.168.0.1 to any); Perhaps I'm asking for too much, but that would be nice. I don't suggest that userland tools like libdnet, pftop, symon, etc. should immediately adjust to all -current changes in pf. It's probably enough if they just provide one working source for each OpenBSD -release/-stable. Perhaps. But if you have a single box and want to follow -current, but you also want to maintain a piece of software, that becomes rather difficult ;) If you want an update to -current, mail me, I'll happily adjust your source to -current. It causes me less work to adjust a handful of userland tools than maintaining a library. :) Heh. Thanks for the offer, but I can do that myself. As Car mentioned before, you might go mad after a couple of -current synchs. It might be a handful of tools now, but with a decent library API, there might be many more. But ok, I'll shut up now. // haver
Re: RFC: libpf, simplifying pf(4) access to userland apps
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 192.168.0.1') to a daemon running on my pf fw and have the daemon translate that into a rules which can be added to the filter/anchor. I guess the answer is yes. Write an authpf-like daemon (with a remote interface) and let is do the job. Oh, this brings us back to the original issue. It would be hell to maintain. what? no, easier, you just call pfctl and let it load the set of custom rules to the anchor defined in your main pf.conf... Perhaps. But it would be better to talk to the kernel directly, thru an API, instead of forking pfctl every time I need a rule added/removed from an anchor/table. Does authpf call pfctl? AFAIK, no. // haver
Re: 'scrub out log' not working?
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't this work? [ Evaluations: 1920 Packets: 1920 Bytes: 0 States: 0 ] However, /var/log/pflog nor tcpdump on pflogd show anything. Perhaps zero sized packets don't get logged at all? Only the packet counters are increased. We could also count the bytes, I guess. But the zero byte counters you quoted don't mean the packets were zero sized, size is just not incremented for scrub rules. I though so. Anyways, I'll synch my -current and try again. // haver
'scrub out log' not working?
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 Bytes: 0 States: 0 ] However, /var/log/pflog nor tcpdump on pflogd show anything. Perhaps zero sized packets don't get logged at all? // haver
set limit states ulimited and pf.conf
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@hellspawn:/root# pfctl -Of /etc/pf.conf
/etc/pf.conf:15: unlimited is not a number
pfctl: Syntax error in file: pf rules not loaded
If not, what is the proper syntax? (and someone should fix
src/etc/pf.conf)
This is on -current from 2 days ago.
// haver
--
Library is an arsenal of liberty, -- unknown
Re: set limit states ulimited and pf.conf
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
Re: set limit states ulimited and pf.conf
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 also no way to set to limit for frags to unlimited. That should be more flexible eh? I'll see if i can cook up a diff for that tonight. DIOCSETLIMIT pf(4) ioctl hook is your friend ;) // haver
Re: set limit states ulimited and pf.conf
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 'unlimited' to the parser (it just has to translate to UINT_MAX). But it really makes no difference whether you set the limit to a high number or unlimited. In fact, it makes little sense to leave the limits unlimited, as the kernel will actually crash when memory is exhausted. So you really want to set a low enough limit in any case, and not leave settings unlimited. We already discussed setting the state limit to 5000 by default. You can increase it depending on your memory, but it's rather pointless setting it (back) to unlimited. How about having a possiblity to define a limit in relative way? Like 80% of free memory or something. That way, kernel would not crash and the limits could be dynamic, depending on the current memory utilization. I understand that this could have performance penalities (since memory checks should be done for every new state created). There must be a better way to handle this, rather then hardcoding state limits. No? // haver
macro expansion and '!' wierdness
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
