From owner-freebsd-pf@FreeBSD.ORG Sun Jun 7 03:37:19 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A2F2E36 for ; Sun, 7 Jun 2015 03:37:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83F921479 for ; Sun, 7 Jun 2015 03:37:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t573bJJs045421 for ; Sun, 7 Jun 2015 03:37:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Sun, 07 Jun 2015 03:37:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 03:37:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #7 from Kristof Provost --- Created attachment 157492 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157492&action=edit Possible patch I've had a look, and I think I know why you're seeing this panic. Can you try this patch? Basically the issue is that if drop-ovl is set we take a different path, which leads through pf_fragcache(). In pf_fragcache() we create a pf_frag but fail to set the address family, which leads to the panic you see when we try to insert it (and compare with pf_addr_cmp()). -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Sun Jun 7 04:01:25 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F2F5132 for ; Sun, 7 Jun 2015 04:01:25 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 504421A56 for ; Sun, 7 Jun 2015 04:01:25 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from homiemail-a51.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by hapkido.dreamhost.com (Postfix) with ESMTP id 14E699DEC3 for ; Sat, 6 Jun 2015 20:54:02 -0700 (PDT) Received: from homiemail-a51.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a51.g.dreamhost.com (Postfix) with ESMTP id E67D42E805C for ; Sat, 6 Jun 2015 20:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=menhennitt.com.au; h= message-id:date:from:mime-version:to:subject:content-type; s= menhennitt.com.au; bh=szX2uhwXKd2vxIS7VyCplwc5P2s=; b=Jk1pT+IOrt 9mX9UmabZby6b66tdWBBrLHSv+i4kXRKg2ZlObpUk1cDFwQTlsfs5sJcfj3QTB+A IvSoSrKebrpTt48geh7k/QK69Y5XVX6DKo1Nki0TGGUYgK/9459nTdGTNsnS718O 6wFbyLuZkw8mgME8avIOwM/J/i2NS7CAE= Received: from [203.2.73.75] (c122-107-214-88.mckinn3.vic.optusnet.com.au [122.107.214.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: graham@menhennitt.com.au) by homiemail-a51.g.dreamhost.com (Postfix) with ESMTPSA id F03032E8057 for ; Sat, 6 Jun 2015 20:53:54 -0700 (PDT) Message-ID: <5573C050.7070407@menhennitt.com.au> Date: Sun, 07 Jun 2015 13:53:52 +1000 From: Graham Menhennitt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: converting from ipfw to pf - not working at all Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 04:01:25 -0000 Hello FreeBSD pf list, I've been using FreeBSD and ipfw for many years on my router. I recently decided to move to pf instead of ipfw (trying to get a Chromecast to work - need UPnP via miniupnpd which only works with pf). But I can't get anything to work at all. I'm obviously doing something very basically wrong. Firstly, I'm running FreeBSD 10-stable as of a week or so ago. I do not have ALTQ compiled in my kernel, but I don't believe that I need it. The contents of /etc/pf.conf, and the output from dmesg, ifconfig, and pfctl -s all are below. I've replaced IP addresses to protect the innocent. If anybody can please help, I'd be very grateful. Thanks, Graham I have packet forwarding enabled: % sysctl net.inet.ip.forwarding net.inet6.ip6.forwarding net.inet.ip.forwarding: 1 net.inet6.ip6.forwarding: 1 % In /etc/rc.conf, I have: pf_enable="YES" pf_flags="" pf_rules="/etc/pf.conf" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_flags="" After booting, the following processes are running: % ps axww|grep pf 585 - DL 0:00.14 [pf purge] 594 - Is 0:00.01 pflogd: [priv] (pflogd) 601 - S 0:00.02 pflogd: [running] -s 116 -i pflog0 -f /var/log/pflog (pflogd) 1114 u0 S+ 0:00.00 grep pf % Pinging myself gives errors: % ping XXX.2.73.1 PING XXX.2.73.1 (XXX.2.73.1): 56 data bytes ping: sendto: Permission denied ^C --- XXX.2.73.1 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss /etc/pf.conf: # internal and external interfaces int_if = "re0" ext_if = "re1" wap_if = "re2" ipv6_if = "gif0" #egress_if = $ext_if # interface classes #insecure_ifs = "{ $ext_if, $wap_if, $ipv6_if }" #natted_ifs = "{ $int_if, $wap_if }" # TCP ports we want to allow access to from insecure interfaces tcp_services_from_insecure_ifs = "{ ssh, imaps, openvpn }" # ping requests icmp_types = "echoreq" # block incoming traffic from unroutable addresses blocked = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4, 255.255.255.255/32 }" # options set block-policy drop set loginterface egress set skip on lo0 # Scrub scrub in all # nat/rdr match out on egress inet from !(egress:network) to any nat-to (egress:0) #nat on egress from $int_if:network to any -> (egress) #nat on egress from $wap_if:network to any -> (egress) # for UPnP #rdr-anchor "miniupnpd" # filter rules block all # block traffic to/from private networks block drop in quick from $blocked to any block drop out quick from any to $blocked # allow access to certain TCP services from insecure interfaces pass in on $ext_if inet proto tcp from any to ($int_if) port $tcp_services_from_insecure_ifs flags S/SA keep state #pass in on $wap_if inet proto tcp from any to ($int_if) port $tcp_services_from_insecure_ifs flags S/SA keep state #pass in on $ipv6_if inet proto tcp from any to ($int_if) port $tcp_services_from_insecure_ifs flags S/SA keep state # allow in ping replies pass in inet proto icmp all icmp-type $icmp_types keep state # allow all traffic from internal network to internal interface pass in on $int_if from $int_if:network to any keep state pass out on $int_if from any to $int_if:network keep state # allow all traffic out via external interface pass out on $ext_if proto tcp all modulate state flags S/SA pass out on $ext_if proto { udp, icmp } all keep state # for UPnP #anchor "miniupnpd" pfctl -s all: TRANSLATION RULES: nat on egress inet from XXX.2.73.0/25 to any -> (egress) round-robin FILTER RULES: scrub in all fragment reassemble block drop all block drop in quick inet from <__automatic_523e5_0> to any block drop out quick inet from any to <__automatic_523e5_1> pass in on re1 inet proto tcp from any to (re0) port = ssh flags S/SA keep state pass in on re1 inet proto tcp from any to (re0) port = imaps flags S/SA keep state pass in on re1 inet proto tcp from any to (re0) port = openvpn flags S/SA keep state pass in inet proto icmp all icmp-type echoreq keep state pass in on re0 inet from XXX.2.73.0/25 to any flags S/SA keep state pass in on re0 inet6 from 2001:470:1f05:35d::/64 to any flags S/SA keep state pass out on re0 inet from any to XXX.2.73.0/25 flags S/SA keep state pass out on re0 inet6 from any to 2001:470:1f05:35d::/64 flags S/SA keep state pass out on re1 proto tcp all flags S/SA modulate state pass out on re1 proto udp all keep state pass out on re1 proto icmp all keep state STATES: all tcp 179.60.193.3:443 <- XXX.2.73.72:18969 CLOSED:SYN_SENT all tcp 179.60.193.3:443 <- XXX.2.73.72:27780 CLOSED:SYN_SENT all udp XXX.2.73.1:53 <- XXX.2.73.72:19784 NO_TRAFFIC:SINGLE all udp XXX.2.73.1:53 <- XXX.2.73.72:50987 NO_TRAFFIC:SINGLE all udp XXX.2.73.1:53 <- XXX.2.73.72:36252 NO_TRAFFIC:SINGLE all udp XXX.2.73.1:514 <- XXX.2.73.105:1024 NO_TRAFFIC:SINGLE all udp XXX.2.73.1:53 <- XXX.2.73.72:49728 NO_TRAFFIC:SINGLE all udp XXX.2.73.1:53 <- XXX.2.73.72:33288 NO_TRAFFIC:SINGLE all udp XXX.2.73.1:53 <- XXX.2.73.72:33594 NO_TRAFFIC:SINGLE all udp XXX.2.73.1:53 <- XXX.2.73.72:39265 NO_TRAFFIC:SINGLE INFO: Status: Enabled for 0 days 00:02:00 Debug: Urgent Interface Stats for egress IPv4 IPv6 Bytes In 0 0 Bytes Out 0 0 Packets In Passed 0 0 Blocked 0 0 Packets Out Passed 0 0 Blocked 0 0 State Table Total Rate current entries 10 searches 766 6.4/s inserts 29 0.2/s removals 19 0.2/s Counters match 744 6.2/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s TIMEOUTS: tcp.first 120s tcp.opening 30s tcp.established 86400s tcp.closing 900s tcp.finwait 45s tcp.closed 90s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 6000 states adaptive.end 12000 states src.track 0s LIMITS: states hard limit 10000 src-nodes hard limit 10000 frags hard limit 5000 table-entries hard limit 200000 TABLES: __automatic_523e5_0 __automatic_523e5_1 OS FINGERPRINTS: 710 fingerprints loaded dmesg: Copyright (c) 1992-2015 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 10.1-STABLE #8 r282466: Wed May 6 23:22:44 AEST 2015 gfm@maxwell.menhennitt.com.au:/usr/data/maxwell/obj/usr/data/FreeBSD/src_10-Stable/sys/maxwell amd64 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: AMD G-T40E Processor (1000.02-MHz K8-class CPU) Origin="AuthenticAMD" Id=0x500f20 Family=0x14 Model=0x2 Stepping=0 Features=0x178bfbff Features2=0x802209 AMD Features=0x2e500800 AMD Features2=0x35ff SVM: NP,NRIP,NAsids=8 TSC: P-state invariant, performance statistics real memory = 4815060992 (4592 MB) avail memory = 4099497984 (3909 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard random: initialized acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 450 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 4.0 on pci0 pci1: on pcib1 re0: port 0x1000-0x10ff mem 0xf7a00000-0xf7a00fff,0xf7900000-0xf7903fff irq 16 at device 0.0 on pci1 re0: Using 1 MSI-X message re0: ASPM disabled re0: Chip rev. 0x2c000000 re0: MAC rev. 0x00200000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Using defaults for TSO: 65518/35/2048 re0: Ethernet address: 00:0d:b9:35:c9:b0 pcib2: irq 17 at device 5.0 on pci0 pci2: on pcib2 re1: port 0x2000-0x20ff mem 0xf7c00000-0xf7c00fff,0xf7b00000-0xf7b03fff irq 17 at device 0.0 on pci2 re1: Using 1 MSI-X message re1: ASPM disabled re1: Chip rev. 0x2c000000 re1: MAC rev. 0x00200000 miibus1: on re1 rgephy1: PHY 1 on miibus1 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re1: Using defaults for TSO: 65518/35/2048 re1: Ethernet address: 00:0d:b9:35:c9:b1 pcib3: irq 18 at device 6.0 on pci0 pci3: on pcib3 re2: port 0x3000-0x30ff mem 0xf7e00000-0xf7e00fff,0xf7d00000-0xf7d03fff irq 18 at device 0.0 on pci3 re2: Using 1 MSI-X message re2: ASPM disabled re2: Chip rev. 0x2c000000 re2: MAC rev. 0x00200000 miibus2: on re2 rgephy2: PHY 1 on miibus2 rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re2: Using defaults for TSO: 65518/35/2048 re2: Ethernet address: 00:0d:b9:35:c9:b2 ahci0: port 0x4010-0x4017,0x4020-0x4023,0x4018-0x401f,0x4024-0x4027,0x4000-0x400f mem 0xf7f04000-0xf7f043ff irq 19 at device 17.0 on pci0 ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported ahci0: quirks=0x1b5f0 ahcich0: at channel 0 on ahci0 ahcich1: at channel 1 on ahci0 ahcich2: at channel 2 on ahci0 ahcich3: at channel 3 on ahci0 ahcich4: at channel 4 on ahci0 ahcich5: at channel 5 on ahci0 ohci0: mem 0xf7f00000-0xf7f00fff irq 18 at device 18.0 on pci0 usbus0 on ohci0 ehci0: mem 0xf7f04400-0xf7f044ff irq 17 at device 18.2 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 ohci1: mem 0xf7f01000-0xf7f01fff irq 18 at device 19.0 on pci0 usbus2 on ohci1 ehci1: mem 0xf7f04500-0xf7f045ff irq 17 at device 19.2 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci1 isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pci4: on pcib4 ohci2: mem 0xf7f02000-0xf7f02fff irq 18 at device 20.5 on pci0 usbus4 on ohci2 pcib5: at device 21.0 on pci0 pci5: on pcib5 ohci3: mem 0xf7f03000-0xf7f03fff at device 22.0 on pci0 usbus5 on ohci3 ehci2: mem 0xf7f04600-0xf7f046ff at device 22.2 on pci0 usbus6: EHCI version 1.0 usbus6 on ehci2 acpi_button0: on acpi0 orm0: at iomem 0xee800-0xeffff on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 uart0: console (115200,n,8,1) uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 Timecounters tick every 1.000 msec ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled usbus1: 480Mbps High Speed USB v2.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 480Mbps High Speed USB v2.0 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-3 ATA SATA 3.x device ada0: Serial Number 3AF607491C0800677564 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 15272MB (31277232 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA8-ACS SATA 3.x device ada1: Serial Number S3PD52ZD ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada1: Command Queueing enabled ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: quirks=0x1<4K> ada1: Previously was known as ad6 uhub4: 2 ports with 2 removable, self powered uhub0: 5 ports with 5 removable, self powered uhub2: 5 ports with 5 removable, self powered uhub5: 4 ports with 4 removable, self powered SMP: AP CPU #1 Launched! Timecounter "TSC" frequency 1000022996 Hz quality 800 Root mount waiting for: usbus6 usbus3 usbus1 Root mount waiting for: usbus6 usbus3 usbus1 uhub6: 4 ports with 4 removable, self powered uhub3: 5 ports with 5 removable, self powered uhub1: 5 ports with 5 removable, self powered ugen6.2: at usbus6 umass0: on usbus6 umass0: SCSI over Bulk-Only; quirks = 0x4001 umass0:6:0:-1: Attached to scbus6 Root mount waiting for: usbus1 da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 da0: Removable Direct Access SPC-2 SCSI device da0: Serial Number 058F63666485 da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da0: quirks=0x2 ugen1.2: at usbus1 uhub7: on usbus1 uhub7: MTT enabled uhub7: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 Root mount waiting for: usbus1 ugen1.3: at usbus1 umass1: on usbus1 umass1: SCSI over Bulk-Only; quirks = 0xc000 umass1:7:1:-1: Attached to scbus7 da1 at umass-sim1 bus 1 scbus7 target 0 lun 0 da1: Removable Direct Access SCSI device da1: Serial Number 000000009602 da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da1: quirks=0x3 da2 at umass-sim1 bus 1 scbus7 target 0 lun 1 da2: Removable Direct Access SCSI device da2: Serial Number 000000009602 da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da2: quirks=0x3 da3 at umass-sim1 bus 1 scbus7 target 0 lun 2 da3: Removable Direct Access SCSI device da3: Serial Number 000000009602 da3: 40.000MB/s transfers da3: Attempt to query device size failed: NOT READY, Medium not present da3: quirks=0x3 da4 at umass-sim1 bus 1 scbus7 target 0 lun 3 da4: Removable Direct Access SCSI device da4: Serial Number 000000009602 da4: 40.000MB/s transfers da4: Attempt to query device size failed: NOT READY, Medium not present da4: quirks=0x3 ugen1.4: at usbus1 uhub8: on usbus1 uhub8: MTT enabled Root mount waiting for: usbus1 uhub8: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ada0p2 [rw,noatime]... NLM: failed to contact remote rpcbind, stat = 3, port = 28416 NLM: failed to contact remote rpcbind, stat = 3, port = 28416 Can't start NLM - unable to contact NSM ifconfig: re0: flags=8843 metric 0 mtu 1500 options=8209b ether 00:0d:b9:35:c9:b0 inet6 YYYYYYYYYYYYYY%re0 prefixlen 64 scopeid 0x1 inet XXX.2.73.1 netmask 0xffffff80 broadcast XXX.2.73.127 inet6 YYYYYYYYYYYYYY::1 prefixlen 64 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active re1: flags=8843 metric 0 mtu 1500 options=8209b ether 00:0d:b9:35:c9:b1 inet6 YYYYYYYYY%re1 prefixlen 64 scopeid 0x2 inet YYY.YYY.YYY.YYY netmask 0xfffff000 broadcast YYY.YYY.YYY.255 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active re2: flags=8843 metric 0 mtu 1500 options=8209b ether 00:0d:b9:35:c9:b2 inet XXX.2.73.129 netmask 0xffffff80 broadcast XXX.2.73.255 inet6 YYYYYYYYYYY%re2 prefixlen 64 scopeid 0x3 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 YYYYYYYYY%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=21 From owner-freebsd-pf@FreeBSD.ORG Sun Jun 7 09:15:55 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C59882DE for ; Sun, 7 Jun 2015 09:15:55 +0000 (UTC) (envelope-from fjo-lists@ogris.de) Received: from box2.ogris.net (box2.ogris.net [IPv6:2a03:4000:6:2157::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4CC171F8F for ; Sun, 7 Jun 2015 09:15:55 +0000 (UTC) (envelope-from fjo-lists@ogris.de) Received: from [192.168.0.10] (p4FC151B1.dip0.t-ipconnect.de [79.193.81.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by box2.ogris.net (Postfix) with ESMTPSA id 64B7A1AC6; Sun, 7 Jun 2015 11:15:44 +0200 (CEST) Message-ID: <55740BC0.6080908@ogris.de> Date: Sun, 07 Jun 2015 11:15:44 +0200 From: "Felix J. Ogrs" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Graham Menhennitt , freebsd-pf@freebsd.org Subject: Re: converting from ipfw to pf - not working at all References: <5573C050.7070407@menhennitt.com.au> In-Reply-To: <5573C050.7070407@menhennitt.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 09:15:55 -0000 Hi, is ipfw still loaded and activated without any rules? --Felix On 06/07/15 05:53, Graham Menhennitt wrote: > Hello FreeBSD pf list, > > I've been using FreeBSD and ipfw for many years on my router. I recently > decided to move to pf instead of ipfw (trying to get a Chromecast to > work - need UPnP via miniupnpd which only works with pf). But I can't > get anything to work at all. I'm obviously doing something very > basically wrong. > > Firstly, I'm running FreeBSD 10-stable as of a week or so ago. I do not > have ALTQ compiled in my kernel, but I don't believe that I need it. The > contents of /etc/pf.conf, and the output from dmesg, ifconfig, and pfctl > -s all are below. I've replaced IP addresses to protect the innocent. > > If anybody can please help, I'd be very grateful. > > Thanks, > Graham > > I have packet forwarding enabled: > > % sysctl net.inet.ip.forwarding net.inet6.ip6.forwarding > net.inet.ip.forwarding: 1 > net.inet6.ip6.forwarding: 1 > % > > > In /etc/rc.conf, I have: > > pf_enable="YES" > pf_flags="" > pf_rules="/etc/pf.conf" > pflog_enable="YES" > pflog_logfile="/var/log/pflog" > pflog_flags="" > > > After booting, the following processes are running: > > % ps axww|grep pf > 585 - DL 0:00.14 [pf purge] > 594 - Is 0:00.01 pflogd: [priv] (pflogd) > 601 - S 0:00.02 pflogd: [running] -s 116 -i pflog0 -f > /var/log/pflog (pflogd) > 1114 u0 S+ 0:00.00 grep pf > % > > Pinging myself gives errors: > > % ping XXX.2.73.1 > PING XXX.2.73.1 (XXX.2.73.1): 56 data bytes > ping: sendto: Permission denied > ^C > > --- XXX.2.73.1 ping statistics --- > 3 packets transmitted, 0 packets received, 100.0% packet loss > > /etc/pf.conf: > > # internal and external interfaces > int_if = "re0" > ext_if = "re1" > wap_if = "re2" > ipv6_if = "gif0" > > #egress_if = $ext_if > > # interface classes > #insecure_ifs = "{ $ext_if, $wap_if, $ipv6_if }" > #natted_ifs = "{ $int_if, $wap_if }" > > # TCP ports we want to allow access to from insecure interfaces > tcp_services_from_insecure_ifs = "{ ssh, imaps, openvpn }" > > # ping requests > icmp_types = "echoreq" > > # block incoming traffic from unroutable addresses > blocked = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8, > 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4, > 255.255.255.255/32 }" > > # options > set block-policy drop > set loginterface egress > set skip on lo0 > > # Scrub > scrub in all > > # nat/rdr > match out on egress inet from !(egress:network) to any nat-to (egress:0) > #nat on egress from $int_if:network to any -> (egress) > #nat on egress from $wap_if:network to any -> (egress) > # for UPnP > #rdr-anchor "miniupnpd" > > # filter rules > block all > > # block traffic to/from private networks > block drop in quick from $blocked to any > block drop out quick from any to $blocked > > # allow access to certain TCP services from insecure interfaces > pass in on $ext_if inet proto tcp from any to ($int_if) port > $tcp_services_from_insecure_ifs flags S/SA keep state > #pass in on $wap_if inet proto tcp from any to ($int_if) port > $tcp_services_from_insecure_ifs flags S/SA keep state > #pass in on $ipv6_if inet proto tcp from any to ($int_if) port > $tcp_services_from_insecure_ifs flags S/SA keep state > > # allow in ping replies > pass in inet proto icmp all icmp-type $icmp_types keep state > > # allow all traffic from internal network to internal interface > pass in on $int_if from $int_if:network to any keep state > pass out on $int_if from any to $int_if:network keep state > > # allow all traffic out via external interface > pass out on $ext_if proto tcp all modulate state flags S/SA > pass out on $ext_if proto { udp, icmp } all keep state > > # for UPnP > #anchor "miniupnpd" > > > > pfctl -s all: > > TRANSLATION RULES: > nat on egress inet from XXX.2.73.0/25 to any -> (egress) round-robin > > FILTER RULES: > scrub in all fragment reassemble > block drop all > block drop in quick inet from <__automatic_523e5_0> to any > block drop out quick inet from any to <__automatic_523e5_1> > pass in on re1 inet proto tcp from any to (re0) port = ssh flags > S/SA keep state > pass in on re1 inet proto tcp from any to (re0) port = imaps flags > S/SA keep state > pass in on re1 inet proto tcp from any to (re0) port = openvpn flags > S/SA keep state > pass in inet proto icmp all icmp-type echoreq keep state > pass in on re0 inet from XXX.2.73.0/25 to any flags S/SA keep state > pass in on re0 inet6 from 2001:470:1f05:35d::/64 to any flags S/SA > keep state > pass out on re0 inet from any to XXX.2.73.0/25 flags S/SA keep state > pass out on re0 inet6 from any to 2001:470:1f05:35d::/64 flags S/SA > keep state > pass out on re1 proto tcp all flags S/SA modulate state > pass out on re1 proto udp all keep state > pass out on re1 proto icmp all keep state > > STATES: > all tcp 179.60.193.3:443 <- XXX.2.73.72:18969 CLOSED:SYN_SENT > all tcp 179.60.193.3:443 <- XXX.2.73.72:27780 CLOSED:SYN_SENT > all udp XXX.2.73.1:53 <- XXX.2.73.72:19784 NO_TRAFFIC:SINGLE > all udp XXX.2.73.1:53 <- XXX.2.73.72:50987 NO_TRAFFIC:SINGLE > all udp XXX.2.73.1:53 <- XXX.2.73.72:36252 NO_TRAFFIC:SINGLE > all udp XXX.2.73.1:514 <- XXX.2.73.105:1024 NO_TRAFFIC:SINGLE > all udp XXX.2.73.1:53 <- XXX.2.73.72:49728 NO_TRAFFIC:SINGLE > all udp XXX.2.73.1:53 <- XXX.2.73.72:33288 NO_TRAFFIC:SINGLE > all udp XXX.2.73.1:53 <- XXX.2.73.72:33594 NO_TRAFFIC:SINGLE > all udp XXX.2.73.1:53 <- XXX.2.73.72:39265 NO_TRAFFIC:SINGLE > > INFO: > Status: Enabled for 0 days 00:02:00 Debug: Urgent > > Interface Stats for egress IPv4 IPv6 > Bytes In 0 0 > Bytes Out 0 0 > Packets In > Passed 0 0 > Blocked 0 0 > Packets Out > Passed 0 0 > Blocked 0 0 > > State Table Total Rate > current entries 10 > searches 766 6.4/s > inserts 29 0.2/s > removals 19 0.2/s > Counters > match 744 6.2/s > bad-offset 0 0.0/s > fragment 0 0.0/s > short 0 0.0/s > normalize 0 0.0/s > memory 0 0.0/s > bad-timestamp 0 0.0/s > congestion 0 0.0/s > ip-option 0 0.0/s > proto-cksum 0 0.0/s > state-mismatch 0 0.0/s > state-insert 0 0.0/s > state-limit 0 0.0/s > src-limit 0 0.0/s > synproxy 0 0.0/s > > TIMEOUTS: > tcp.first 120s > tcp.opening 30s > tcp.established 86400s > tcp.closing 900s > tcp.finwait 45s > tcp.closed 90s > tcp.tsdiff 30s > udp.first 60s > udp.single 30s > udp.multiple 60s > icmp.first 20s > icmp.error 10s > other.first 60s > other.single 30s > other.multiple 60s > frag 30s > interval 10s > adaptive.start 6000 states > adaptive.end 12000 states > src.track 0s > > LIMITS: > states hard limit 10000 > src-nodes hard limit 10000 > frags hard limit 5000 > table-entries hard limit 200000 > > TABLES: > __automatic_523e5_0 > __automatic_523e5_1 > > OS FINGERPRINTS: > 710 fingerprints loaded > > > > dmesg: > > Copyright (c) 1992-2015 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 10.1-STABLE #8 r282466: Wed May 6 23:22:44 AEST 2015 > > gfm@maxwell.menhennitt.com.au:/usr/data/maxwell/obj/usr/data/FreeBSD/src_10-Stable/sys/maxwell > amd64 > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 > CPU: AMD G-T40E Processor (1000.02-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x500f20 Family=0x14 Model=0x2 Stepping=0 > > Features=0x178bfbff > Features2=0x802209 > AMD Features=0x2e500800 > AMD > Features2=0x35ff > SVM: NP,NRIP,NAsids=8 > TSC: P-state invariant, performance statistics > real memory = 4815060992 (4592 MB) > avail memory = 4099497984 (3909 MB) > Event timer "LAPIC" quality 400 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > random: initialized > acpi0: on motherboard > acpi0: Power Button (fixed) > cpu0: on acpi0 > cpu1: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > Event timer "RTC" frequency 32768 Hz quality 0 > attimer0: port 0x40-0x43 irq 0 on acpi0 > Timecounter "i8254" frequency 1193182 Hz quality 0 > Event timer "i8254" frequency 1193182 Hz quality 100 > hpet0: iomem 0xfed00000-0xfed003ff on acpi0 > Timecounter "HPET" frequency 14318180 Hz quality 950 > Event timer "HPET" frequency 14318180 Hz quality 550 > Event timer "HPET1" frequency 14318180 Hz quality 450 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 4.0 on pci0 > pci1: on pcib1 > re0: > port 0x1000-0x10ff mem 0xf7a00000-0xf7a00fff,0xf7900000-0xf7903fff > irq 16 at device 0.0 on pci1 > re0: Using 1 MSI-X message > re0: ASPM disabled > re0: Chip rev. 0x2c000000 > re0: MAC rev. 0x00200000 > miibus0: on re0 > rgephy0: PHY 1 on > miibus0 > rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re0: Using defaults for TSO: 65518/35/2048 > re0: Ethernet address: 00:0d:b9:35:c9:b0 > pcib2: irq 17 at device 5.0 on pci0 > pci2: on pcib2 > re1: > port 0x2000-0x20ff mem 0xf7c00000-0xf7c00fff,0xf7b00000-0xf7b03fff > irq 17 at device 0.0 on pci2 > re1: Using 1 MSI-X message > re1: ASPM disabled > re1: Chip rev. 0x2c000000 > re1: MAC rev. 0x00200000 > miibus1: on re1 > rgephy1: PHY 1 on > miibus1 > rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re1: Using defaults for TSO: 65518/35/2048 > re1: Ethernet address: 00:0d:b9:35:c9:b1 > pcib3: irq 18 at device 6.0 on pci0 > pci3: on pcib3 > re2: > port 0x3000-0x30ff mem 0xf7e00000-0xf7e00fff,0xf7d00000-0xf7d03fff > irq 18 at device 0.0 on pci3 > re2: Using 1 MSI-X message > re2: ASPM disabled > re2: Chip rev. 0x2c000000 > re2: MAC rev. 0x00200000 > miibus2: on re2 > rgephy2: PHY 1 on > miibus2 > rgephy2: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, > 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, > 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, > 1000baseT-FDX-flow-master, auto, auto-flow > re2: Using defaults for TSO: 65518/35/2048 > re2: Ethernet address: 00:0d:b9:35:c9:b2 > ahci0: port > 0x4010-0x4017,0x4020-0x4023,0x4018-0x401f,0x4024-0x4027,0x4000-0x400f mem > 0xf7f04000-0xf7f043ff irq 19 at device 17.0 on pci0 > ahci0: AHCI v1.20 with 6 6Gbps ports, Port Multiplier supported > ahci0: quirks=0x1b5f0 > ahcich0: at channel 0 on ahci0 > ahcich1: at channel 1 on ahci0 > ahcich2: at channel 2 on ahci0 > ahcich3: at channel 3 on ahci0 > ahcich4: at channel 4 on ahci0 > ahcich5: at channel 5 on ahci0 > ohci0: mem > 0xf7f00000-0xf7f00fff irq 18 at device 18.0 on pci0 > usbus0 on ohci0 > ehci0: mem > 0xf7f04400-0xf7f044ff irq 17 at device 18.2 on pci0 > usbus1: EHCI version 1.0 > usbus1 on ehci0 > ohci1: mem > 0xf7f01000-0xf7f01fff irq 18 at device 19.0 on pci0 > usbus2 on ohci1 > ehci1: mem > 0xf7f04500-0xf7f045ff irq 17 at device 19.2 on pci0 > usbus3: EHCI version 1.0 > usbus3 on ehci1 > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib4: at device 20.4 on pci0 > pci4: on pcib4 > ohci2: mem > 0xf7f02000-0xf7f02fff irq 18 at device 20.5 on pci0 > usbus4 on ohci2 > pcib5: at device 21.0 on pci0 > pci5: on pcib5 > ohci3: mem > 0xf7f03000-0xf7f03fff at device 22.0 on pci0 > usbus5 on ohci3 > ehci2: mem > 0xf7f04600-0xf7f046ff at device 22.2 on pci0 > usbus6: EHCI version 1.0 > usbus6 on ehci2 > acpi_button0: on acpi0 > orm0: at iomem 0xee800-0xeffff on isa0 > uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 on > isa0 > uart0: console (115200,n,8,1) > uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 > random: unblocking device. > usbus0: 12Mbps Full Speed USB v1.0 > Timecounters tick every 1.000 msec > ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to > deny, logging disabled > usbus1: 480Mbps High Speed USB v2.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 480Mbps High Speed USB v2.0 > ugen0.1: at usbus0 > uhub0: on usbus0 > ugen1.1: at usbus1 > uhub1: on usbus1 > ugen2.1: at usbus2 > uhub2: on usbus2 > ugen3.1: at usbus3 > uhub3: on usbus3 > usbus4: 12Mbps Full Speed USB v1.0 > usbus5: 12Mbps Full Speed USB v1.0 > usbus6: 480Mbps High Speed USB v2.0 > ugen4.1: at usbus4 > uhub4: on usbus4 > ugen5.1: at usbus5 > uhub5: on usbus5 > ugen6.1: at usbus6 > uhub6: on usbus6 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-3 ATA SATA 3.x device > ada0: Serial Number 3AF607491C0800677564 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 15272MB (31277232 512 byte sectors: 16H 63S/T 16383C) > ada0: Previously was known as ad4 > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > ada1: ATA8-ACS SATA 3.x device > ada1: Serial Number S3PD52ZD > ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) > ada1: Command Queueing enabled > ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada1: quirks=0x1<4K> > ada1: Previously was known as ad6 > uhub4: 2 ports with 2 removable, self powered > uhub0: 5 ports with 5 removable, self powered > uhub2: 5 ports with 5 removable, self powered > uhub5: 4 ports with 4 removable, self powered > SMP: AP CPU #1 Launched! > Timecounter "TSC" frequency 1000022996 Hz quality 800 > Root mount waiting for: usbus6 usbus3 usbus1 > Root mount waiting for: usbus6 usbus3 usbus1 > uhub6: 4 ports with 4 removable, self powered > uhub3: 5 ports with 5 removable, self powered > uhub1: 5 ports with 5 removable, self powered > ugen6.2: at usbus6 > umass0: addr 2> on usbus6 > umass0: SCSI over Bulk-Only; quirks = 0x4001 > umass0:6:0:-1: Attached to scbus6 > Root mount waiting for: usbus1 > da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 > da0: Removable Direct Access SPC-2 SCSI > device > da0: Serial Number 058F63666485 > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not present > da0: quirks=0x2 > ugen1.2: at usbus1 > uhub7: addr 2> on usbus1 > uhub7: MTT enabled > uhub7: 4 ports with 4 removable, self powered > Root mount waiting for: usbus1 > Root mount waiting for: usbus1 > ugen1.3: at usbus1 > umass1: 3> on usbus1 > umass1: SCSI over Bulk-Only; quirks = 0xc000 > umass1:7:1:-1: Attached to scbus7 > da1 at umass-sim1 bus 1 scbus7 target 0 lun 0 > da1: Removable Direct Access SCSI device > da1: Serial Number 000000009602 > da1: 40.000MB/s transfers > da1: Attempt to query device size failed: NOT READY, Medium not present > da1: quirks=0x3 > da2 at umass-sim1 bus 1 scbus7 target 0 lun 1 > da2: Removable Direct Access SCSI device > da2: Serial Number 000000009602 > da2: 40.000MB/s transfers > da2: Attempt to query device size failed: NOT READY, Medium not present > da2: quirks=0x3 > da3 at umass-sim1 bus 1 scbus7 target 0 lun 2 > da3: Removable Direct Access SCSI device > da3: Serial Number 000000009602 > da3: 40.000MB/s transfers > da3: Attempt to query device size failed: NOT READY, Medium not present > da3: quirks=0x3 > da4 at umass-sim1 bus 1 scbus7 target 0 lun 3 > da4: Removable Direct Access SCSI device > da4: Serial Number 000000009602 > da4: 40.000MB/s transfers > da4: Attempt to query device size failed: NOT READY, Medium not present > da4: quirks=0x3 > ugen1.4: at usbus1 > uhub8: addr 4> on usbus1 > uhub8: MTT enabled > Root mount waiting for: usbus1 > uhub8: 4 ports with 4 removable, self powered > Trying to mount root from ufs:/dev/ada0p2 [rw,noatime]... > NLM: failed to contact remote rpcbind, stat = 3, port = 28416 > NLM: failed to contact remote rpcbind, stat = 3, port = 28416 > Can't start NLM - unable to contact NSM > > ifconfig: > > re0: flags=8843 metric 0 mtu > 1500 > > options=8209b > ether 00:0d:b9:35:c9:b0 > inet6 YYYYYYYYYYYYYY%re0 prefixlen 64 scopeid 0x1 > inet XXX.2.73.1 netmask 0xffffff80 broadcast XXX.2.73.127 > inet6 YYYYYYYYYYYYYY::1 prefixlen 64 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > re1: flags=8843 metric 0 mtu > 1500 > > options=8209b > ether 00:0d:b9:35:c9:b1 > inet6 YYYYYYYYY%re1 prefixlen 64 scopeid 0x2 > inet YYY.YYY.YYY.YYY netmask 0xfffff000 broadcast > YYY.YYY.YYY.255 > nd6 options=21 > media: Ethernet autoselect (100baseTX ) > status: active > re2: flags=8843 metric 0 mtu > 1500 > > options=8209b > ether 00:0d:b9:35:c9:b2 > inet XXX.2.73.129 netmask 0xffffff80 broadcast XXX.2.73.255 > inet6 YYYYYYYYYYY%re2 prefixlen 64 scopeid 0x3 > nd6 options=21 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > inet6 ::1 prefixlen 128 > inet6 YYYYYYYYY%lo0 prefixlen 64 scopeid 0x4 > inet 127.0.0.1 netmask 0xff000000 > nd6 options=21 > > > _______________________________________________ > 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 owner-freebsd-pf@FreeBSD.ORG Sun Jun 7 18:31:07 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B80D539 for ; Sun, 7 Jun 2015 18:31:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 056F3103C for ; Sun, 7 Jun 2015 18:31:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t57IV6ah090508 for ; Sun, 7 Jun 2015 18:31:06 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Sun, 07 Jun 2015 18:31:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 18:31:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #8 from Danilo Egea Gondolfo --- I'm testing. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Mon Jun 8 00:50:23 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C48F48D for ; Mon, 8 Jun 2015 00:50:23 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from homiemail-a57.g.dreamhost.com (sub5.mail.dreamhost.com [208.113.200.129]) by mx1.freebsd.org (Postfix) with ESMTP id 7E771171A for ; Mon, 8 Jun 2015 00:50:22 +0000 (UTC) (envelope-from graham@menhennitt.com.au) Received: from homiemail-a57.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTP id 69F3F208063; Sun, 7 Jun 2015 17:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=menhennitt.com.au; h= message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s= menhennitt.com.au; bh=gC5p3hny/wZGbbWx0HWqCmMbts8=; b=CFCxzTCmNh 6SJHFxSqJzUNGzSqLtvPuisZx3/cGNKJIC1AcmV2LHXYKFPnfs8kYZ+4CsY7etjf 2MuZMGMz6DA31evxrb3Ps2cwYC5HdnAyOQAyuLNzHIF3oZIhZPh4PZpj6LzhweTp PGOjfYan76t9EZ7XSLCi10H85MZYm4umU= Received: from [203.2.73.75] (c122-107-214-88.mckinn3.vic.optusnet.com.au [122.107.214.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: graham@menhennitt.com.au) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTPSA id CDB20208058; Sun, 7 Jun 2015 17:50:21 -0700 (PDT) Message-ID: <5574E6CC.7080109@menhennitt.com.au> Date: Mon, 08 Jun 2015 10:50:20 +1000 From: Graham Menhennitt User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Felix J. Ogrs" , freebsd-pf@freebsd.org Subject: Re: converting from ipfw to pf - not working at all References: <5573C050.7070407@menhennitt.com.au> <55740BC0.6080908@ogris.de> In-Reply-To: <55740BC0.6080908@ogris.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 00:50:23 -0000 On 07/06/2015 19:15, Felix J. Ogrs wrote: > > is ipfw still loaded and activated without any rules? > Thanks for replying, Felix. Yes, that's exactly what the problem was. I needed to remove ipfw_nat_load="YES" from /boot/loader.conf. Now it's at least it's partially working. It doesn't seem to be NATting though. I'll work on that some more. Thanks again, Graham From owner-freebsd-pf@FreeBSD.ORG Mon Jun 8 12:07:24 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 06815751 for ; Mon, 8 Jun 2015 12:07:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4DB31A45 for ; Mon, 8 Jun 2015 12:07:23 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t58C7NUB019051 for ; Mon, 8 Jun 2015 12:07:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 198868] pf brakes tcp checksum if enabled for ue adapter Date: Mon, 08 Jun 2015 12:07:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dms@samersoff.net X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 12:07:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198868 --- Comment #2 from Dmitry Samersoff --- Any updates? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Tue Jun 9 21:14:10 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4879FE27 for ; Tue, 9 Jun 2015 21:14:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31FD11388 for ; Tue, 9 Jun 2015 21:14:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t59LEAiM020963 for ; Tue, 9 Jun 2015 21:14:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Tue, 09 Jun 2015 21:14:10 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:14:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #9 from Danilo Egea Gondolfo --- Panic again, but due a page fault now. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Tue Jun 9 21:15:59 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54EBAEED for ; Tue, 9 Jun 2015 21:15:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E4CB13B7 for ; Tue, 9 Jun 2015 21:15:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t59LFxMA032055 for ; Tue, 9 Jun 2015 21:15:59 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Tue, 09 Jun 2015 21:15:59 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:15:59 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #10 from Danilo Egea Gondolfo --- Created attachment 157587 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=157587&action=edit new core dump -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Tue Jun 9 21:20:44 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 691E3DA for ; Tue, 9 Jun 2015 21:20:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 522D81487 for ; Tue, 9 Jun 2015 21:20:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t59LKihH036244 for ; Tue, 9 Jun 2015 21:20:44 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Tue, 09 Jun 2015 21:20:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 21:20:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #11 from Kristof Provost --- Thanks for testing. I'll already commit the first fix, because it clearly fixes part of the problem you're seeing. I'll also see if I can reproduce the problem and/or figure out what's happening now. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Wed Jun 10 13:44:18 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3E722A65 for ; Wed, 10 Jun 2015 13:44:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 287761955 for ; Wed, 10 Jun 2015 13:44:18 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5ADiIrC049976 for ; Wed, 10 Jun 2015 13:44:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Wed, 10 Jun 2015 13:44:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 13:44:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #12 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Wed Jun 10 13:44:04 UTC 2015 New revision: 284222 URL: https://svnweb.freebsd.org/changeset/base/284222 Log: pf: address family must be set when creating a pf_fragment Fix a panic when handling fragmented ip4 packets with 'drop-ovl' set. In that scenario we take a different branch in pf_normalize_ip(), taking us to pf_fragcache() (rather than pf_reassemble()). In pf_fragcache() we create a pf_fragment, but do not set the address family. This leads to a panic when we try to insert that into pf_frag_tree because pf_addr_cmp(), which is used to compare the pf_fragments doesn't know what to do if the address family is not set. Simply ensure that the address family is set correctly (always AF_INET in this path). PR: 200330 Differential Revision: https://reviews.freebsd.org/D2769 Approved by: philip (mentor), gnn (mentor) Changes: head/sys/netpfil/pf/pf_norm.c -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 11 17:01:22 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98912B8B for ; Thu, 11 Jun 2015 17:01:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 830C9170E for ; Thu, 11 Jun 2015 17:01:22 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5BH1MD9078127 for ; Thu, 11 Jun 2015 17:01:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Thu, 11 Jun 2015 17:01:22 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:01:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #13 from Kristof Provost --- I've not yet been able to reproduce your second panic. As of r284260 things appear to be working for me. Is this something you can easily reproduce? Can you also explain your use case for 'fragment drop-ovl'? Looking at what it actually does (which is different from what unsuspecting users - or developers - might expect it do do), I'm very tempted to just propose removing it alltogether. -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 11 17:29:20 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93299220 for ; Thu, 11 Jun 2015 17:29:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D53B1D4E for ; Thu, 11 Jun 2015 17:29:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5BHTKb2018445 for ; Thu, 11 Jun 2015 17:29:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Thu, 11 Jun 2015 17:29:20 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:29:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #14 from Danilo Egea Gondolfo --- I was using this option in a low traffic network. The last panic happened after some hours of uptime. Nothing special. My use case for "drop-ovl" is just "testing", I don't need to use this option actually, I was just testing when I discovered the problem. Does the "fragment reassemble" option do the same work? After the last panic I've deactivated the option, I'm using it again to try to reproduce the panic. Thanks for your work! -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 11 17:50:32 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 684A18A4 for ; Thu, 11 Jun 2015 17:50:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52C841484 for ; Thu, 11 Jun 2015 17:50:32 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5BHoWZa043666 for ; Thu, 11 Jun 2015 17:50:32 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Thu, 11 Jun 2015 17:50:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:50:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #15 from Kristof Provost --- The problem I have with 'drop-ovl' (and the same applies to 'crop') is that it's a bit misleading. They don't actually reassemble the fragmented packet. That means a far lower system load, but you can't actually filter in-depth. For example, with 'scrub all fragment reassemble' you can do 'pass in inet proto icmp all icmp-type echoreq keep state', but with 'scrub all fragment drop-ovl' you'll end up just dropping a fragmented ICMP echo request. An unfragmented ICMP echo request will just get through. That goes against what I'd expect. I think you (and really all pf users) want to be using 'scrub in all fragment reassemble'. (That said, if you can break it, please keep using drop-ovl, so I can debug it ;)) -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 11 17:59:16 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A854CD2B for ; Thu, 11 Jun 2015 17:59:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 925DE1615 for ; Thu, 11 Jun 2015 17:59:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5BHxGlA050416 for ; Thu, 11 Jun 2015 17:59:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Thu, 11 Jun 2015 17:59:16 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 17:59:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #16 from Danilo Egea Gondolfo --- Yes, I was expecting that drop-ovl just drops packets with fragments that has the field "fragment offset" overlapping other fragments. My question is: Can (or should) "fragment reassemble" drop these packets too? I'll keep using it to see what happens. Thanks! -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 11 18:08:03 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 37E1E179 for ; Thu, 11 Jun 2015 18:08:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21BB3186F for ; Thu, 11 Jun 2015 18:08:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5BI832S079370 for ; Thu, 11 Jun 2015 18:08:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Thu, 11 Jun 2015 18:08:03 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 18:08:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #17 from Kristof Provost --- 'reassemble' does the right thing, in that it will fully reassemble the packet. It handles overlaps, by discarding the (parts of) packets it's already seen. Processing continues with the full packet, not on a fragment-per-fragment basis. When filtering input packets that's where it ends, because the host would have to reassemble anyway. When forwarding we also just continue with the full packet, and fragment again when transmitting. This implies that it's possible that we'll receive 5 packets of 80 bytes, but we transmit one packet of 400 bytes. (Note that this is slightly different for IPv6. There we'll always refragment to the size of the largest fragment we received so we don't break path MTU.) -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Fri Jun 12 15:43:54 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81AA6D35; Fri, 12 Jun 2015 15:43:54 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48BCDF40; Fri, 12 Jun 2015 15:43:53 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id D2FFE19E08; Fri, 12 Jun 2015 17:43:50 +0200 (CEST) Received: by vega.codepro.be (Postfix, from userid 1001) id C2D5821DA; Fri, 12 Jun 2015 17:43:50 +0200 (CEST) Date: Fri, 12 Jun 2015 17:43:50 +0200 From: Kristof Provost To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org Subject: RFC: Dropping support for scrub fragment crop/drop-ovl Message-ID: <20150612154350.GA3135@vega.codepro.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 15:43:54 -0000 Hi all, I've recently been looking at bug 200330. I broke things while adding the reassembly support for ipv6 to pf. Those issues should be fixed now, but having looked at the fragment crop/drop-ovl code, I'm starting to think support for those options should just be removed. For context: in FreeBSD's pf scrub rules can specify different ways to handle fragments. These are 'reassemble', 'crop' and 'drop-ovl'. 'reassemble' is the default, and does full reassembly before filtering the packet. 'crop' and 'drop-ovl' do not reassemble. The man page explains it better than I can: > fragment crop > The default fragment reassembly method is expensive, hence the option > to crop is provided. In this case, pf(4) will track the fragments > and cache a small range descriptor. Duplicate fragments are dropped > and overlaps are cropped. Thus data will only occur once on the wire > with ambiguities resolving to the first occurrence. Unlike the > fragment reassemble modifier, fragments are not buffered, they are > passed as soon as they are received. The fragment crop reassembly > mechanism does not yet work with NAT. > > fragment drop-ovl > This option is similar to the fragment crop modifier except that all > overlapping or duplicate fragments will be dropped, and all further > corresponding fragments will be dropped as well. Basically, these options don't reassemble. That also implies that you get the choice between having your firewall drop fragmented packets, or allowing potentially unwanted packets through because they're fragmented. That's not explicitly mentioned in the man page and I suspect many users don't realise this and are thus led to make choices with unintended consequences. All of this applies only to IPv4. I never implemented support for crop/drop-ovl in the IPv6 reassembly code. On IPv4 any scrub is 'fragment reassembly'. The OpenBSD people removed crop/drop-ovl back in 2009. Removing crop/drop-ovl would also remove around 450 lines of fairly hairy pf code. We'd just default to fragment reassemble, even if crop or drop-ovl is specified. That'd mean a behaviour change, but it'll likely actually make many firewall configurations behave better rather than break things. In summary, unless someone comes forward to say they're using crop or drop-ovl support from them is going to go away. Regards, Kristof From owner-freebsd-pf@FreeBSD.ORG Fri Jun 12 16:59:29 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F449960 for ; Fri, 12 Jun 2015 16:59:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18D113B2 for ; Fri, 12 Jun 2015 16:59:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5CGxSJw048598 for ; Fri, 12 Jun 2015 16:59:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Fri, 12 Jun 2015 16:59:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kristof@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kristof@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:59:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 Kristof Provost changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --- Comment #18 from Kristof Provost --- This issue should be fixed as of r284260, so I'm closing this bug. If you see any other problems please reopen (or submit a new bug). -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Fri Jun 12 17:24:37 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8FCA8F1; Fri, 12 Jun 2015 17:24:37 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D1F8C78; Fri, 12 Jun 2015 17:24:37 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: by ykdx132 with SMTP id x132so3887873ykd.2; Fri, 12 Jun 2015 10:24:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=czfeMivhIrE866+i04P7XL51/WXS0ZRutmTs6EUIwHs=; b=NnsluFbN+nwUCjyV9h5P5zY9CSyjWvR2BGoOyA3NgYFsDWmJmblybToVSWk+hCkV5z gLdIgqP8xC6iO80kz2W6mSMkfhZ8oywxQtPdNcnoD/jkGoCdg10yx28lIpTrDMPXysIU vf0SW+sm2zoOIfewf3WXTU8J5gbVENs6BY+ZawrToOcTmtlPdJlQfhU+xYgWW4LdxZ5m DllZPku9Y31RvZaj7jT0IHkvwj9eZpNgHuBP5mQuonlVcQk4mEA1NLFpuKtme7pNf2uE iEcr3578NnREt8yixb7H0Tj4dQr3T5nnaUCT5+zZwkRro49PrOEnusD80yDz/132j1J7 hVUw== MIME-Version: 1.0 X-Received: by 10.129.82.14 with SMTP id g14mr20352232ywb.9.1434129876032; Fri, 12 Jun 2015 10:24:36 -0700 (PDT) Sender: ermal.luci@gmail.com Received: by 10.129.123.137 with HTTP; Fri, 12 Jun 2015 10:24:35 -0700 (PDT) In-Reply-To: <20150612154350.GA3135@vega.codepro.be> References: <20150612154350.GA3135@vega.codepro.be> Date: Fri, 12 Jun 2015 13:24:35 -0400 X-Google-Sender-Auth: mE_nDyXSMQQapTkcToQlweL1Wd4 Message-ID: Subject: Re: RFC: Dropping support for scrub fragment crop/drop-ovl From: =?UTF-8?Q?Ermal_Lu=C3=A7i?= To: Kristof Provost Cc: freebsd-net , "freebsd-pf@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 17:24:37 -0000 On Fri, Jun 12, 2015 at 11:43 AM, Kristof Provost wrote: > Hi all, > > I've recently been looking at bug 200330. I broke things while adding > the reassembly support for ipv6 to pf. > > Those issues should be fixed now, but having looked at the fragment > crop/drop-ovl code, I'm starting to think support for those options > should just be removed. > Just go ahead an do that. > > For context: in FreeBSD's pf scrub rules can specify different ways to > handle fragments. These are 'reassemble', 'crop' and 'drop-ovl'. > > 'reassemble' is the default, and does full reassembly before filtering > the packet. > > 'crop' and 'drop-ovl' do not reassemble. The man page explains it better > than I can: > > > fragment crop > > The default fragment reassembly method is expensive, hence the > option > > to crop is provided. In this case, pf(4) will track the fragments > > and cache a small range descriptor. Duplicate fragments are > dropped > > and overlaps are cropped. Thus data will only occur once on the > wire > > with ambiguities resolving to the first occurrence. Unlike the > > fragment reassemble modifier, fragments are not buffered, they are > > passed as soon as they are received. The fragment crop reassembly > > mechanism does not yet work with NAT. > > > > fragment drop-ovl > > This option is similar to the fragment crop modifier except that > all > > overlapping or duplicate fragments will be dropped, and all further > > corresponding fragments will be dropped as well. > > Basically, these options don't reassemble. That also implies that you > get the choice between having your firewall drop fragmented packets, or > allowing potentially unwanted packets through because they're > fragmented. > > That's not explicitly mentioned in the man page and I suspect many > users don't realise this and are thus led to make choices with > unintended consequences. > > All of this applies only to IPv4. I never implemented support for > crop/drop-ovl in the IPv6 reassembly code. On IPv4 any scrub is > 'fragment reassembly'. > The OpenBSD people removed crop/drop-ovl back in 2009. > > Removing crop/drop-ovl would also remove around 450 lines of fairly > hairy pf code. > > We'd just default to fragment reassemble, even if crop or drop-ovl is > specified. That'd mean a behaviour change, but it'll likely actually > make many firewall configurations behave better rather than break > things. > > In summary, unless someone comes forward to say they're using crop or > drop-ovl support from them is going to go away. > > Regards, > Kristof > _______________________________________________ > 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" > -- Ermal