From bugmaster at FreeBSD.org Mon Aug 3 11:07:06 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 3 11:09:29 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200908031107.n73B73pF088732@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 35 problems total. From bugmaster at FreeBSD.org Mon Aug 10 11:07:03 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 10 11:08:59 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200908101107.n7AB716S025251@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 35 problems total. From tom at uffner.com Thu Aug 13 22:04:18 2009 From: tom at uffner.com (Tom Uffner) Date: Thu Aug 13 22:04:26 2009 Subject: packet forwarding/firewall performance question Message-ID: <4A8484E4.6090504@uffner.com> I am curious what level of performance I should expect from the firewall box described below in terms of packets/sec and bytes/sec. it is an 800 MHz VIA c3 with a Gigabit switch on the inside interface and 20 Mbs symetric Fios on the outside. both interfaces are 100 Mbs. it is running sshd, bsnmpd, sendmail (outbound only), bind9 (serving local domain info & queries from 5-15 machines on the LAN) and isc-dhcpd. it acts as a border firewall/router for a small LAN w/ 5 static external addresses & the rest NATed. Kernel: http://www.uffner.com/temp/GATEWAY.txt dmesg: http://www.uffner.com/temp/dmesg.txt rc.conf: http://www.uffner.com/temp/rc.conf.txt pf.conf: http://www.uffner.com/temp/pf.conf.txt i'm hoping a few people will give me estimates on what kind of throughput i should theoretically expect before i provide any actual test data. also, any suggestions on tuning would be welcome. so far in preliminary tests, enabling polling on the network interfaces reduces my performance slightly both to/from and through the box. net.inet.ip.fastforwarding doesn't seem to make much difference either way but i haven't done very thorough testing of it. increasing net.inet.tcp.sendbuf_max & recvbuf_max may have helped, but again, not sufficiently tested. From cbuechler at gmail.com Thu Aug 13 23:10:22 2009 From: cbuechler at gmail.com (Chris Buechler) Date: Thu Aug 13 23:10:29 2009 Subject: packet forwarding/firewall performance question In-Reply-To: <4A8484E4.6090504@uffner.com> References: <4A8484E4.6090504@uffner.com> Message-ID: On Thu, Aug 13, 2009 at 5:25 PM, Tom Uffner wrote: > I am curious what level of performance I should expect from the > firewall box described below in terms of packets/sec and bytes/sec. > > it is an 800 MHz VIA c3 with a Gigabit switch on the inside interface > and 20 Mbs symetric Fios on the outside. both interfaces are 100 Mbs. > it is running sshd, bsnmpd, sendmail (outbound only), bind9 (serving > local domain info & queries from 5-15 machines on the LAN) and isc-dhcpd. > it acts as a border firewall/router for a small LAN w/ 5 static external > addresses & the rest NATed. > Keeping this on pf since you aren't running -current. With what sounds like a nearly identical box, I've gotten 100 Mb wire speed with 7.x-based pfSense versions, which should be virtually identical to stock FreeBSD performance. I would expect 100 Mb wire speed with CPU to spare, using out of the box settings. > so far in preliminary tests, enabling polling on the network interfaces > reduces my performance slightly both to/from and through the box. That's to be expected, the only benefit of polling is to prevent live lock under extreme load. With only 100 Mb NICs I doubt if you could even get into that scenario with an 800 MHz CPU. > net.inet.ip.fastforwarding doesn't seem to make much difference either > way but i haven't done very thorough testing of it. I believe that has more impact with routing, and little or none when firewalling/NATing. > increasing > net.inet.tcp.sendbuf_max & recvbuf_max may have helped, but again, not > sufficiently tested. I don't think that has any impact on traffic through the system, rather that's for traffic initiated by the system, but not completely sure. From cswiger at mac.com Thu Aug 13 23:58:00 2009 From: cswiger at mac.com (Chuck Swiger) Date: Thu Aug 13 23:58:11 2009 Subject: packet forwarding/firewall performance question In-Reply-To: <4A8484E4.6090504@uffner.com> References: <4A8484E4.6090504@uffner.com> Message-ID: Hi-- On Aug 13, 2009, at 2:25 PM, Tom Uffner wrote: > it is an 800 MHz VIA c3 with a Gigabit switch on the inside interface > and 20 Mbs symetric Fios on the outside. both interfaces are 100 Mbs. I'd done a bit of testing of a VIA EPIA C3 (either a 600 or 800) with the on-board vr0 and an Intel fxp card, and it seemed to go OK up to ~ 8MB/s aka ~65 megabits/sec with a fairly short IPFW-based firewall doing NAT and suchlike. It's probably OK for your purpose, but the EPIA motherboard I had was somewhat flaky. I'd had the vr0 interface get wedged every few days, and trying to use both ATA channels in an UDMA mode tended to result in a total system hang; using only one ATA device, UDMA-100 was fine. I never ended up putting the box into a production use as a consequence. I've had better luck with something like the Soerkris 480x ... -- -Chuck From rwatson at FreeBSD.org Fri Aug 14 13:55:19 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Fri Aug 14 13:55:25 2009 Subject: packet forwarding/firewall performance question In-Reply-To: <4A8484E4.6090504@uffner.com> References: <4A8484E4.6090504@uffner.com> Message-ID: On Thu, 13 Aug 2009, Tom Uffner wrote: > i'm hoping a few people will give me estimates on what kind of throughput i > should theoretically expect before i provide any actual test data. > > also, any suggestions on tuning would be welcome. > > so far in preliminary tests, enabling polling on the network interfaces > reduces my performance slightly both to/from and through the box. > net.inet.ip.fastforwarding doesn't seem to make much difference either > way but i haven't done very thorough testing of it. increasing > net.inet.tcp.sendbuf_max & recvbuf_max may have helped, but again, not > sufficiently tested. I can't speak to absolute numbers, but I wouldn't expect net.inet.tcp.* changes to make any difference, as they should affect only locally terminated sockets on the firewall host, not forwarded packets. You might want to try experimenting with net.isr.direct -- try setting it to 0, as this changes the kernel dispatch model for the network stack. On a UP box, I would probably anticipate a performance loss for making that change, or similar configuration changes for multiple netisr threads using net.isr.maxthreads. If you're using firewall code, fast forwarding is unlikely to make a difference. Depending on the cache/memory/CPU trade-off, you might find turning off flowtable support helps -- net.inet.flowtable.enable=0. Robert N M Watson Computer Laboratory University of Cambridge From zvujovic at gmail.com Sat Aug 15 18:01:02 2009 From: zvujovic at gmail.com (z0ran) Date: Sat Aug 15 18:01:23 2009 Subject: freebsd-8-beta2 and pf Message-ID: First of all i couldn't enable pf with "pfctl -e", then i couldn't load module with "kldload pf.ko", it gives me % kldload /boot/kernel/pf.ko kldload: can't load /boot/kernel/pf.ko: Exec format error and at the end i couldn't find in kernel: device pf device pflog device pfsync This is my % uname -a FreeBSD freebsd.svarog-r00lz.info 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Wed Jul 15 21:48:41 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 and % file /boot/kernel/pf.ko /boot/kernel/pf.ko: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped % kldstat Id Refs Address Size Name 1 15 0xffffffff80100000 ef0820 kernel 2 1 0xffffffff80ff1000 196498 zfs.ko 3 2 0xffffffff81188000 3a98 opensolaris.ko 4 1 0xffffffff8118c000 23f48 snd_hda.ko 5 2 0xffffffff811b0000 86d88 sound.ko this is my /var/log/messages: Aug 15 07:00:00 freebsd newsyslog[1234]: logfile turned over due to size>100K Aug 15 07:01:45 freebsd console-kit-daemon[1145]: WARNING: kvm_getenvv failed: cannot open /proc/1209/mem Aug 15 07:01:45 freebsd gnome-session[1209]: WARNING: Unable to determine session: Unable to lookup session information for process '1209' Aug 15 13:55:14 freebsd console-kit-daemon[1145]: WARNING: kvm_getenvv failed: cannot open /proc/1209/mem Aug 15 13:55:14 freebsd gnome-session[1209]: WARNING: Unable to determine session: Unable to lookup session information for process '1209' Aug 15 13:55:58 freebsd kernel: lock order reversal: Aug 15 13:55:58 freebsd kernel: 1st 0xffffff0044baca48 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 Aug 15 13:55:58 freebsd kernel: 2nd 0xffffff0053e287f8 zfs (zfs) @ /usr/src/sys/kern/vfs_subr.c:4091 Aug 15 13:55:58 freebsd kernel: KDB: stack backtrace: Aug 15 13:55:58 freebsd kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a Aug 15 13:55:58 freebsd kernel: _witness_debugger() at _witness_debugger+0x2e Aug 15 13:55:58 freebsd kernel: witness_checkorder() at witness_checkorder+0x81e Aug 15 13:55:58 freebsd kernel: __lockmgr_args() at __lockmgr_args+0xcf3 Aug 15 13:55:58 freebsd kernel: vop_stdlock() at vop_stdlock+0x39 Aug 15 13:55:58 freebsd kernel: VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b Aug 15 13:55:58 freebsd kernel: _vn_lock() at _vn_lock+0x47 Aug 15 13:55:58 freebsd kernel: knlist_remove_kq() at knlist_remove_kq+0x67 Aug 15 13:55:58 freebsd kernel: knote_fdclose() at knote_fdclose+0x177 Aug 15 13:55:58 freebsd kernel: kern_close() at kern_close+0xe9 Aug 15 13:55:58 freebsd kernel: syscall() at syscall+0x1af Aug 15 13:55:58 freebsd kernel: Xfast_syscall() at Xfast_syscall+0xe1 Aug 15 13:55:58 freebsd kernel: --- syscall (6, FreeBSD ELF64, close), rip = 0x800e46f8c, rsp = 0x7fffffffe538, rbp = 0x800f7eb80 --- and this is /var/run/dmesg.boot Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-BETA2 #0: Wed Jul 15 21:48:41 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) 9550 Quad-Core Processor (2200.09-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x7ff TSC: P-state invariant real memory = 3221225472 (3072 MB) avail memory = 2829471744 (2698 MB) ACPI APIC Table: <073108 APIC1642> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <073108 RSDT1642> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, aff00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xc000-0xc0ff mem 0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 hdac0: mem 0xfe9e8000-0xfe9ebfff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib2: irq 18 at device 6.0 on pci0 pci2: on pcib2 re0: port 0xd800-0xd8ff mem 0xfeaff000-0xfeafffff,0xfdff0000-0xfdffffff irq 18 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:21:97:08:14:22 re0: [FILTER] atapci0: port 0xb000-0xb007,0xa000-0xa003,0x9000-0x9007,0x8000-0x8003,0x7000-0x700f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe7fd000-0xfe7fdfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe7ff000-0xfe7ff0ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.0 on pci0 ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe7fb000-0xfe7fbfff irq 18 at device 19.1 on pci0 ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe7fa800-0xfe7fa8ff irq 19 at device 19.2 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] hdac1: mem 0xfe7f4000-0xfe7f7fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20090624_0136 hdac1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 rl0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff irq 20 at device 5.0 on pci3 miibus1: on rl0 rlphy0: PHY 0 on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:a1:b0:01:38:1a rl0: [ITHREAD] ohci4: mem 0xfe7f9000-0xfe7f9fff irq 18 at device 20.5 on pci0 ohci4: [ITHREAD] usbus6: on ohci4 acpi_button0: on acpi0 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse, device ID 3 atrtc0: port 0x70-0x71 irq 8 on acpi0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] driver bug: Unable to set devclass (devname: (null)) cpu0: on acpi0 acpi_throttle0: on cpu0 hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 driver bug: Unable to set devclass (devname: (null)) orm0: at iomem 0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range WARNING: ZFS is considered to be an experimental feature in FreeBSD. Timecounters tick every 1.000 msec usbus6: 12Mbps Full Speed USB v1.0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ZFS NOTICE: system has less than 4GB and prefetch enable is not set... disabling. ZFS filesystem version 13 ZFS storage pool version 13 ugen6.1: at usbus6 uhub0: on usbus6 ugen0.1: at usbus0 uhub1: on usbus0 ugen1.1: at usbus1 uhub2: on usbus1 ugen2.1: at usbus2 uhub3: on usbus2 ugen3.1: at usbus3 uhub4: on usbus3 ugen4.1: at usbus4 uhub5: on usbus4 ugen5.1: at usbus5 uhub6: on usbus5 acd0: DVDR at ata1-master UDMA66 ad4: 238475MB at ata2-master SATA300 hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: IDT 92HD206X pcm1: at cad 0 nid 1 on hdac1 pcm2: at cad 0 nid 1 on hdac1 pcm3: at cad 0 nid 1 on hdac1 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! WARNING: WITNESS option enabled, expect reduced performance. GEOM: ad4s1: geometry does not match label (255h,63s != 16h,63s). uhub0: 2 ports with 2 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub5: 3 ports with 3 removable, self powered Root mount waiting for: usbus5 usbus2 Root mount waiting for: usbus5 usbus2 uhub3: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered Trying to mount root from zfs:tank/root KLD pf.ko: depends on kernel - not available linker_load_file: Unsupported file type KLD pflog.ko: depends on pf - not available linker_load_file: Unsupported file type KLD pf.ko: depends on kernel - not available linker_load_file: Unsupported file type now, why is it pf.ko not available, any idea please, thanks in advance! -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From tom at uffner.com Sat Aug 15 19:02:08 2009 From: tom at uffner.com (Tom Uffner) Date: Sat Aug 15 19:02:16 2009 Subject: freebsd-8-beta2 and pf In-Reply-To: References: Message-ID: <4A87062B.1020706@uffner.com> z0ran wrote: > now, why is it pf.ko not available, any idea please, thanks in advance! did you build your kernel & pf modules at the same time? if not, try checking out the kernel sources for some consistent date and doing a "make buildkernel", complete with all the modules. that sort of error occurs in current if your modules are out of sync with your kernel after a version bump. From tom at uffner.com Sat Aug 15 23:58:29 2009 From: tom at uffner.com (Tom Uffner) Date: Sat Aug 15 23:58:36 2009 Subject: freebsd-8-beta2 and pf In-Reply-To: References: <4A87056D.2090106@uffner.com> Message-ID: <4A874B9B.9080807@uffner.com> z0ran wrote: > i tried to rebuild my kernel with and without pf modules, i also rebuild > it without "make options DEBUG=-g" and without "# Debugging for use in > -current options KDB options GDB options DDB options INVARIANTS" (that > was sugestion from freebsd forum) and no matter what i do it always > loads GENERIC kernel..so far, no idea why..anyway, thanks on so fast > respond. since 8.0 has reached beta status, i guess you are "allowed" to run it w/o being an expert and following the current & commits mailing lists, etc. but I would strongly suggest that you read /usr/src/UPDATING, and review the sections of the handbook on updating your system and building kernels. chances are you will figure out on your own what you are doing wrong, or what is broken. i can guarantee that it does work (at least on i386) because my system is FreeBSD xiombarg.uffner.com 8.0-BETA2 FreeBSD 8.0-BETA2 #0: Mon Aug 3 04:25:34 EDT 2009 tom@xiombarg.uffner.com:/usr/obj/usr/src/sys/XIOMBARG i386 and pf works fine either as a module or compiled in the kernel tomm From bugmaster at FreeBSD.org Mon Aug 17 11:07:00 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 17 11:09:18 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200908171107.n7HB70Vh075891@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 35 problems total. From ianf at clue.co.za Tue Aug 18 11:31:49 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Tue Aug 18 11:31:59 2009 Subject: packet forwarding/firewall performance question In-Reply-To: References: <4A8484E4.6090504@uffner.com> Message-ID: Robert Watson wrote: > > On Thu, 13 Aug 2009, Tom Uffner wrote: > > > i'm hoping a few people will give me estimates on what kind of > > throughput i should theoretically expect before i provide any actual > > test data. also, any suggestions on tuning would be welcome. > > > > so far in preliminary tests, enabling polling on the network > > interfaces reduces my performance slightly both to/from and through > > the box. net.inet.ip.fastforwarding doesn't seem to make much > > difference either way but i haven't done very thorough testing of > > it. increasing net.inet.tcp.sendbuf_max & recvbuf_max may have > > helped, but again, not sufficiently tested. > > I can't speak to absolute numbers, but I wouldn't expect > net.inet.tcp.* changes to make any difference, as they should affect > only locally terminated sockets on the firewall host, not forwarded > packets. > > You might want to try experimenting with net.isr.direct -- try setting > it to 0, as this changes the kernel dispatch model for the network > stack. On a UP box, I would probably anticipate a performance loss > for making that change, or similar configuration changes for multiple > netisr threads using net.isr.maxthreads. > > If you're using firewall code, fast forwarding is unlikely > to make a difference. Depending on the cache/memory/CPU > trade-off, you might find turning off flowtable support helps -- > net.inet.flowtable.enable=0. I found that forwarding made a fantastic difference to the forwarding rate in the past. Even with firewalling - was the difference between 38kpps and 500kpps using RTL8110 gigE interfaces. Perhaps I need to retest the effect on a modern FreeBSD. As to the OP, on a VIA Epia LN - C7-1GHz with vr interfaces maxed out at 100Mbit/s. Putting gigE interfaces in the PCI slot made no difference. The bottle-neck appeared to be the number of interrupts the cards generated and the amount of time servicing interrupts, which was not affected by polling(4). Ian -- Ian Freislich From zbeeble at gmail.com Tue Aug 18 18:03:09 2009 From: zbeeble at gmail.com (Zaphod Beeblebrox) Date: Tue Aug 18 18:03:15 2009 Subject: packet forwarding/firewall performance question In-Reply-To: References: <4A8484E4.6090504@uffner.com> Message-ID: <5f67a8c40908181032x5b23de27jc01dc1147281a1a6@mail.gmail.com> On Tue, Aug 18, 2009 at 6:57 AM, Ian FREISLICH wrote: > Robert Watson wrote: > > > > On Thu, 13 Aug 2009, Tom Uffner wrote: > > > > > i'm hoping a few people will give me estimates on what kind of > > > throughput i should theoretically expect before i provide any actual > > > test data. also, any suggestions on tuning would be welcome. > I havn't tried 800Mhz hardware, but I have extensive experience with the 266Mhz c3 in the WRAP board for comparison. The 266 Mhz part has no heatsink, but I've found it to be flakey in "hot" environments if a heatsink is not rigged to it. So... the WRAP boards have 3 "sis" interfaces. With various combinations of usage, one can expect 30 megabit of average sized packets if they kernel is doing the passing. This makes the board an adequate wireless bridge. If userland is doing the packet passing (pppd vs. mpd as a DSL router), I've had trouble getting more than about 10 megabit through the unit. This makes it an adequate DSL router but poor for aggregating multiple links. From linimon at FreeBSD.org Thu Aug 20 04:16:53 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Thu Aug 20 04:17:05 2009 Subject: kern/137982: [pf] when pf can hit state limits, random IP failures and no debugging info is provided Message-ID: <200908200416.n7K4Grbs081783@freefall.freebsd.org> Old Synopsis: when pf can hit state limits, random IP failures and no debugging info is provided New Synopsis: [pf] when pf can hit state limits, random IP failures and no debugging info is provided Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Thu Aug 20 04:16:16 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=137982 From max at love2party.net Thu Aug 20 09:21:15 2009 From: max at love2party.net (Max Laier) Date: Thu Aug 20 09:21:22 2009 Subject: (just for fun) port of OpenBSD pf's sloppy mode In-Reply-To: <4A8CFDAF.1000309@delphij.net> References: <4A8CFDAF.1000309@delphij.net> Message-ID: <200908201108.39177.max@love2party.net> Nice Work! Thanks a lot! On Thursday 20 August 2009 09:39:27 Xin LI wrote: > Since there is effort undergoing to port a newer pf version to FreeBSD, > I think this work would not be useful for inclusion in -CURRENT. > However, I'd like to share it here as someone may find it useful before > the new pf code hits the tree. The patch can also be downloaded from my I disagree about the usefulness of this. As your patch doesn't affect ABI this could make it into 8.1 (which the all new pf won't). With SVN it is also much simpler to manage the vendor branch differences, now. > website: > > http://www.delphij.net/pf-sloppy.diff freebsd-pf@ test and provide feedback - I know people have asked about this in the past. > About this patch: > > When pf(4) is operating in a manner that not all packet would went > through it, specifically, when being used in a DSR ("Direct Server > Return") network, the strict TCP state tracking would prevent some > packets from being able to pass through. This can exhibit as, when you > upload files, the connection would stall at ~60KB (may differ if you > have special TCP setting), or stalled connections. > > With this change, pf.conf would support a new syntax, i.e. "(sloppy)" as > state flag, e.g.: > > pass in quick on em0 route-to { (em1 $server1), (em1 $server2) } > round-robin proto tcp from any to $ext_ip port 80 keep state (sloppy) > > When enabled, the "sloppy" TCP FSM would be activated, which loosens the > state check. When using this option, the backend server has to use its > own mechanism to prevent ICMP teardown attack and/or insertion attacks, > so please use caution and limit the use in cases where pf(4) won't see > some packets in the connection. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From julian at elischer.org Thu Aug 20 16:31:55 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Aug 20 16:32:02 2009 Subject: pf and vimage In-Reply-To: <200908201108.39177.max@love2party.net> References: <4A8CFDAF.1000309@delphij.net> <200908201108.39177.max@love2party.net> Message-ID: <4A8D76FE.7040302@elischer.org> there were some people looking at adding vnet support to pf. Since we discussed it last, the rules of the game have significantly changed for the better. With the addition of some new facilitiesin FreeBSD, the work needed to virtualize a module has significantly decreased. The following doc gives the new rules.. -------------- next part -------------- August 17 2009 Julian Elischer =================== Vimage: what is it? =================== Vimage is a framework in the BSD kernel which allows a co-operating module to operate on multiple independent instances of its state so that it can participate in a virtual machine / virtual environment scenario. It refers to a part of the Jail infrastructure in FreeBSD. For historical reasons "Virtual network stack enabled jails"(1) are also known as "vimage enabled jails"(2) or "vnet enabled jails"(3). The currently correct term is the latter, which is a contraction of the first. In the future other parts of the system may be virtualized using the same technology and the term to cover all such components would be VIMAGE enhanced modules. The implementation approach taken by the vimage framework is a redefinition of selected global state variables to evaluate to constructs that allow for the virtualized state to be stored and resolved in appropriate instances of 'jail' specific container storage regions. The code operating on virtualized state has to conform to a set of rules described further below. Among other things in order to allow for all the changes to be conditionally compilable. i.e. permitting the virtualized code to fall back to operation on global state. The rest of this document will discuss NETWORK virtualization though the concepts may be true in the future for other parts of the system. The most visible change throughout the existing code is typically replacement of direct references to global variables with macros; foo_bar thus becomes V_foo_bar. V_foo_bar macros will resolve back to the foo_bar global in default kernel builds, and alternatively to the logical equivalent of some_base_pointer->_foo_bar for "options VIMAGE" kernel configs. Prepending of "V_" prefixes to variable references helps in visual discrimination between global and virtualized state. It is also possible to use an alternative syntax, of VNET(foo_bar) to achieve the same thing. The developers felt that V_foo_bar was less visually distracting while still providing enough clues to the reader that the variable is virtualized. In fact the V_foo_bar macro is locally defined near the definition of foo_bar to be an alias for VNET(foo_bar) so the two are not only equivalent, they are the same. The framework also extends the sysctl infrastructure to support access to virtualized state through introduction of the SYSCTL_VNET family of macros; those also automatically fall back to their standard SYSCTL counterparts in default kernel builds. Transparent libkvm(3) lookups are provided to virtualized variables which permits userland binaries such as netstat to operate unmodified on "options VIMAGE" kernels, though this may have some security implications. Vnets are associated with jails. In 8.0, every process is associated with a jail, usually the default (null) jail, and jails currently hang off of a processes ucred. This relationship defines a process's administrative affinity to a vnet and thus indirectly to all of its state. All network interfaces and sockets hold pointers back to their associated vnets. This relationship is obviously entirely independent from proc->ucred->jail bindings. Hence, when a process opens a socket, the socket will get bound to a vnet instance hanging off of proc->ucred->jail->vnet, but once such a socket->vnet binding gets established, it cannot be changed for the entire socket lifetime. The mapping of a from a thread to a vnet should always be done via the TD_TO_VNET macro as the path may change in the future as we get more experience with using the system. Certain classes of network interfaces (Ethernet in particular) can be reassigned from one vnet to another at any time. By definition all vnets are independent and can communicate only if they are explicitly provided with communication paths. Currently mainly netgraph is used to establish inter-vnet datapaths, though other paths are being explored such as the 'epair' back-to-back virtual interface pair, in which the different sides may exist in different jails. In network traffic processing the vnet affinity is defined either by the inbound interface or by the socket / pcb -> vnet binding. However, there are many functions in the network stack that cannot implicitly fetch the vnet context from their standard arguments. Instead of explicitly extending argument lists of such functions with a struct vnet *, the concept of a "current vnet", a per-thread variable was introduced, which can be fetched efficiently via the curvnet macro. The correct network context has to be set on entry to the network stack (socket operations, packet reception, or timer-driven functions) and cleared on exit. This must be done via provided CURVNET_SET() / CURVNET_RESTORE() family of macros, which allow for "stacking" of curvnet context setting and provide additional debugging info in INVARIANTS kernel configs. In most cases however a developer writing virtualized code will not have to set / restore the curvnet context unless the code would include timer-driven events, given that those are inherently vnet-contextless on entry. The current rule is that when not in networking code, the result of the 'curvnet' macro will return NULL and evaluating a V_xxx (or VNET(xxx)) macro will result in an kernel page-fault error. While this is not strictly necessary, it aids in debugging and assurance of program correctness. Note this does NOT mean that TD_TO_VNET(curthread) is invalid. A thread is always associated with a vnet, but just the efficient "curvnet" access method is disabled along with the ability to resolve virtualized symbols. Converting / virtualizing existing code ======================================= There are several steps need in virtualisation. 1/ Decide whether the module needs to be virtualised. If the module is a driver for specific hardware, it makes sense that there be only one instance of the driver as there is only one piece of physical hardware. There are changes in the networking code to allow physical (or virtual) interfaces to be moved between vnets. This generally requires NO changes to the network drivers of the classes covered (e.g. ethernet). Currently if your module is does not have any networking facet, the answer is "no" by default. 2/ If the module is to be virtualised, decide which attributes of the module should be virtualised. For example, It may make sense that there be a single central pool of "struct foo" and a single uma zone for them to come from, with a single lock guarding it. It might also make sense if the "foo_debug" sysctl controls all the instances at once, while on the other hand, the "foo_mode" sysctl might make better sense if it were controllable on a virtual system by virtual system basis. 3/ Work out what global variables and structures are to be virtualised to achieve the behaviour required for part #2. 4/ Work out for all the code paths through the module, how the thread entering the module can divine which virtual environment it is on. Some examples: * Since interfaces are all assigned to one vnet or another, an incoming packet has a pointer to the receive interface, which in turn has a pointer back to the vnet. Often "curvnet" will already have been set by the time your code is called anyhow. * Similarly, on any request from outside the kernel, (direct or indirect) the current thread has a way to get to the current virtual environment instance via TD_TO_VNET(curthread). For existing sockets the vnet context must be used via so->so_vnet since the thread's vnet might change after socket creation. * Timer initiated actions usually have a (void *) argument which points to some private structure for the module. It should be possible to add a pointer to the appropriate module instance into whatever structure that points to. * Sometimes an action (timer trigerred or trigerred by module load or unload simply has to check all the vimage or module instances. There are macro (pairs) for this which will iterate through all the VNET or instances. (see sample code below). This covers most of the cases, however in some cases it may still be required for the module to stash away the virtual environment instance somewhere, and make associated changes in the code. 5/ Decide which parts of the initialization and teardown are per jail and which parts are global, and separate out the code accordingly. Global initialization is done using the SYSINIT facility. Per jail initialization is done using VNET_SYSINIT(). Per jail teardown is doen using VNET_SYSUNINIT(). Global teardown is done using SYSUNIT(). In addition, the modevent handler is called with various event types before any of these are called. The modevent handler may veto load or teardown. On Shutdown, only the modevent handler is called so it may have to simulate the calling of the other handlers if clean shutdown is a requirement of your module. (see sample code below). Don't forget to unregister event handlers, and destroy locks and condition variables. 6/ Add the code described below to the files that make up the module. Details: (VNET implementation details) Firstly the file must be included. Depending on what code you use you may find you also need one or more of: , and . These requirements may change slightly as the ABI settles. Having decided which variables need to be virtualized, the definition of thosvariables needs to be modified to use the VNET_DEFINE() macro. For example: static int foo = 3; struct bar thebar = { 1,2,3 }; would become: static VNET_DEFINE(int, foo) = 3; VNET_DEFINE(struct bar, thebar) = { 1,2,3 }; extern int foo; in an include file might become: VNET_DECLARE(int foo); Normal rules regarding 'static/extern' apply. The initial values that you give in this way will be stored and used as the initial values for EACH NEW INSTANCE of these variables as new jails/vnets are created. As mentioned above, accesses to virtualized symbols are achieved via macros, which generally are of the same name as the original symbol but with a "V_" prepended, thus the head of the interface list, called 'ifnet' is replaced whereever used with "V_ifnet". We do this, by adding the following lines after the definitions above: #define V_foo VNET(foo) #define V_thebar VNET(thebar) --- side-note --- In SCTP, because the code is shared with other OS's they are replaced with a macro MODULE_GLOBAL(modulename, symbol). (this may simplify in light of recent changes). -------------- In addition, should any of your values need to be changed or viewed via sysctl, the following SYSCTL definitions would be needed: SYSCTL_VNET_PROC(_net_inet, OID_AUTO, thebar, CTLTYPE_?? | CTLFLAG_RW | CTLFLAG_SECURE3, &VNET_NAME(thebar), 0, thebar, "?", "the bar is open"); {[XXX] robert fix this is possible ^^^} SYSCTL_VNET_INT(_net_inet, OID_AUTO, foo, CTLFLAG_RW, &VNET_NAME(foo), 0, "size of foo"); In the current version of vimage, when VIMAGE is not compiled into the kernel, the macros evaluate to a direct reference to the one and only symbol/variable, so that there is no speed penalty for those not using vnets. When VIMAGE is compiled in, the macro will evaluate to an access to an offset into a data structure that is accessed on a per-vet basis. The vnet used for this is always curvnet. For this reason an attempt to access such a variable while curvnet is not valid, will result in an exception. To ensure that curvnet has a valid value when needed one needs to add the following code on all entry code paths into the networking code: int my_func(int arg) { CURVNET_SET(TD_TO_VNET(curthread)); do_my_network_stuff(arg); CURVNET_RESTORE(); return (0); } The initial value is usually something like "TD_TO_VNET(curthread) which in turn is a macro that derives the vnet affinity from the current thread. It could also be (m->m_ifp->if_vnet) if we were receiving an mbuf, or so->so_vnet if we had a socket involved. Usually, when a packet enters the system it is carried through the processing path via a single thread, and that thread will set its virtual environment reference to that indicated by the packet on picking up that new packet. This means that in the normal inbound processing path as well as the outgoing process path the current thread can be used to indicate the current virtual environment and curvet will always be valid once most user supplied code is reached. In timer events, it is sometimes necessary to add an "outer loop" to iterate through all the possible vnets if there is just one timer for all instances. When a new loadable module is virtualised the module definitions and intializers need to be examined. The following example illustrates what is needed in the case that you are not loading a new protocol, or domain. (for that see later) ============= sample skeleton code ========== /* init on boot or module load */ static int mymod_init(void) { return (error); } /**************** * Stuff that must be initialized for every instance * (including the first of course). */ static int mymod_vnet_init(const void *unused) { return (0); } /********************** * Called for the removal of the last instance only on module unload. */ static void mymod_uninit(void) { } /*********************** * Called for the removal of each instance. */ static int mymod_vnet_uninit(const void *unused) { return (0) } mymod_modevent(module_t mod, int type, void *unused) { int err = 0; switch (type) { case MOD_LOAD: /* check that loading is ok */ break; case MOD_UNLOAD: /* check that unloading is ok */ break; case MOD_QUIESCE: /* warning: try stop processing */ /* maybe sleep 1 mSec or something to let threads get out */ break; case MOD_SHUTDOWN: /* * this is called once but you may want to shut down * things in each jail, or something global. * In that case it's up to us to simulate the SYSUNINIT() * or the VNET_SYSUNINIT() */ { VNET_ITERATOR_DECL(vnet_iter); VNET_LIST_RLOCK(); VNET_FOREACH(vnet_iter) { CURVNET_SET(vnet_iter); mymod_vnet_uninit(NULL); CURVNET_RESTORE(); } VNET_LIST_RUNLOCK(); } /* you may need to shutdown something global. */ mymod_uninit(); break; default: err = EOPNOTSUPP; break; } return err; } static moduledata_t mymodmod = { "mymod", mymod_modevent, 0 }; /* define execution order using constants from /sys/sys/kernel.h */ #define MYMOD_MAJOR_ORDER SI_SUB_PROTO_BEGIN /* for example */ #define MYMOD_MODULE_ORDER (SI_ORDER_ANY + 64) /* not fussy */ #define MYMOD_SYSINIT_ORDER (MYMOD_MODULE_ORDER + 1) /* a bit later */ #define MYMOD_VNET_ORDER (MYMOD_MODULE_ORDER + 2) /* later still */ DECLARE_MODULE(mymod, mymodmod, MYMOD_MAJOR_ORDER, MYMOD_MODULE_ORDER); MODULE_DEPEND(mymod, ipfw, 2, 2, 2); /* depend on ipfw version (exactly) 2 */ MODULE_VERSION(mymod, 1); SYSINIT(mymod_init, MYMOD_MAJOR_ORDER, MYMOD_SYSINIT_ORDER, mymod_init, NULL); SYSUNINIT(mymod_uninit, MYMOD_MAJOR_ORDER, MYMOD_SYSINIT_ORDER, mymod_uninit, NULL); VNET_SYSINIT(mymod_vnet_init, MYMOD_MAJOR_ORDER, MYMOD_VNET_ORDER, mymod_vnet_init, NULL); VNET_SYSUNINIT(mymod_vnet_uninit, MYMOD_MAJOR_ORDER, MYMOD_VNET_ORDER, mymod_vnet_uninit, NULL); ========== end sample code ======= On BOOT, the order of evaluation will be: In a NON-VIMAGE kernel where the module is compiled: MODEVENT, SYSINIT and VNET_SYSINIT both runm with order defined by their order declarations. {good foot shooting material if you get it wrong!} In a VIMAGE kernel where the module is compiled in: MODEVNET, SYSINIT and VNET_SYSINIT all run with order defined by their order declarations. AND in addition, the VNET_SYSINIT is repeated once for every existing or new jail/vnet. On loading a vnet enabled kernel module after boot: MODEVENT("event = load"); SYSINIT() VNET_SYSINIT() for every existing jail AND in addition, VNET_SYSINIT being called for each new jail created. On unloading of module: MODEVENT("event = MOD_QUIESCE") MODEVENT("event = MOD_UNLOAD") VNET_SYSUNINIT called for every jail/vnet SYSUNINIT On system shutdown: MODEVENT(shutdown) NOTICE that while the order of the SYSINIT and VNET_SYSINIT is reversed from that of SYSUNINIT and VNET_SYSUNINIT, MODEVENTS do not follow this rule and thus it is dangerous to initialise and uninitialise things which are order dependent using MODEVENTs. Or, put another way, Since MODEVENT is called first during module load, it would, by the assumption that everything is reversed, be easy to assume that MODEVENT is called AFTER the SYSINITS during unload. This is in fact not the case. (and I have the scars to prove it). It might be make some sense if the "QUIESCE" was called before the SYSINIT/SYSUNINIT and the UNLOAD called after.. with a millisecond sleep between them, but this is not the case either. Since initial values are copied into the virtualized variables on each new instantiatin, it is quite possible to have modules for which some of the above methods are not needed, and they may be left out. (but not the modevent). Sometimes there is a need to iterate through the vnets. See the modevent shutdown handler (above) for an example of how to do this. Don't forget the locks. In the case where you are loading a new protocol, or domain (protocol family) there are some "shortcuts" that are in place to allow you to maintain a bit more source compatibility with older revisions of FreeBSD. It must be added that the sample code above works just fine for protocols, however protcols also have an aditional initialization vector which is via the prtocol structure, which has a pr_init() entry. When a protocol is registered using pf_proto_register(), the pr_init() for the protocol is called once for every existing vnet. in addition, it will be called for each new vnet. The pr_destroy() method will be called as well on vnet teardown. The pf_proto_register() funcion can be called either from a modevent handler of from the SYSINIT() if you have one, and the pf_proto_unregister() called from the SYSUNINIT or the unload modevent handler. If you are adding a whole new protocol domain, (protocol family) then you should add the VNET_DOMAIN_SET(domainname) (e,g, inet, inet6) macro. These use VNET_SYSINIT internally to indirectly call the dom_init() and pr_init() functions for each vnet, (and the equivalent for teardown.) In this case one needs to be absolutely sure that both your domain and protocol initializers can be called multiple times, once for each vnet. One can still add SYSINITs for once only initialization, or use the modevent handler. I prefer to do as much explicitly in the SYSINITS and VNET_SYSINITS as then you have no surprises. finally: The command to make a new jail with a new vnet: jail -c host.hostname=test path=/ vnet command=/bin/tcsh jail -c host.hostname=test path=/ children.max=4 vnet command=/bin/tcsh (children.max allows hierarchical jail creation). Note that the command must come last. From barowc at telenet.net Fri Aug 21 21:36:35 2009 From: barowc at telenet.net (barowc@telenet.net) Date: Fri Aug 21 21:46:15 2009 Subject: ALTQ and bandwidth limiting Message-ID: <4A8EFD59.6070106@telenet.net> I am about to install a machine at a co-location facility and I would like to limit the bandwidth on my interface to match the bandwidth i have contracted for. This is necessary because the connection i will have is not limited, but my usage is. I have added the following two lines to my pf.conf file, but this does not appear to be working. altq on $External cbq bandwidth 1Mb queue { std } queue std bandwidth 1Mb cbq(default) I assume all rules on $External will now default to this queue, and should be limited to 1Mb. I hav even specified the queue on the External rules, and there is still no limiting. Any help would be appreciated, Chris From LConrad at Go2France.com Sat Aug 22 23:53:22 2009 From: LConrad at Go2France.com (Len Conrad) Date: Sat Aug 22 23:53:38 2009 Subject: something like bruteblock for pf? Message-ID: <200908230132343.SM01728@W500.Go2France.com> I've used bruteblock, which manages ipfw, for blocking SMTP attackers and reducing smtp connects by 10s of 1000s per day. But bruteblock, which hasn't moved in 3 years, logged a lot of errors like "failed to ..." which didn't seem to bother its effectiveness, but was concerning, and ugly. Anybody know of anything similar for pf? thanks Len From mozolevsky at gmail.com Sun Aug 23 01:28:12 2009 From: mozolevsky at gmail.com (Igor Mozolevsky) Date: Sun Aug 23 01:28:19 2009 Subject: something like bruteblock for pf? In-Reply-To: <200908230132343.SM01728@W500.Go2France.com> References: <200908230132343.SM01728@W500.Go2France.com> Message-ID: 2009/8/23 Len Conrad : > > I've used bruteblock, which manages ipfw, for blocking SMTP attackers and reducing smtp connects by 10s of 1000s per day. [snip] > Anybody know of anything similar for pf? http://www.bgnett.no/~peter/pf/en/spamd.setup.html Cheers, -- Igor From LConrad at Go2France.com Sun Aug 23 01:41:42 2009 From: LConrad at Go2France.com (Len Conrad) Date: Sun Aug 23 01:41:49 2009 Subject: something like bruteblock for pf? In-Reply-To: References: <200908230132343.SM01728@W500.Go2France.com> Message-ID: <200908230340125.SM01728@W500.Go2France.com> >> I've used bruteblock, which manages ipfw, for blocking SMTP attackers and reducing smtp connects by 10s of 1000s per day. > >[snip] > >> Anybody know of anything similar for pf? > > >http://www.bgnett.no/~peter/pf/en/spamd.setup.html thanks, but I've never liked tarpitting, no matter how inexpensive it is, and I already have greylisting. I'm looking for something like bruteblock that logwatches (smtp, ssh, ftp, whatever) and inserts/removes TCP block rules into pf for x hours, so the protocol daemons are involved. Len From peter at allicient.co.uk Sun Aug 23 02:57:34 2009 From: peter at allicient.co.uk (Peter Maxwell) Date: Sun Aug 23 02:57:40 2009 Subject: something like bruteblock for pf? In-Reply-To: <200908230340125.SM01728@W500.Go2France.com> References: <200908230132343.SM01728@W500.Go2France.com> <200908230340125.SM01728@W500.Go2France.com> Message-ID: <7731938b0908221957g2150a2f0p3263b6cab72bdf81@mail.gmail.com> 2009/8/23 Len Conrad : > > I'm looking for something like bruteblock that logwatches (smtp, ssh, ftp, whatever) and inserts/removes TCP block rules into pf for x hours, so the protocol daemons are involved. > Are you sure you really need this in the first place? Others may disagree, but the way I see it is pf is a packet filter, your MTA should be dealing with SMTP "attacks". Nonetheless, it's probably fairly trivial to do something like you are requesting. Create your pf ruleset with table(s) and corresponding drop rules. You can then create a simple cron script that parses the logs from your sshd, ftpd, etc and uses pfctl to replace the appropriate table with offending IPs or address ranges. You would probably have to manage timeouts in your scripts as well though. Please note that - in most situations at least - allowing applications in userland to modify firewall rules is a particularly bad idea, for obvious reasons. Good firewall practice would suggest that the box doing packet filtering does that and only that, with all external services placed in a DMZ; if an attacker then comprimises one of your services then they cannot mess about with the firewall rules, or much else for that matter. Before implementing something like this, I would urge caution: if what you're asking was actually of any use, someone else would probably have done it properly. I can't imagine how log entries from an ftp server, say, are going to be related to your smtp server security? If it's a simple connection management, then max-src-conn/max-src-conn-rate might be a more robust solution. Peter From arlytex at gmail.com Sun Aug 23 09:05:27 2009 From: arlytex at gmail.com (Arlen Drina) Date: Sun Aug 23 09:05:34 2009 Subject: CARP failover strange behaviour-two master states on master and backup server Message-ID: <4e96b49a0908230137m6cfe420v2921593e99e8b706@mail.gmail.com> Hi list, I am using PF + CARP on OpenBSD 4.5 for my redundant firewall, but I have some strange situations, I cannot understand very well. So please review and give me your opinion, firewalls perform redundancy as expected and works but some stuff are not clear 1 ) master configuration for carp interfaces is eternal inet abc.abc.abc.abc 255.255.255.224 abc.abc.abc.abc.abc vhid 1 pass b5f06766c75cfsfsdfa6f87741430832 carpdev fxp0 advbase 10 advskew 0 state master internal inet 192.168.1.100 255.255.255.0 192.168.1.255 vhid 2 pass 5e0125fb892ef94542eddcc6ab78a1ae carpdev rl0 advbase 10 advskew 0 state master 2) on backup eternal inet abc.abc.abc.abc 255.255.255.224 abc.abc.abc.abc.abc vhid 1 pass b5f06766c75cfsfsdfa6f87741430832 carpdev fxp0 advbase 10 advskew 100 state master internal inet 192.168.1.100 255.255.255.0 192.168.1.255 vhid 2 pass 5e0125fb892ef94542eddcc6ab78a1ae carpdev rl0 advbase 10 advskew 100 state master as you can see I have different values for advbase/advskew, if master server is boot first and backup second, all ok, master become master and backup is backup server, but in case backup is booted first it becomes master, and after real master is boot up it becomes backup. I wondering how is this possible as I set up lower values for advskew /advbase on master to push it ( in case it is alive in normal environment ) to be always master. And master stays in backup state whole time. When there is normal process, master boots first and then slave, on both servers I have ifconfig -g carp carp: carp demote count 0 again should not these values be different on master and backup ? If I reboote master, while backup is on, after master reboot on it I have ifconfig -g carp carp: carp demote count 1 and it is marked as BACKUP. Also I noticed that master server after reboot is for a very short time marked as MASTER and very fast it switch again to BACKUP state. I played with carpdemote parameters on master/backup and in case BACKUP server : ifconfig -g carp carp: carp demote count 0 MASTER server : ifconfig -g carp carp: carp demote count 1 I do on BACKUP server ifconfig -g carp carpdemote 20 then is on BACKUP server ifconfig -g carp carp: carp demote count 20 and all traffice is switched from backup to master ( tcpdump -i $ext_if that shows ) what is what I expect and that works normal, but after increasing carpdemote on backup, internal carp interface change state to backup , but external carp interface on backup server remains MASTER, so in this situation I have two masters ....on backup and on master server. All works as expected, failover works correctly and ony above stuff is very confusing for me. Also I noticed that external carp device on both servers ( master and backup ) belongs to egress interface group too, carp interface is at same time default route interface and I understand it, I tried to raise carpdemote value for egress group to be same as for carp group but that did not helped, I still have two masters on external interfaces on master/backup. Sorry for long mail, if someone knows what could be cause for this behaviour is more than welcome to write it. Thank you in advance, Kind regards, Arlen From ronw at bals.org Sun Aug 23 14:37:02 2009 From: ronw at bals.org (Ron Wilhoite) Date: Sun Aug 23 14:37:08 2009 Subject: something like bruteblock for pf? In-Reply-To: <7731938b0908221957g2150a2f0p3263b6cab72bdf81@mail.gmail.com> References: <200908230132343.SM01728@W500.Go2France.com> <200908230340125.SM01728@W500.Go2France.com> <7731938b0908221957g2150a2f0p3263b6cab72bdf81@mail.gmail.com> Message-ID: <4A914FD1.7070500@bals.org> On 08/22/2009 10:57 PM Peter Maxwell wrote: > 2009/8/23 Len Conrad : >> I'm looking for something like bruteblock that logwatches (smtp, ssh, ftp, whatever) and inserts/removes TCP block rules into pf for x hours, so the protocol daemons are involved. >> ... > Before implementing something like this, I would urge caution: if what > you're asking was actually of any use, someone else would probably > have done it properly. I can't imagine how log entries from an ftp > server, say, are going to be related to your smtp server security? If > it's a simple connection management, then > max-src-conn/max-src-conn-rate might be a more robust solution. > http://johan.fredin.info/openbsd/block_ssh_bruteforce.html explains how to use max-src-conn-rate and expiretable. # pkg_info -x expiretable Information for expiretable-0.6: Comment: Utility to remove entries from the pf(4) table based on their age Description: Expiretable is a utility used to remove entries from the pf(4) table based on their age. The age in question being the amount of time that has passed since the statistics for each entry in the target table was last cleared. WWW: http://expiretable.fnord.se/ Ron From LConrad at Go2France.com Sun Aug 23 15:49:29 2009 From: LConrad at Go2France.com (Len Conrad) Date: Sun Aug 23 15:49:36 2009 Subject: something like bruteblock for pf? In-Reply-To: <4A914FD1.7070500@bals.org> References: <200908230132343.SM01728@W500.Go2France.com> <200908230340125.SM01728@W500.Go2France.com> <7731938b0908221957g2150a2f0p3263b6cab72bdf81@mail.gmail.com> <4A914FD1.7070500@bals.org> Message-ID: <200908231748187.SM01728@W500.Go2France.com> >n 08/22/2009 10:57 PM Peter Maxwell wrote: >>2009/8/23 Len Conrad : >>>I'm looking for something like bruteblock that logwatches (smtp, ssh, ftp, whatever) and inserts/removes TCP block rules into pf for x hours, so the protocol daemons are involved. >... >>Before implementing something like this, I would urge caution: if what >>you're asking was actually of any use, someone else would probably >>have done it properly. I can't imagine how log entries from an ftp >>server, say, are going to be related to your smtp server security? If >>it's a simple connection management, then >>max-src-conn/max-src-conn-rate might be a more robust solution. > >http://johan.fredin.info/openbsd/block_ssh_bruteforce.html explains how to use max-src-conn-rate and expiretable. > ># pkg_info -x expiretable >Information for expiretable-0.6: > >Comment: >Utility to remove entries from the pf(4) table based on their age > >Description: >Expiretable is a utility used to remove entries from the pf(4) table >based on their age. > >The age in question being the amount of time that has passed since >the statistics for each entry in the target table was last cleared. > >WWW: http://expiretable.fnord.se/ I have no problem putting IPs into pf, it's expiring them that was blocking me, but expiretable fixes that. I don't use pf for protecting these "sacrificial" machines generally, only for reactive blocking. thanks Len From artem at aws-net.org.ua Sun Aug 23 15:52:15 2009 From: artem at aws-net.org.ua (Artyom Viklenko) Date: Sun Aug 23 15:52:23 2009 Subject: something like bruteblock for pf? In-Reply-To: <200908230132343.SM01728@W500.Go2France.com> References: <200908230132343.SM01728@W500.Go2France.com> Message-ID: <4A915E6C.2060000@aws-net.org.ua> Len Conrad wrote: > I've used bruteblock, which manages ipfw, for blocking SMTP attackers and reducing smtp connects by 10s of 1000s per day. > > But bruteblock, which hasn't moved in 3 years, logged a lot of errors like "failed to ..." which didn't seem to bother its effectiveness, but was concerning, and ugly. > > Anybody know of anything similar for pf? > ports/security/sshguard-pf -- Sincerely yours, Artyom Viklenko. ------------------------------------------------------- artem@aws-net.org.ua | http://www.aws-net.org.ua/~artem artem@viklenko.net | http://www.viklenko.net/~artem FreeBSD: The Power to Serve - http://www.freebsd.org From nikky at mnet.bg Sun Aug 23 19:28:15 2009 From: nikky at mnet.bg (Nickola Kolev) Date: Sun Aug 23 19:28:22 2009 Subject: something like bruteblock for pf? In-Reply-To: <4A915E6C.2060000@aws-net.org.ua> References: <200908230132343.SM01728@W500.Go2France.com> <4A915E6C.2060000@aws-net.org.ua> Message-ID: <20090823221658.06da495e.nikky@mnet.bg> On Sun, 23 Aug 2009 18:21:16 +0300 Artyom Viklenko wrote: > Len Conrad wrote: > > I've used bruteblock, which manages ipfw, for blocking SMTP > > attackers and reducing smtp connects by 10s of 1000s per day. > > > > But bruteblock, which hasn't moved in 3 years, logged a lot of > > errors like "failed to ..." which didn't seem to bother its > > effectiveness, but was concerning, and ugly. > > > > Anybody know of anything similar for pf? > > > > ports/security/sshguard-pf Mentioning that, why dont you take a look at: http://blocksshd.sourceforge.net/ -- Best regards, Nickola From danger at FreeBSD.org Sun Aug 23 21:54:01 2009 From: danger at FreeBSD.org (Daniel Gerzo) Date: Sun Aug 23 21:54:08 2009 Subject: something like bruteblock for pf? In-Reply-To: <200908230132343.SM01728@W500.Go2France.com> References: <200908230132343.SM01728@W500.Go2France.com> Message-ID: <4A91B7E5.8050007@FreeBSD.org> Len Conrad wrote: > I've used bruteblock, which manages ipfw, for blocking SMTP attackers and reducing smtp connects by 10s of 1000s per day. > > Anybody know of anything similar for pf? security/bruteforceblocker -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From repcsike at gmail.com Sun Aug 23 22:14:41 2009 From: repcsike at gmail.com (=?ISO-8859-1?B?QmFs4XpzIE3hdOlmZnk=?=) Date: Sun Aug 23 22:14:47 2009 Subject: something like bruteblock for pf? In-Reply-To: <4A91B7E5.8050007@FreeBSD.org> References: <200908230132343.SM01728@W500.Go2France.com> <4A91B7E5.8050007@FreeBSD.org> Message-ID: Hi guys, I'm using bruteforceblocker at the moment on my systems, thanks for this great utility Daniel! Can you tweak it to be able to get the ips from proftpd or any other log, or its working out of the box, you just have to set it up in syslog.conf(didn't see that feature in the doc.)? Or for these things sshguard is more appropiate? Thanks, Best Regards, Repcsi 2009/8/23 Daniel Gerzo > Len Conrad wrote: > >> I've used bruteblock, which manages ipfw, for blocking SMTP attackers and >> reducing smtp connects by 10s of 1000s per day. >> Anybody know of anything similar for pf? >> > > security/bruteforceblocker > > -- > S pozdravom / Best regards > Daniel Gerzo, FreeBSD committer > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From bugmaster at FreeBSD.org Mon Aug 24 11:07:01 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 24 11:09:02 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200908241107.n7OB70Sv048678@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 36 problems total. From danger at FreeBSD.org Tue Aug 25 01:52:10 2009 From: danger at FreeBSD.org (Daniel Gerzo) Date: Tue Aug 25 01:52:17 2009 Subject: something like bruteblock for pf? In-Reply-To: References: <200908230132343.SM01728@W500.Go2France.com> <4A91B7E5.8050007@FreeBSD.org> Message-ID: <4A9343C8.3080101@FreeBSD.org> Bal?zs M?t?ffy wrote: > Hi guys, > > I'm using bruteforceblocker at the moment on my systems, thanks for this > great utility Daniel! > > Can you tweak it to be able to get the ips from proftpd or any other log, or > its working out of the box, you just have to set it up in syslog.conf(didn't > see that feature in the doc.)? > > Or for these things sshguard is more appropiate? Check the /usr/local/sbin/bruteforceblocker file and edit the line which looks like the following: if (/.*Failed password.*from ($work->{ipv4}|$work->{ipv6}|$work->{fqdn}) port.*/i || ... You just need to add any regular expression that meets your requirements and set the syslog up so that the logs are directed to bruteforceblocker as well. -- S pozdravom / Best regards Daniel Gerzo, FreeBSD committer From rivanr at gmail.com Tue Aug 25 10:04:27 2009 From: rivanr at gmail.com (Ivan Radovanovic) Date: Tue Aug 25 10:04:35 2009 Subject: Positive condition for adding in the table? Message-ID: <4A93B203.2000305@gmail.com> I am new into pf configuration and I am curious if it is possible to add some host into table in firewall rules if some conditions are met (not if they are broken). I was thinking about some way to prevent port scanning of machine and what came to me as obvious way to do it is this (in some pseudocode) block all communication with bad_guys allow all communication with good_guys allow any communication with my open port and put ip in good_guys table block sending any rst packet from me and put ip in bad_guys table /* somebody tried to connect to non-open port */ /* more criteria to remove someone from good_guys and put in bad_guys, according to connection rate, etc */ Anyway when I tried to code this into pf rules I discovered that I can't put host into table according to positive condition. Is there some workaround for this? From mkhitrov at gmail.com Tue Aug 25 13:03:20 2009 From: mkhitrov at gmail.com (Maxim Khitrov) Date: Tue Aug 25 13:03:26 2009 Subject: Filtering on multi-interface firewall Message-ID: <26ddd1750908250539l79735cabg4ce99c4eb445f61c@mail.gmail.com> Hello all, A quick question regarding the behavior of FreeBSD and pf when you have multiple local interfaces. In my case, I have a Soekris net5501 board with one interface being the uplink to ISP and the other three dedicated to separate networks. There should be no traffic passing from one network to the other and no one (except for a few admin IPs) should be able to connect to any firewall port, especially ssh. So to accomplish this, I have a default "block" rule followed by what traffic is allowed to pass. The following rule is used to permit internet traffic from one of the LANs: pass in quick on $int_if from ($int_if:network) to !($int_if) tag INET When this packet goes out on $ext_if, it is processed by a nat rule followed by another pass: nat on $ext_if tagged INET -> ($ext_if:0) pass out quick on $ext_if queue (def, pri) This part should work without problems (I say "should" because I don't have the ability to test all of this right now). But my question is about what happens if someone on $int_if network tries to connect to the IP assigned to $ext_if or one of the other two interfaces? It seems to me that this packet would be passed when coming in on $int_if, because the "!($int_if)" portion of the rule is satisfied. Once the packet makes it to the kernel, would the system then recognize that it is the final destination for that packet and let it go to whatever port was specified (ssh, for example)? What I'm looking for is a way to define a "pass in" rule, so long as the destination is guaranteed not to be the firewall itself, and I'm not sure if "!($int_if)" accounts for this other scenario. I know that I can create a table containing "self," but then the ruleset would need to be reloaded for every IP change. Is there some other way to specify "pass this packet in only if it isn't addressed to any local interface?" - Max From peter at bsdly.net Tue Aug 25 15:14:01 2009 From: peter at bsdly.net (Peter N. M. Hansteen) Date: Tue Aug 25 15:14:37 2009 Subject: something like bruteblock for pf? In-Reply-To: (Igor Mozolevsky's message of "Sun, 23 Aug 2009 02:07:23 +0100") References: Message-ID: <87eir0sz8o.fsf@thingy.bsdly.net> Igor Mozolevsky writes: >> I've used bruteblock, which manages ipfw, for blocking SMTP attackers and reducing smtp connects by 10s of 1000s per day. > > [snip] > >> Anybody know of anything similar for pf? > > http://www.bgnett.no/~peter/pf/en/spamd.setup.html OP more likely wants something like state tracking with overload tables, ie http://home.nuug.no/~peter/pf/en/bruteforce.html or similar (yes, please update your bookmarks to point to the nuug site, the bgnett one is getting stale). It's worth noting that the overload tables method is not limited to specific services as long as you can dream up sensible criteria and some useful action to take on the hosts that end up in the overload list. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From peter at bsdly.net Tue Aug 25 15:28:12 2009 From: peter at bsdly.net (Peter N. M. Hansteen) Date: Tue Aug 25 15:28:20 2009 Subject: Positive condition for adding in the table? In-Reply-To: <4A93B203.2000305@gmail.com> (Ivan Radovanovic's message of "Tue, 25 Aug 2009 11:42:27 +0200") References: <4A93B203.2000305@gmail.com> Message-ID: <87ab1nud5f.fsf@thingy.bsdly.net> Ivan Radovanovic writes: > I am new into pf configuration and I am curious if it is possible to add > some host into table in firewall rules if some conditions are met (not > if they are broken). There are a couple of apps out there that will update pf tables for you based on various conditions. One is authpf (a non-interactive user shell, frequently used for stuff like http://home.nuug.no/~peter/pf/en/vegard.authpf.html), likely something to build on. Then I was going to write that dhcpd can manipulate tables (for example, adding addresses it has assigned to a pf table), but then I realized that OpenBSD's dhcpd is not identical to the FreeBSD one so that particular feature may not be available immediately to readers of this list. Tables are nice, more apps that interface with pf through tables would likely be welcome. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds. From freebsd at optimis.net Tue Aug 25 15:30:53 2009 From: freebsd at optimis.net (George Davidovich) Date: Tue Aug 25 15:30:59 2009 Subject: something like bruteblock for pf? In-Reply-To: <200908231748187.SM01728@W500.Go2France.com> References: <200908230132343.SM01728@W500.Go2France.com> <200908230340125.SM01728@W500.Go2France.com> <7731938b0908221957g2150a2f0p3263b6cab72bdf81@mail.gmail.com> <4A914FD1.7070500@bals.org> <200908231748187.SM01728@W500.Go2France.com> Message-ID: <20090825151812.GA75010@marvin.optimis.net> On Sun, Aug 23, 2009 at 10:49:24AM -0500, Len Conrad wrote: > > n 08/22/2009 10:57 PM Peter Maxwell wrote: > > > 2009/8/23 Len Conrad : > > > > I'm looking for something like bruteblock that logwatches (smtp, > > > > ssh, ftp, whatever) and inserts/removes TCP block rules into pf > > > > for x hours, so the protocol daemons are involved. If you're looking for a general-purpose solution, see /usr/ports/sysutils/grok. The FreeBSD man cgi doesn't seem to want to show the manpage, so here's an alternate link for more information: http://www.semicomplete.com/projects/grok/ > > > Before implementing something like this, I would urge caution: if > > > what you're asking was actually of any use, someone else would > > > probably have done it properly. I can't imagine how log entries > > > from an ftp server, say, are going to be related to your smtp > > > server security? If it's a simple connection management, then > > > max-src-conn/max-src-conn-rate might be a more robust solution. > > > > http://johan.fredin.info/openbsd/block_ssh_bruteforce.html explains > > how to use max-src-conn-rate and expiretable. > > > > # pkg_info -x expiretable > > Information for expiretable-0.6: > > > > Comment: > > Utility to remove entries from the pf(4) table based on their age > > I have no problem putting IPs into pf, it's expiring them that was > blocking me, but expiretable fixes that. >From pfctl(8): -T command [address ...] Specify the command (may be abbreviated) to apply to the table. Commands include: ... -T expire number Delete addresses which had their statistics cleared more than number seconds ago. For entries which have never had their statistics cleared, number refers to the time they were added to the table. IIRC, the expire command was added in 7.0 or 7.1. -- George From bugmaster at FreeBSD.org Mon Aug 31 11:07:13 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 31 11:09:02 2009 Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org Message-ID: <200908311107.n7VB7Coc070658@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 36 problems total. From chihau at betazeta.com Mon Aug 31 14:21:14 2009 From: chihau at betazeta.com (Chihau Chau) Date: Mon Aug 31 14:21:21 2009 Subject: pf: unlocked lookup Message-ID: Hi everybody, I am experiment a crash in my freebsd 7.1 system every 5 days, the system show me this error message "pf: unlocked lookup". I only can do a hard reset to restart the system. Who can help me about this issue? Thanks -- Chihau Chau Betazeta Networks www.betazeta.com From leccine at gmail.com Mon Aug 31 14:30:22 2009 From: leccine at gmail.com (=?ISO-8859-1?B?SXN0duFu?=) Date: Mon Aug 31 14:30:31 2009 Subject: pf: unlocked lookup In-Reply-To: References: Message-ID: # sysctl debug.pfugidhack debug.pfugidhack: 0 what is yours? On Mon, Aug 31, 2009 at 2:49 PM, Chihau Chau wrote: > Hi everybody, > > I am experiment a crash in my freebsd 7.1 system every 5 days, the system > show me this error message "pf: unlocked lookup". > > I only can do a hard reset to restart the system. > > Who can help me about this issue? > > Thanks > > -- > Chihau Chau > Betazeta Networks > www.betazeta.com > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > -- the sun shines for all From chihau at betazeta.com Mon Aug 31 16:33:08 2009 From: chihau at betazeta.com (Chihau Chau) Date: Mon Aug 31 16:33:14 2009 Subject: pf: unlocked lookup In-Reply-To: References: Message-ID: It's 0 too debug.pfugidhack: 0 2009/8/31 Istv?n > # sysctl debug.pfugidhack > > debug.pfugidhack: 0 > > what is yours? > > On Mon, Aug 31, 2009 at 2:49 PM, Chihau Chau wrote: > >> Hi everybody, >> >> I am experiment a crash in my freebsd 7.1 system every 5 days, the system >> show me this error message "pf: unlocked lookup". >> >> I only can do a hard reset to restart the system. >> >> Who can help me about this issue? >> >> Thanks >> >> -- >> Chihau Chau >> Betazeta Networks >> www.betazeta.com >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >> > > > > -- > the sun shines for all > -- Chihau Chau Betazeta Networks www.betazeta.com