From owner-freebsd-pf@FreeBSD.ORG Mon Oct 21 11:06:52 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B22E9A56 for ; Mon, 21 Oct 2013 11:06:52 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F3022E22 for ; Mon, 21 Oct 2013 11:06:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9LB6q0P018735 for ; Mon, 21 Oct 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9LB6qUm018733 for freebsd-pf@FreeBSD.org; Mon, 21 Oct 2013 11:06:52 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Oct 2013 11:06:52 GMT Message-Id: <201310211106.r9LB6qUm018733@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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, 21 Oct 2013 11:06:52 -0000 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/182401 pf [pf] pf state for some IPs reaches 4294967295 suspicou o kern/182350 pf [pf] core dump with packet filter -- pf_overlad_task o kern/179392 pf [pf] [ip6] Incorrect TCP checksums in rdr return packe o kern/177810 pf [pf] traffic dropped by accepting rules is not counted o kern/177808 pf [pf] [patch] route-to rule forwarding traffic inspite o kern/176763 pf [pf] [patch] Removing pf Source entries locks kernel. o kern/176268 pf [pf] [patch] synproxy not working with route-to o kern/173659 pf [pf] PF fatal trap on 9.1 (taskq fatal trap on pf_test o bin/172888 pf [patch] authpf(8) feature enhancement o kern/172648 pf [pf] [ip6]: 'scrub reassemble tcp' breaks IPv6 packet o kern/171733 pf [pf] PF problem with modulate state in [regression] o kern/169630 pf [pf] [patch] pf fragment reassembly of padded (undersi o kern/168952 pf [pf] direction scrub rules don't work o kern/168190 pf [pf] panic when using pf and route-to (maybe: bad frag o kern/166336 pf [pf] kern.securelevel 3 +pf reload o kern/165315 pf [pf] States never cleared in PF with DEVICE_POLLING o kern/164402 pf [pf] pf crashes with a particular set of rules when fi o kern/164271 pf [pf] not working pf nat on FreeBSD 9.0 [regression] o kern/163208 pf [pf] PF state key linking mismatch o kern/160370 pf [pf] Incorrect pfctl check of pf.conf o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented 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/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st 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/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/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/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/103283 pf pfsync fails to sucessfully transfer some sessions 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 kern/87074 pf [pf] pf does not log dropped packets when max-* statef a kern/86752 pf [pf] pf does not use default timeouts when reloading c o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 57 problems total. From owner-freebsd-pf@FreeBSD.ORG Sat Oct 26 15:36:15 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2D4F2FB7 for ; Sat, 26 Oct 2013 15:36:15 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 015B223A0 for ; Sat, 26 Oct 2013 15:36:14 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id x13so8358467ief.23 for ; Sat, 26 Oct 2013 08:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LuKrOquMJiY7ShXMaoip5kRymU3RrMgduI7yAiokB0I=; b=U6fdIsPDCo78HfEKoepyI2HTWLWR7L5i9hCqQsY81LSB+EqtQzh10pqlILU3UGCE6k vhiWzNIKiDUiUyO71DwdR1ouUVEDLtiJWOWICG7r2gNcgtlLKopZYh3PI7WqINkPRwUL smnRSJpA81h2xCBP8oHKrFeSz0DbznUd2tKp1oYCmMeMFBQYvURe8gnSZewEDRnUJauz /luW2qugbUxZQQwy+XWAGADILo5xrEjpx0LMqXJUG9gr7Z60brC65I/m3uWk4mNovI7Q MQzv5h2j4uCmYFrHXTAqXYRdYzEIRX6uLVavlWBj9NDghRdYCfwzO1hn4+QIQpk6ugIx 1RSg== MIME-Version: 1.0 X-Received: by 10.42.189.132 with SMTP id de4mr8414869icb.35.1382801774367; Sat, 26 Oct 2013 08:36:14 -0700 (PDT) Received: by 10.50.2.101 with HTTP; Sat, 26 Oct 2013 08:36:14 -0700 (PDT) Date: Sat, 26 Oct 2013 08:36:14 -0700 Message-ID: Subject: PF sanity check From: Rumen Telbizov To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 26 Oct 2013 15:36:15 -0000 Hello everyone, I am in the process of building a brand new PF firewall ruleset for a site which requires that we have the ability to filter between internal vlans as well as between the Internet and the vlans. I'd like to share what I have in mind and hear what people think about it and what they have done in the past. Here are a few assumptions that I made during the process: 1. I use quick rules everywhere. Early on in the ruleset I pass everything in and out on the $ext_if no state. All of the actual rules that let the traffic in or create the state out (to internet and other vlans) are bound to the vlan interface itself. So this way, effectively I only have to worry about writing one rule which is bound to the vlan interface itself and don't care if the traffic comes from the Internet or another vlan. They are to be considered equally dangerous sources of traffic. So if a packet that is to be blocked comes in from the Internet it will pass "half way through" via the external interface on its way in and then will be blocked on its way out when it hits the vlan interface. So my questions here are: - Is this a sane setup? - Is there any security risk in me allowing the traffic pass the external interface and then dropping it on the internal interface? As a side effect it turns out that pf will always send an icmp host unreachable when I have this setup regardless of the default block policy. 2. For inter-vlan traffic it will create double states for the pass rules: one state on the way the packet coming in on the source vlan interface and another out going out of the destination interface allowing the specific traffic. The question is: Is keeping two states for one connection a bad thing or is it an acceptable practice ? Here's a reproduction of the ruleset for better understanding: # ignore the $ext_if below pass quick on $ext_if no state # vlan1 pass in quick on vlan1 # outgoing state for the internet and other vlans pass out quick on vlan1 proto tcp from to 10.1.1.1 port 22 block quick on vlan1 all # vlan2 pass in quick on vlan2 pass out quick on vlan2 proto tcp from any to 10.1.2.1 port 80 block quick on vlan2 all ... block quick all All your input is highly appreciated. Thank you very much. Regards, -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-pf@FreeBSD.ORG Sat Oct 26 23:28:57 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4EF05FA6 for ; Sat, 26 Oct 2013 23:28:57 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D7F6F297B for ; Sat, 26 Oct 2013 23:28:56 +0000 (UTC) Received: by mail-bk0-f44.google.com with SMTP id mz10so1302765bkb.3 for ; Sat, 26 Oct 2013 16:28:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=8RxS7Si9Hving9g5trCx5l5K9wswLtz0OFaAOz6F+Xw=; b=PWC77v6udqOUltd5B7MXC1HO/DNZKKH2cQkSkw1vJLPNgj4Y/yW/IEWy6rbwXdNOap G1nZIgOSM/bGOnYwAp2T1o5VBLGGhgdcxgGSc+7EMR5e5L2A6lVbWgm1FCFmon2UJk+p hY0QpEwJbmZdELvqsh/QyNEZMb+JfQF44NSziGKrRNrBonjnCyYoBpoFUT5JOomi10tb APJrtggjok+AKn65sjjR9yj/fbTPDIV9XIpAWEHSrEASD6Xlbm7x0WAAf3ld/6XIfMpc TT9fLOwCsQ6AHd+z70OQfKTvp4LPRK2EBZ9XRAcfAjRpepFjJ4rzRRDmpH89DevC8l+w 4N5A== X-Gm-Message-State: ALoCoQkLdIh6b1flHKv9zNt9BKJq21Tm0EvwKSMHrkDOkkHU47R95UTi7iI2zUlu6rAQ+cX2SBm/ X-Received: by 10.204.228.198 with SMTP id jf6mr464631bkb.41.1382830128831; Sat, 26 Oct 2013 16:28:48 -0700 (PDT) Received: from zvezda.localnet ([2a02:8108:1440:e1:2677:3ff:fe7b:7648]) by mx.google.com with ESMTPSA id pn6sm7665356bkb.14.2013.10.26.16.28.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 Oct 2013 16:28:48 -0700 (PDT) From: Kajetan Staszkiewicz To: freebsd-pf@freebsd.org Subject: Re: PF sanity check Date: Sun, 27 Oct 2013 01:28:47 +0200 User-Agent: KMail/1.13.7 (Linux/3.10.1; KDE/4.8.4; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201310270128.47766.vegeta@tuxpowered.net> X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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: Sat, 26 Oct 2013 23:28:57 -0000 Dnia sobota, 26 pa=C5=BAdziernika 2013 o 17:36:14 Rumen Telbizov napisa=C5= =82(a): > 1. I use quick rules everywhere. Early on in the ruleset I pass everything > in and out on the $ext_if no state. See below. > ... > 2. For inter-vlan traffic it will create double states for the pass rules: > one state on the way the packet coming in on the source vlan interface and > another out going out of the destination interface allowing the specific > traffic. >=20 > The question is: Is keeping two states for one connection a bad thing or = is > it an acceptable practice ? It's rather a requirement. A packet incoming on one interface creates a=20 different state than the same packet outgoing on other interface (even with= out=20 if-bound state policy). And you want further, reverse direction packets in= =20 connections to be matched to existing states and passed instead of traversi= ng=20 rule list or hitting the block rule. > Here's a reproduction of the ruleset for better understanding: >=20 > # ignore the $ext_if below If you want to fully ignore the interface, you can use "set skip" for that= =20 purpose. Although I'm not sure if NAT will work in such case, should you ne= ed=20 it. It also would be nice to set skip on the loopback interface. > pass quick on $ext_if no state This rule passes the traffic both directions, so it's probably fine. Althou= gh=20 using stateful inspection would increase security a bit. > # vlan1 > pass in quick on vlan1 # outgoing state for the internet and other vlans > pass out quick on vlan1 proto tcp from to 10.1.1.1 port 22 > block quick on vlan1 all >=20 > # vlan2 > pass in quick on vlan2 > pass out quick on vlan2 proto tcp from any to 10.1.2.1 port 80 > block quick on vlan2 all > ... >=20 > block quick all >=20 =20 =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------'