From owner-freebsd-pf@FreeBSD.ORG Mon Dec 14 11:07:01 2009 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51FB3106568D for ; Mon, 14 Dec 2009 11:07:01 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 370738FC18 for ; Mon, 14 Dec 2009 11:07:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nBEB71gJ076026 for ; Mon, 14 Dec 2009 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nBEB70Id076024 for freebsd-pf@FreeBSD.org; Mon, 14 Dec 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Dec 2009 11:07:00 GMT Message-Id: <200912141107.nBEB70Id076024@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 Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Dec 2009 11:07:01 -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/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/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/121704 pf [pf] PF mangles loopback packets o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit o kern/111220 pf [pf] repeatable hangs while manipulating pf tables s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 37 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Dec 14 14:54:50 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6639106568B for ; Mon, 14 Dec 2009 14:54:50 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4017D8FC23 for ; Mon, 14 Dec 2009 14:54:49 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-064-184-180.pools.arcor-ip.net [88.64.184.180]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LosHL-1Nzqj5176J-00gINK; Mon, 14 Dec 2009 15:54:48 +0100 Received: (qmail 32027 invoked from network); 14 Dec 2009 14:54:47 -0000 Received: from f8x64.laiers.local (192.168.4.188) by router.laiers.local with SMTP; 14 Dec 2009 14:54:47 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Mon, 14 Dec 2009 15:54:46 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE; KDE/4.3.4; amd64; ; ) References: <20091212012507.GD27716@x96.org> <20091212211128.GA28@x96.org> In-Reply-To: <20091212211128.GA28@x96.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200912141554.46525.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18gnhRIt2kGUbegIIjgMAlBJeIs2otvEUV86KG dTolbfFm7qI43+XSWx49yYR+mOp4agNJ7s+eg+NmGckGd7CmZi H5mkpu3N2HJnxZRc8I2ow== Cc: Subject: Re: IPv6, PF problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Dec 2009 14:54:50 -0000 On Saturday 12 December 2009 22:11:28 Aaron Stellman wrote: > Hello there, > > > What does "pfctl -vvsr" give you for the rule? It should include the > > number of addresses assigned to the interface in the braces - e.g. "... > > (bge0:4) ..." > > @8 pass in on bge0 proto tcp from any to (bge0:4) port = ftp flags S/SA > keep state [ Evaluations: 0 Packets: 0 Bytes: 0 > States: 0 ] [ Inserted: uid 0 pid 79900 ] > > > In addition, can you try to add separate rules for inet and inet6 - i.e. > > > > pass in on $ext_if inet proto tcp to ($ext_if) port 21 > > pass in on $ext_if inet6 proto tcp to ($ext_if) port 21 > > @8 pass in on bge0 inet proto tcp from any to (bge0:2) port = ftp flags > S/SA keep state [ Evaluations: 1 Packets: 17 Bytes: 916 > States: 1 ] [ Inserted: uid 0 pid 80198 ] > @9 pass in on bge0 inet6 proto tcp from any to (bge0:2) port = ftp flags > S/SA keep state [ Evaluations: 1 Packets: 0 Bytes: 0 > States: 0 ] [ Inserted: uid 0 pid 80198 ] > > and it passes inet6 connection with these two rules. Do you consider it > a bug? This essentially forces me to have 2 separate rules for inet and > inet6. I do consider it a bug, but I can't reproduce it here. Can you think of anything in your setup that might be special - e.g. the way you add the addresses to your interface? Are you certain that you were testing with the right rules in place (your output above shows zero rule evaluations) which is a sign that something else went wrong. Can anyone else reproduce this problem or did you see something similar? Regards, -- Max From owner-freebsd-pf@FreeBSD.ORG Mon Dec 14 16:19:43 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 059151065670 for ; Mon, 14 Dec 2009 16:19:43 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by mx1.freebsd.org (Postfix) with ESMTP id B8D228FC0C for ; Mon, 14 Dec 2009 16:19:42 +0000 (UTC) Received: by yxe1 with SMTP id 1so2910677yxe.3 for ; Mon, 14 Dec 2009 08:19:42 -0800 (PST) Received: by 10.101.204.1 with SMTP id g1mr7156331anq.169.1260807581666; Mon, 14 Dec 2009 08:19:41 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id 22sm1901882yxe.3.2009.12.14.08.19.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 08:19:40 -0800 (PST) From: "Kevin" To: Date: Mon, 14 Dec 2009 11:19:30 -0500 Message-ID: <002601ca7cd9$380cc970$a8265c50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp82TZ8XvohOjxETt6jYce1LCGD6w== Content-Language: en-us Subject: PF Transparent Bridge Firewall + CARP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Dec 2009 16:19:43 -0000 Hello, I have what I would consider not a standard firewall scenario that requires a second, redundant PF firewall. My first / main firewall is pf + transparent bridging with no internal network / ip addresses. I would like to implement a second failover firewall w/ CARP and have a pretty good idea of how I can accomplish this -- however , I would like to hear opinions / suggestions of implementing the most logical solution with CARP. I would like to implement CARP on the gateway IP address which will sit on the bridge0 interface, which bridges br01 + br02. Bridge0 will have no ip address assigned , and the gateway ip address will be assigned to carp0. Will I have to NAT traffic from carp0 > bridge0 ? will bridge0 be my ext_if in pf.conf , and int_if will be carp0? The main issue is maintaining redundancy, for me. It seems like an easy question, however Im just trying to wrap my brain around the one that doesn't cost as much overhead and is the simplest / most logical. Pertinent info : FreeBSD fw 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #4: Tue Dec 16 13:00:03 EST 2008 admin@fw:/usr/obj/usr/src/sys/FW i386 If you need additional information ,please let me know. Suggestions are welcome. Thanks, Kevin From owner-freebsd-pf@FreeBSD.ORG Mon Dec 14 16:39:57 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CC6C1065694 for ; Mon, 14 Dec 2009 16:39:57 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.211.172]) by mx1.freebsd.org (Postfix) with ESMTP id D6C0A8FC0A for ; Mon, 14 Dec 2009 16:39:56 +0000 (UTC) Received: by ywh2 with SMTP id 2so3201588ywh.27 for ; Mon, 14 Dec 2009 08:39:56 -0800 (PST) Received: by 10.101.142.22 with SMTP id u22mr5434445ann.117.1260808795991; Mon, 14 Dec 2009 08:39:55 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id 4sm1914266yxd.16.2009.12.14.08.39.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 14 Dec 2009 08:39:54 -0800 (PST) From: "Kevin" To: References: In-Reply-To: Date: Mon, 14 Dec 2009 11:39:43 -0500 Message-ID: <003001ca7cdc$0b530540$21f90fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp82TZ8XvohOjxETt6jYce1LCGD6wAAnZbA Content-Language: en-us Subject: RE: PF Transparent Bridge Firewall + CARP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Dec 2009 16:39:57 -0000 > -----Original Message----- > From: Kevin [mailto:k@kevinkevin.com] > I have what I would consider not a standard firewall scenario that > requires a second, redundant PF firewall. My first / main firewall is > pf + transparent bridging with no internal network / ip addresses. I realize that carp would require an ip address on both interfaces to work properly... this is correct, right? Could I just assign the 1 ip address / gateway on the bridge0 interface and add a carp interface to fail that over to the 2nd firewall? From owner-freebsd-pf@FreeBSD.ORG Tue Dec 15 06:47:02 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F4EA1065670 for ; Tue, 15 Dec 2009 06:47:02 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 282138FC1A for ; Tue, 15 Dec 2009 06:47:01 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so113594eyf.9 for ; Mon, 14 Dec 2009 22:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=h37XPJ0PfFfsdfNWK5w+z2MGokQLJfPgZuKyN5KOJyc=; b=Do7tontZth0PxUiCVCEb9nKfPRM443xZtKnj44UiiW8VCY+UH7QKlZ2zb+oP3vSPgx XGf93d2LLxivV5Mmfv17Czuxs8nn7o0MCVwXQyTFlbBInpjcSDZI78fJQWivrC+1OkhV m/7t22+ZoGDoderRu7iyYnD4SYpdCXh3uVtAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=DyFlImKlYvCXoo8bW0vQvQvAmE8KvlPt4HyVWP2CBhzg+XIJE4HFeHvAQVNV8GAERW g28iD5za1zyKR8ZYSP/iS3XDqHJSMGYaPzoTGh6/4H0MBIh1p+N1ZRU5/r+cKNsxCC7G 03A0Z4Uz1M5qtkKaPqJRrvrlrq2cp6QSHm0KE= MIME-Version: 1.0 Received: by 10.216.90.1 with SMTP id d1mr2625330wef.136.1260858113442; Mon, 14 Dec 2009 22:21:53 -0800 (PST) Date: Tue, 15 Dec 2009 01:21:53 -0500 Message-ID: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> From: Linda Messerschmidt To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Dec 2009 06:47:02 -0000 Hi all, I have a PF machine that is giving fits. I see a lot of weird behavior. 1) TCP connections (mainly port 80) sometimes take 3 seconds to get started instead of being virtually instant. 2) Sometimes HTTP connections just stop responding. (Client program times out waiting for response.) 3) Sometimes connections get weirdly dropped ("Connection reset by peer.") 4) Sometimes if I am ssh'd through the firewall, something will happen and my inbound packets will start getting dropped, but outbound packets still pass. For example, if I'm at the shell prompt, it is non-responsive. But if I log alongside a stuck connection and "write" to that tty, I will see it no problem. 5) States that have no right to still be there continue to pile up into the hundreds of thousands. I kind of get the feeling that all of these are related. In particular, I think 2, 3, and 4. Of all of these, the only one I can document at the moment is #3. Here is a packet capture from the public (web client) interface: 20:00:02.038067 IP 1.2.3.4.61645 > 5.6.7.8.80: S 620577087:620577087(0) win 65535 20:00:02.038328 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0) ack 620577088 win 0 20:00:02.065678 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535 20:00:02.095158 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:02.378248 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:02.746163 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:03.282122 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:04.154112 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:05.698002 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:07.913721 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:12.145438 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:12.287038 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535 20:00:20.408734 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:20.409874 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win 0 Here is a packet capture of the same session from the private (web server) interface: 20:00:02.038089 IP 1.2.3.4.61645 > 5.6.7.8.80: S 620577087:620577087(0) win 65535 20:00:02.038311 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0) ack 620577088 win 0 20:00:02.065694 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535 20:00:12.287026 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535 20:00:20.408747 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 20:00:20.409859 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win 0 So that client -> server push packet is not making it through the firewall despite numerous retransmits, until 18 seconds later when the server has already given up on it. That connection hangs around in the state table for a long time as: all tcp 5.6.7.8:80 <- 1.2.3.4:61645 CLOSED:CLOSING This despite: set timeout tcp.closed 5 set timeout tcp.closing 30 To test, I stopped connections from 1.2.3.4 to 5.6.7.8. At present, there are *zero* established connections between 1.2.3.4 and 5.6.7.8. None. But: $ sudo pfctl -s state | fgrep 1.2.3.4: | fgrep :80 | wc 2243 13458 160932 A few minutes later I broke this down by connection status: 1222 CLOSED:CLOSING 556 ESTABLISHED:ESTABLISHED 15 FIN_WAIT_2:CLOSING 27 SYN_SENT:FIN_WAIT_2 That doesn't add up to 2243, so they *are* slowly dying off. I did some poking around, and the CLOSED:CLOSING ones expire after fifteen minutes, which is the timeout for tcp.opening. Um, OK. The 556 ESTABLISHED:ESTABLISHED states appear content to persist until they age off too, even though those connections are long gone. As far as the "3 second" thing, I noticed somebody here recently had a similar problem and made it go away by upping their states and dropping their timeouts. Well, he dropped his timeouts to where ours are, and we're at: set limit states 2000000 We are definitely not out of states; we're seeing these problems right now and due to my playing around with the tcp.established timeout, we're at 66412 states right now. (Ordinarily it hovers around 350,000.) The machine is a dual-core Core 2 6320 with 2GB of RAM and nothing to but load balance this traffic. It shows as 95% idle all day. So sometimes pf loses packets related to connections that are still around, and sometimes it thinks connections are still around long after the packets are gone. I would be really, really grateful for any suggestions or help. I am completely lost here and at my wits' end! I've included my pf.conf below. -------------------------------------------------------------------------------------------- set limit states 2000000 set timeout tcp.established 86400 set timeout tcp.closed 5 set timeout tcp.closing 30 ExtIf = "em0" IntIf = "em1" table { 127.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } table { ... } table { ... } table { ... } scrub ## Block Reserved Addresses block log quick on $ExtIf from to any block log quick on $ExtIf from any to ## Block our own Addresses block in log quick on $ExtIf inet from to any ## Anti-DDOS table persist block quick from to any block quick from any to ## Block HTTP traffic to DNS servers block quick inet proto tcp from any to port 80 ## Weird DNS people added 2009-06-18 block drop log quick proto 255 table { 61.220.4.0/24 } block drop in quick proto { udp, tcp } from to any port 53 ## Load Balancing pass in on $ExtIf route-to { ($IntIf 3.4.5.6), ($IntIf 3.4.5.7), ($IntIf 3.4.5.8), ($IntIf 3.4.5.9) } round-robin proto tcp from any to port 80 From owner-freebsd-pf@FreeBSD.ORG Tue Dec 15 09:56:19 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B9941065692 for ; Tue, 15 Dec 2009 09:56:19 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-gx0-f218.google.com (mail-gx0-f218.google.com [209.85.217.218]) by mx1.freebsd.org (Postfix) with ESMTP id E54368FC21 for ; Tue, 15 Dec 2009 09:56:18 +0000 (UTC) Received: by gxk10 with SMTP id 10so3902038gxk.3 for ; Tue, 15 Dec 2009 01:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=M8iTWghm/t7IBZpUtRqwIGg2MuY6LU8XaseVKfS37c8=; b=YCqM6E6yOCmQ9ANknt3qDsvI1Q+cy1Xj+vIWbC7ZRWZhFW7/lwimW7vk5XmioprFmT WmL5qyXdI6kUCyufB7lWKWnz7R32/PfXSncq+2Ev2h8i8GllYY2t6VsfYtqLubUG3/KS 0bYhQaqCMxtI9MzITA9Zw7iyXGANTVEbmbWn0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=mU3JzjMoCMRBO7UiPSatrzPLctiRHOou5UqSnPea8p7fqnPU+E0hjrj85lKyYFmOl4 8n7A22SaNKcEt8g0U9a3BcOZR3Gx4d5nJAz9dwTHQhZI8a8vMDgZUpJ+IFJKqvRYzswP rHuD09t8CMNyDpv3k+u6Te9wadd3qiHPfYhao= MIME-Version: 1.0 Sender: ermal.luci@gmail.com Received: by 10.150.105.27 with SMTP id d27mr9168222ybc.195.1260870978088; Tue, 15 Dec 2009 01:56:18 -0800 (PST) In-Reply-To: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Date: Tue, 15 Dec 2009 10:55:58 +0100 X-Google-Sender-Auth: 16cee2154408c1c9 Message-ID: <9a542da30912150155k22c5187bla981e6c394d1d541@mail.gmail.com> To: Linda Messerschmidt Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Dec 2009 09:56:19 -0000 On Tue, Dec 15, 2009 at 7:21 AM, Linda Messerschmidt < linda.messerschmidt@gmail.com> wrote: > Hi all, > > I have a PF machine that is giving fits. I see a lot of weird behavior. > > 1) TCP connections (mainly port 80) sometimes take 3 seconds to get > started instead of being virtually instant. > 2) Sometimes HTTP connections just stop responding. (Client program > times out waiting for response.) > 3) Sometimes connections get weirdly dropped ("Connection reset by peer.") > 4) Sometimes if I am ssh'd through the firewall, something will happen > and my inbound packets will start getting dropped, but outbound > packets still pass. For example, if I'm at the shell prompt, it is > non-responsive. But if I log alongside a stuck connection and "write" > to that tty, I will see it no problem. > 5) States that have no right to still be there continue to pile up > into the hundreds of thousands. > > I kind of get the feeling that all of these are related. In > particular, I think 2, 3, and 4. > > Of all of these, the only one I can document at the moment is #3. > > Here is a packet capture from the public (web client) interface: > > 20:00:02.038067 IP 1.2.3.4.61645 > 5.6.7.8.80: S > 620577087:620577087(0) win 65535 9,sackOK,timestamp 953726452 0> > 20:00:02.038328 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0) > ack 620577088 win 0 > 20:00:02.065678 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535 > 20:00:02.095158 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:02.378248 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:02.746163 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:03.282122 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:04.154112 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:05.698002 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:07.913721 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:12.145438 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:12.287038 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535 > 20:00:20.408734 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:20.409874 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win 0 > > Here is a packet capture of the same session from the private (web > server) interface: > > 20:00:02.038089 IP 1.2.3.4.61645 > 5.6.7.8.80: S > 620577087:620577087(0) win 65535 9,sackOK,timestamp 953726452 0> > 20:00:02.038311 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0) > ack 620577088 win 0 > 20:00:02.065694 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535 > 20:00:12.287026 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535 > 20:00:20.408747 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:20.409859 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win 0 > > So that client -> server push packet is not making it through the > firewall despite numerous retransmits, until 18 seconds later when the > server has already given up on it. > > That connection hangs around in the state table for a long time as: > > all tcp 5.6.7.8:80 <- 1.2.3.4:61645 CLOSED:CLOSING > > This despite: > > set timeout tcp.closed 5 > set timeout tcp.closing 30 > > To test, I stopped connections from 1.2.3.4 to 5.6.7.8. At present, > there are *zero* established connections between 1.2.3.4 and 5.6.7.8. > None. But: > > $ sudo pfctl -s state | fgrep 1.2.3.4: | fgrep :80 | wc > 2243 13458 160932 > > A few minutes later I broke this down by connection status: > 1222 CLOSED:CLOSING > 556 ESTABLISHED:ESTABLISHED > 15 FIN_WAIT_2:CLOSING > 27 SYN_SENT:FIN_WAIT_2 > > That doesn't add up to 2243, so they *are* slowly dying off. I did > some poking around, and the CLOSED:CLOSING ones expire after fifteen > minutes, which is the timeout for tcp.opening. Um, OK. > > The 556 ESTABLISHED:ESTABLISHED states appear content to persist until > they age off too, even though those connections are long gone. > > As far as the "3 second" thing, I noticed somebody here recently had a > similar problem and made it go away by upping their states and > dropping their timeouts. Well, he dropped his timeouts to where ours > are, and we're at: > > set limit states 2000000 > > We are definitely not out of states; we're seeing these problems right > now and due to my playing around with the tcp.established timeout, > we're at 66412 states right now. (Ordinarily it hovers around > 350,000.) The machine is a dual-core Core 2 6320 with 2GB of RAM and > nothing to but load balance this traffic. It shows as 95% idle all > day. > > So sometimes pf loses packets related to connections that are still > around, and sometimes it thinks connections are still around long > after the packets are gone. > > I would be really, really grateful for any suggestions or help. I am > completely lost here and at my wits' end! > > I've included my pf.conf below. > > > > -------------------------------------------------------------------------------------------- > > set limit states 2000000 > set timeout tcp.established 86400 > set timeout tcp.closed 5 > set timeout tcp.closing 30 > > ExtIf = "em0" > IntIf = "em1" > > table { 127.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, > 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } > table { ... } > table { ... } > table { ... } > > scrub > > ## Block Reserved Addresses > block log quick on $ExtIf from to any > block log quick on $ExtIf from any to > > ## Block our own Addresses > block in log quick on $ExtIf inet from to any > > ## Anti-DDOS > table persist > block quick from to any > block quick from any to > > ## Block HTTP traffic to DNS servers > block quick inet proto tcp from any to port 80 > > ## Weird DNS people added 2009-06-18 > block drop log quick proto 255 > table { 61.220.4.0/24 } > block drop in quick proto { udp, tcp } from to any port > 53 > > ## Load Balancing > pass in on $ExtIf route-to { ($IntIf 3.4.5.6), ($IntIf 3.4.5.7), > ($IntIf 3.4.5.8), ($IntIf 3.4.5.9) } round-robin proto tcp from any to > port 80 > > Try enabling sticky connections here. -- Ermal From owner-freebsd-pf@FreeBSD.ORG Tue Dec 15 15:01:49 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AE811065693 for ; Tue, 15 Dec 2009 15:01:49 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id CA9008FC1E for ; Tue, 15 Dec 2009 15:01:48 +0000 (UTC) Received: by ewy5 with SMTP id 5so4647359ewy.14 for ; Tue, 15 Dec 2009 07:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8fI6YIwb014lwuB+SgOH75n9AeIVA/uXhVKxrVkUvWw=; b=AKatx65ChoWaeoMCLI+IEwAQhGW9dY06kXNpfTpXmE51mTckYXu4WGLNttcMqnduEs ie7L6BmiCYWM5L+165mZf2xQnm7OC8qTh9nx9KIFOShYBD7BR8jCZqFlc+HMmmPsm99z MYG8NhUiMluI8qfnNfCZV0Q1a5/SC4M1WehX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PrfwKOdDJS9kqECJnvSSdZrmSZcApW801AikE7fi/qYOGg4fl6uujxqQT99WSe4lJT FL/QVdFW52MxZ0cvQXQBAnzp07+k3GVRQPqTD5MYllklIk5xxPPcqKHkus250QOAqEBL rZP7eibhVF6KNBRVnyvBU5Ng9vuvwdfgHkYgI= MIME-Version: 1.0 Received: by 10.216.87.134 with SMTP id y6mr520222wee.20.1260889307598; Tue, 15 Dec 2009 07:01:47 -0800 (PST) In-Reply-To: <9a542da30912150155k22c5187bla981e6c394d1d541@mail.gmail.com> References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> <9a542da30912150155k22c5187bla981e6c394d1d541@mail.gmail.com> Date: Tue, 15 Dec 2009 10:01:47 -0500 Message-ID: <237c27100912150701w9f3dfb3xf9967ed20b03c556@mail.gmail.com> From: Linda Messerschmidt To: =?ISO-8859-1?Q?Ermal_Lu=E7i?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Dec 2009 15:01:49 -0000 On Tue, Dec 15, 2009 at 4:55 AM, Ermal Lu=E7i wrote: > Try enabling sticky connections here. As a practical matter we don't care if two connections from the same client go to the same server or not. Is there some reason to suspect that this option would alter the behavior of single connections, like the problem we're having? Although even in that case, all the servers on the same interface so if it were a problem with load balancing, I would expect to see the stray packets addressed to the wrong MAC address, not to have them disappear completely. Thanks! From owner-freebsd-pf@FreeBSD.ORG Tue Dec 15 16:08:52 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B31E4106566C for ; Tue, 15 Dec 2009 16:08:52 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3831A8FC08 for ; Tue, 15 Dec 2009 16:08:51 +0000 (UTC) Received: by bwz5 with SMTP id 5so21747bwz.3 for ; Tue, 15 Dec 2009 08:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=2DLreERd2ywIBEQ42DxFblaeJRnrL5jG5HxJxLOGUqE=; b=HbygPRy0qCq/3ydkh7fWBYSxnjnDKoMG8tB4W7wbYGrbe5my2yBw0WeKsQxKikJN64 oYF2pwuni1wNDl0xbDuksBLSSz7BbI0AJIeFHjrfhoLfiw4suxlSAO+nbBaSViElKNw3 TetTaOg63JDZmpyBT7Ckm6gkMLKEcT7dfn+I0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=sRXwfT2gYSHGaw7p1k4YcnG5SIyd8aJEZ9TuCktQnAhyBX4LraFSKOWyDTnWFBI/ZT Neo/+q6aXk5RNGyl3qwysJxpQzv5vVUPJ+rgYLAKWiwKJUpj4QhtIhHvNvvg1Qk+LBCF Me/uc1wMxHWbshhFbSAtHTCYBB/VCEsBLfQls= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.204.27.21 with SMTP id g21mr3808134bkc.133.1260893329142; Tue, 15 Dec 2009 08:08:49 -0800 (PST) In-Reply-To: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> Date: Tue, 15 Dec 2009 16:08:49 +0000 X-Google-Sender-Auth: 006225bb44436a05 Message-ID: <7731938b0912150808y5cfa7cbs3bb31b80f222159c@mail.gmail.com> From: Peter Maxwell To: Linda Messerschmidt , freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Dec 2009 16:08:52 -0000 Hi Linda, I'm pretty sure you can run tcpdump against a packet capture from the pflog interface on the pf box; that will include fields like block/pass and rule number for each packet filtered. That way you at least know what rule is dropping/passing your packets. And if my memory serves me right, pf uses a default pass rule - if it were me I'd check that the SYN-ACK from the webserver isn't creating a second state table entry using the default pass rule, or something equally as annoying. It is also possible I'm completely wrong, as it's been a while since I've actually messed about with pf in any meaningful way. However one thing that I would strongly suggest is using proper packet filter design: either decide upon a default deny then pass what you want, or decide on a default pass and only deny what is bad. This methodology applies to any firewall whether pf, checkpoint, cisco, etc. If you're having to use the "quick" keyword, you've probably* done something wrong. The default deny approach is usually preferable, so you should have one block all rule at the top of the ruleset then all other rules should be pass rules. Best wishes, Peter * there are some situations where you may have to use quick, but not particularly often. 2009/12/15 Linda Messerschmidt : > Hi all, > > I have a PF machine that is giving fits. =A0I see a lot of weird behavior= . > > 1) TCP connections (mainly port 80) sometimes take 3 seconds to get > started instead of being virtually instant. > 2) Sometimes HTTP connections just stop responding. =A0(Client program > times out waiting for response.) > 3) Sometimes connections get weirdly dropped ("Connection reset by peer."= ) > 4) Sometimes if I am ssh'd through the firewall, something will happen > and my inbound packets will start getting dropped, but outbound > packets still pass. =A0For example, if I'm at the shell prompt, it is > non-responsive. =A0But if I log alongside a stuck connection and "write" > to that tty, I will see it no problem. > 5) States that have no right to still be there continue to pile up > into the hundreds of thousands. > > I kind of get the feeling that all of these are related. =A0In > particular, I think 2, 3, and 4. > > Of all of these, the only one I can document at the moment is #3. > > Here is a packet capture from the public (web client) interface: > > 20:00:02.038067 IP 1.2.3.4.61645 > 5.6.7.8.80: S > 620577087:620577087(0) win 65535 9,sackOK,timestamp 953726452 0> > 20:00:02.038328 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0) > ack 620577088 win 0 > 20:00:02.065678 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535 > 20:00:02.095158 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:02.378248 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:02.746163 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:03.282122 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:04.154112 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:05.698002 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:07.913721 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:12.145438 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:12.287038 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535 > 20:00:20.408734 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:20.409874 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win= 0 > > Here is a packet capture of the same session from the private (web > server) interface: > > 20:00:02.038089 IP 1.2.3.4.61645 > 5.6.7.8.80: S > 620577087:620577087(0) win 65535 9,sackOK,timestamp 953726452 0> > 20:00:02.038311 IP 5.6.7.8.80 > 1.2.3.4.61645: S 40565958:40565958(0) > ack 620577088 win 0 > 20:00:02.065694 IP 1.2.3.4.61645 > 5.6.7.8.80: . ack 1 win 65535 > 20:00:12.287026 IP 5.6.7.8.80 > 1.2.3.4.61645: F 1:1(0) ack 1 win 65535 > 20:00:20.408747 IP 1.2.3.4.61645 > 5.6.7.8.80: P 1:80(79) ack 1 win 65535 > 20:00:20.409859 IP 5.6.7.8.80 > 1.2.3.4.61645: R 40565959:40565959(0) win= 0 > > So that client -> server push packet is not making it through the > firewall despite numerous retransmits, until 18 seconds later when the > server has already given up on it. > > That connection hangs around in the state table for a long time as: > > all tcp 5.6.7.8:80 <- 1.2.3.4:61645 =A0 =A0 =A0 CLOSED:CLOSING > > This despite: > > set timeout tcp.closed 5 > set timeout tcp.closing 30 > > To test, I stopped connections from 1.2.3.4 to 5.6.7.8. =A0At present, > there are *zero* established connections between 1.2.3.4 and 5.6.7.8. > None. =A0But: > > $ sudo pfctl -s state | fgrep 1.2.3.4: | fgrep :80 | wc > =A0 =A02243 =A0 13458 =A0160932 > > A few minutes later I broke this down by connection status: > 1222 CLOSED:CLOSING > =A0556 ESTABLISHED:ESTABLISHED > =A015 FIN_WAIT_2:CLOSING > =A027 SYN_SENT:FIN_WAIT_2 > > That doesn't add up to 2243, so they *are* slowly dying off. =A0I did > some poking around, and the CLOSED:CLOSING ones expire after fifteen > minutes, which is the timeout for tcp.opening. =A0Um, OK. > > The 556 ESTABLISHED:ESTABLISHED states appear content to persist until > they age off too, even though those connections are long gone. > > As far as the "3 second" thing, I noticed somebody here recently had a > similar problem and made it go away by upping their states and > dropping their timeouts. =A0Well, he dropped his timeouts to where ours > are, and we're at: > > set limit states 2000000 > > We are definitely not out of states; we're seeing these problems right > now and due to my playing around with the tcp.established timeout, > we're at 66412 states right now. =A0(Ordinarily it hovers around > 350,000.) =A0The machine is a dual-core Core 2 6320 with 2GB of RAM and > nothing to but load balance this traffic. =A0It shows as 95% idle all > day. > > So sometimes pf loses packets related to connections that are still > around, and sometimes it thinks connections are still around long > after the packets are gone. > > I would be really, really grateful for any suggestions or help. =A0I am > completely lost here and at my wits' end! > > I've included my pf.conf below. > > > -------------------------------------------------------------------------= ------------------- > > set limit states 2000000 > set timeout tcp.established 86400 > set timeout tcp.closed 5 > set timeout tcp.closing 30 > > ExtIf =3D "em0" > IntIf =3D "em1" > > table { 127.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, > 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 } > table { ... } > table { ... } > table { ... } > > scrub > > ## =A0Block Reserved Addresses > block log quick on $ExtIf from to any > block log quick on $ExtIf from any to > > ## =A0Block our own Addresses > block in log quick on $ExtIf inet from to any > > ## =A0Anti-DDOS > table persist > block quick from to any > block quick from any to > > ## =A0Block HTTP traffic to DNS servers > block quick inet proto tcp from any to port 80 > > ## =A0Weird DNS people added 2009-06-18 > block drop log quick proto 255 > table { 61.220.4.0/24 } > block drop in quick proto { udp, tcp } from to any port= 53 > > ## Load Balancing > pass in on $ExtIf route-to { ($IntIf 3.4.5.6), ($IntIf 3.4.5.7), > ($IntIf 3.4.5.8), ($IntIf 3.4.5.9) } round-robin proto tcp from any to > port 80 > _______________________________________________ > 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 Tue Dec 15 19:14:10 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D318010656AA for ; Tue, 15 Dec 2009 19:14:10 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 676208FC08 for ; Tue, 15 Dec 2009 19:14:09 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so66542eyf.9 for ; Tue, 15 Dec 2009 11:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5hJVyV1SesbySUFROUnLSi/Lzz/4k65ei0yv29Ra6YA=; b=b7yE0nXslBdxgOzzF6wBdnLcwhOTrgtRu0eEHCaEUbp3ro3GkjkKMA5Nv0YWK9h3Of E19eLBAZdmtW/CI1CMB9xNwKWdlJBChuRgJ9pE4SaexJJK1DatWn5ibEQm5/eUJoVHmP pWpH93AWlqHRY2jPuE+WwXkU9QM2aImClhIy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=e3heNWlcaBibE/7WiafOq619TMyZQay8EmI2EDjquq/VeFztB59u27tMJt1cfBjXxc 9XHzopXD23N3gABC3GBMbxX49IOWQsdvYZPzCtHmwgdR4HCaTGeHEJzffO3hLwXkEp+j 6VRcQUib5scp643/8NTh4O6WWuOgWBDaD4zDA= MIME-Version: 1.0 Received: by 10.216.90.11 with SMTP id d11mr483073wef.187.1260904448965; Tue, 15 Dec 2009 11:14:08 -0800 (PST) In-Reply-To: <7731938b0912150808y5cfa7cbs3bb31b80f222159c@mail.gmail.com> References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> <7731938b0912150808y5cfa7cbs3bb31b80f222159c@mail.gmail.com> Date: Tue, 15 Dec 2009 14:14:08 -0500 Message-ID: <237c27100912151114w6912dd63l80523d02831b2588@mail.gmail.com> From: Linda Messerschmidt To: Peter Maxwell Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org Subject: Re: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Dec 2009 19:14:10 -0000 On Tue, Dec 15, 2009 at 11:08 AM, Peter Maxwell wrote: > I'm pretty sure you can run tcpdump against a packet capture from the > pflog interface on the pf box; that will include fields like > block/pass and rule number for each packet filtered. I have done that with "log" on all block rules. The packets shown as missing are *not* present in the dump when I do, so as far as I can tell they are not being dropped by a filter rule. Which makes sense, since none of the few block rules we have would touch packets in the middle of an established connection that was permitted. For comparison, endless streams of packets from those DNS guys we block *are* present in the tcpdump output, exactly as you describe, so I know pflog is working. So it really seems like something wrong in the internals of pf. I just don't know how to pursue it further. > However one thing that I would strongly suggest is using proper packet > filter design: either decide upon a default deny then pass what you > want, or decide on a default pass and only deny what is bad. We are doing the latter; default pass and denying only what is bad. This isn't even really a firewall, it's for load balancing web connections. We just threw a couple of block rules in there because it was a good place to stop a particular attack. There are other "default deny" firewalls on other machines that handle all the traffic that isn't getting diverted by the load balance rule. > If you're having to use the "quick" keyword, you've probably* > done something wrong. Since we are using load balancing, the "pass" rule that wouldn't pass all the traffic we've just gone to the trouble to block would be outrageously complex. Hence, quick. If a case can be made that the use of "quick" is causing our packets to disappear, we'd probably be willing to tackle trying to restructure the rules. Thanks! From owner-freebsd-pf@FreeBSD.ORG Tue Dec 15 20:33:26 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A988D1065670 for ; Tue, 15 Dec 2009 20:33:26 +0000 (UTC) (envelope-from allicient3141@googlemail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 3153A8FC1E for ; Tue, 15 Dec 2009 20:33:25 +0000 (UTC) Received: by bwz5 with SMTP id 5so267828bwz.3 for ; Tue, 15 Dec 2009 12:33:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ZsP8yElGDARq/b10Ks/b/HExPNcM4CBK3chhwNcWtxc=; b=wSQ7Xpt9ccIu54/2yKXLDzCfva320MJxlaQFWPNgJH5IE9SClD6qGBKEyWr+YLT6lb NfIrK9vG49PeJ23Wa99+OWc2kfMW4jEkJNU2OgsfCaHPlNPzF24P5z4ret0sZmoO8ztX 5LBKFTqa0ccx46XEsh8vSH5pepVZfOa0As+6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=L+GlZxGKFEti27D+qIBhv2MogoIZmQdH+ylO47dZ/kxOviEiAebBFvpOtgkkH71gTj us+oI0252yeGJXgMtuXkZDqC1LKNmIUexmby+F6Js6Rp8NQP/hIGM1cPwIyZpsY0zGds ElYX/8xUjBnmxyKIVAGgPWA41EUznR8/8Avak= MIME-Version: 1.0 Sender: allicient3141@googlemail.com Received: by 10.204.13.215 with SMTP id d23mr30638bka.18.1260909204762; Tue, 15 Dec 2009 12:33:24 -0800 (PST) In-Reply-To: <237c27100912151114w6912dd63l80523d02831b2588@mail.gmail.com> References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> <7731938b0912150808y5cfa7cbs3bb31b80f222159c@mail.gmail.com> <237c27100912151114w6912dd63l80523d02831b2588@mail.gmail.com> Date: Tue, 15 Dec 2009 20:33:24 +0000 X-Google-Sender-Auth: 70aea519e07f3259 Message-ID: <7731938b0912151233u6d6a4ca6pc430ca0db01c73c0@mail.gmail.com> From: Peter Maxwell To: Linda Messerschmidt , freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Dec 2009 20:33:26 -0000 2009/12/15 Linda Messerschmidt : > On Tue, Dec 15, 2009 at 11:08 AM, Peter Maxwell w= rote: >> I'm pretty sure you can run tcpdump against a packet capture from the >> pflog interface on the pf box; that will include fields like >> block/pass and rule number for each packet filtered. > > I have done that with "log" on all block rules. =A0The packets shown as > missing are *not* present in the dump when I do, so as far as I can > tell they are not being dropped by a filter rule. =A0Which makes sense, > since none of the few block rules we have would touch packets in the > middle of an established connection that was permitted. Although it's not likely to be causing the problem (the default "flags" on tcp rules are S/SA, which should exclude this possibility), I'd check that the implicit pass rule isn't getting hit by the web traffic. Add in an explicit "pass all" rule at the start and set the log keyword on it. Make sure *none* of the web traffic is hitting this rule. > > For comparison, endless streams of packets from those DNS guys we > block *are* present in the tcpdump output, exactly as you describe, so > I know pflog is working. > > So it really seems like something wrong in the internals of pf. =A0I > just don't know how to pursue it further. If the box isn't too loaded, you may try using "log (all)" on the pass rules (so that ALL packets are logged, not just the initial SYN) - that way at least you'd find out which rules those data packets are hitting, which would likely pin down the problem quite a bit.. those missing packets must have went somewhere ;-) If it were me, that would be my preferable option if it was available. Barring that, I'd suggest simplifying your setup as much as possible - is there too much traffic to remove the "route-to" and try it against a single webserver? If it's not possible, you could try setting up a simple TCP service on internal hosts and get something that works, then build up (ECHO or TIME are not bad for this). I'd also suggest removing the "scrub" directive until you have it working properly. Is the "state-policy" floating or if-bound? Does the problem affect other services in a similar manner, can you replicate the exact same problem with the web servers with sshd, for example? What's annoying me is that I'm fairly sure I've seen this problem before, but for the life of me I can't remember what caused it :-( > >> However one thing that I would strongly suggest is using proper packet >> filter design: either decide upon a default deny then pass what you >> want, or decide on a default pass and only deny what is bad. > > We are doing the latter; default pass and denying only what is bad. > This isn't even really a firewall, it's for load balancing web > connections. =A0We just threw a couple of block rules in there because > it was a good place to stop a particular attack. =A0There are other > "default deny" firewalls on other machines that handle all the traffic > that isn't getting diverted by the load balance rule. > >> If you're having to use the "quick" keyword, you've probably* >> done something wrong. > > Since we are using load balancing, the "pass" rule that wouldn't pass > all the traffic we've just gone to the trouble to block would be > outrageously complex. =A0Hence, quick. > pf uses the last rule in the ruleset that matches for a given packet, so for a first instance setup I'd suggest putting an explicit "pass all" as the first rule, then any pass rules that do load-balancing and the like, then a list of block rules. It makes it a lot easier to read and debug. Then once it's working as you want, you can move the block rules up to the top and add in the "quick" keyword for performance purposes. > If a case can be made that the use of "quick" is causing our packets > to disappear, we'd probably be willing to tackle trying to restructure > the rules. > > Thanks! > From owner-freebsd-pf@FreeBSD.ORG Tue Dec 15 21:37:16 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EC43106566B for ; Tue, 15 Dec 2009 21:37:16 +0000 (UTC) (envelope-from linda.messerschmidt@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id BFAB18FC0A for ; Tue, 15 Dec 2009 21:37:15 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so98481eyf.9 for ; Tue, 15 Dec 2009 13:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lu/aOtEWPXagbSddvy59VohG7lYgdjoHsa6W95eat5c=; b=nUgITUb16pbGfba6YI062jTmL9yI4g0wYHXMLwjqXVDhs8eG6mVY4gTDOX1nIa2Qls JXUGbtYL9I4vMxQdylhaucgD79HfMiy6y35oqEwBX6OkD+vu0ph5Sx5cPaDZIHYOS59n FIIuut/mZwop+SEDJGSIIbwziFHKLyDi2Y4vU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aey6WiClebYo5eFolWZe+HGGZ0e+78KIulihYvGJXlTrzDIfiRMOuODulx22iENWxP JxX8CX+87B4qPoFpWc9A0oD/aEGFu4P7I+L20Wrf1mr6o1cHz6bS1TzY/uICMjt0zyco QMgo83P4Xb3BxSIGz9DV8Kw5ZzpaB4FZLxZvM= MIME-Version: 1.0 Received: by 10.216.87.68 with SMTP id x46mr55752wee.2.1260913034577; Tue, 15 Dec 2009 13:37:14 -0800 (PST) In-Reply-To: <7731938b0912151233u6d6a4ca6pc430ca0db01c73c0@mail.gmail.com> References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> <7731938b0912150808y5cfa7cbs3bb31b80f222159c@mail.gmail.com> <237c27100912151114w6912dd63l80523d02831b2588@mail.gmail.com> <7731938b0912151233u6d6a4ca6pc430ca0db01c73c0@mail.gmail.com> Date: Tue, 15 Dec 2009 16:37:14 -0500 Message-ID: <237c27100912151337y27cdea3ajda0b3be7987968f3@mail.gmail.com> From: Linda Messerschmidt To: Peter Maxwell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 15 Dec 2009 21:37:16 -0000 On Tue, Dec 15, 2009 at 3:33 PM, Peter Maxwell wrot= e: > Add in an explicit "pass all" rule at the start and set the > log keyword on it. =A0Make sure *none* of the web traffic is hitting > this rule. > If the box isn't too loaded, you may try using "log (all)" on the pass > rules (so that ALL packets are logged, not just the initial SYN) - > that way at least you'd find out which rules those data packets are > hitting, which would likely pin down the problem quite a bit.. those > missing packets must have went somewhere ;-) =A0If it were me, that > would be my preferable option if it was available. > Barring that, I'd suggest simplifying your setup as much as possible - > is there too much traffic to remove the "route-to" and try it against > a single webserver? > I'd also suggest removing the "scrub" directive until you have it > working properly. These are all great suggestions, but I will probably have to wait until the middle of the night to try them just in case of catastrophe. :) I will report back what I find. >=A0Is the "state-policy" floating or if-bound? I don't know what that means. :( I'll check the manual. But it's whatever the default is; I didn't leave anything but IP addresses out of the config file. > Does the problem affect other services in a similar manner, can you > replicate the exact same problem with the web servers with sshd, for > example? In theory it probably affects DNS as well (the other service being load balanced), but since that's a UDP protocol. When it happens to my ssh sessions, it seems to happen to all of them at on= ce. > What's annoying me is that I'm fairly sure I've seen this problem > before, but for the life of me I can't remember what caused it :-( Oh no! > pf uses the last rule in the ruleset that matches for a given packet, > so for a first instance setup I'd suggest putting an explicit "pass > all" as the first rule, then any pass rules that do load-balancing and > the like, then a list of block rules. =A0It makes it a lot easier to > read and debug. =A0Then once it's working as you want, you can move the > block rules up to the top and add in the "quick" keyword for > performance purposes. We could probably do that while nothing bad is happening, as long as we get it done before the next time we get DDOS'd. At such times, we really don't want hundreds of megs of garbage going through the load balance rule, so "quick" becomes pretty important. :) But in the everyday case, we can squeak by the other way long enough to test. Thanks! From owner-freebsd-pf@FreeBSD.ORG Wed Dec 16 01:27:07 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 661B81065676 for ; Wed, 16 Dec 2009 01:27:07 +0000 (UTC) (envelope-from dave.mehler@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id E58338FC18 for ; Wed, 16 Dec 2009 01:27:06 +0000 (UTC) Received: by bwz5 with SMTP id 5so412383bwz.3 for ; Tue, 15 Dec 2009 17:27:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Kzh3YS/JBgC7Vi9zFRIMLKiryzgFExtxv91pF6ye0j4=; b=Zi2m3lIcTfa/1XhHNwqw8xwGI9Js7JyrJW8r58smWhQjU7i01yRTRv72pWl9aU7SjC kXDf3aE5jjuGX4ZZNl/M6mphi1EbQCsuY54NQaIvX1W3n1ZHf7HYo0gi1+ixXSTOH6PE TgFFA5bIYvBGCp7RcAID8FCSOsSYyfxFrMRF0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uGxOdQf41uxJDqVcd2cVJ3Cum++vYA+x8psPRmLi2L7VEq3MGFffRDVynLOUMo9dlp no7vW2/+BbKoqqLqooP0NrL3Dv6EbAACxYLYA2as1gl5rRaWNOtshd2kkuLEvnc8KkzU PpG8kjI+03c5Ha8d+77iXurxETh9t8azP1Av8= MIME-Version: 1.0 Received: by 10.204.148.82 with SMTP id o18mr143686bkv.188.1260925163471; Tue, 15 Dec 2009 16:59:23 -0800 (PST) Date: Tue, 15 Dec 2009 19:59:23 -0500 Message-ID: <78e0dabc0912151659h5d2a9bd4i5a0c4f5a1ff69884@mail.gmail.com> From: David Mehler To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: new firewall config X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Dec 2009 01:27:07 -0000 Hello, I'm writing a new firewall for an 8.0 machine. It's a gateway box, it runs an ftp proxy, dhcp and dns services and ntp. It also routes. Other than that it should block everything else. I've got the below rules, and am wondering since it works if it's the most efficient it can be or if there are any holes in it? Comments appreciated. Thanks. Dave. # Required order: options, normalization, queueing, translation, filtering. # Macros and tables may be defined and used anywhere. ext_if="em0" # replace with actual external interface name i.e., dc0 int_if="em1" # replace with actual internal interface name i.e., dc1 internal_net="192.168.5.0/24" tcp_services="{ ftp-data, ftp, ssh, domain, http, pop3, https, 1503, 1863, 3389, 5999, 7001, 8000, 8080 }" udp_services="{ 9, domain, bootps, ntp, 7001 }" icmp_types = "echoreq" set optimization normal set block-policy return set require-order yes set fingerprints "/etc/pf.os" set skip on lo0 scrub in all nat on $ext_if from $internal_net to any -> ($ext_if) nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 \ port 8021 antispoof for $ext_if antispoof for $int_if block all anchor "ftp-proxy/*" pass out proto tcp from 127.0.0.1 to any port 21 keep state pass quick inet proto tcp to any port $tcp_services flags S/SA keep state pass quick inet proto { tcp, udp } to any port $udp_services keep state pass inet proto icmp all icmp-type $icmp_types keep state pass inet proto icmp all icmp-type unreach code needfrag keep state # allow out the default range for traceroute(8): # "base+nhops*nqueries-1" (33434+64*3-1) pass inet proto udp from any to any \ port 33433 >< 33626 keep state From owner-freebsd-pf@FreeBSD.ORG Wed Dec 16 11:50:20 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35DFE1065679 for ; Wed, 16 Dec 2009 11:50:20 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail2.jellyfishnet.co.uk (mail2.jellyfishnet.co.uk [93.91.20.10]) by mx1.freebsd.org (Postfix) with ESMTP id C52B68FC0A for ; Wed, 16 Dec 2009 11:50:19 +0000 (UTC) Received: from pemexhub02.jellyfishnet.co.uk.local (93.91.20.3) by mail2.jellyfishnet.co.uk (93.91.20.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Wed, 16 Dec 2009 11:50:12 +0000 Received: from PEMEXMBXVS02.jellyfishnet.co.uk.local ([192.168.65.27]) by pemexhub02.jellyfishnet.co.uk.local ([192.168.65.8]) with mapi; Wed, 16 Dec 2009 11:50:17 +0000 From: Greg Hennessy To: "freebsd-pf@freebsd.org" Date: Wed, 16 Dec 2009 11:50:16 +0000 Thread-Topic: new firewall config Thread-Index: Acp97wBprhPzzU7RQiePD0DCqGCgxAAVsxAw Message-ID: <9E8D76EC267C9444AC737F649CBBAD9027419F4EEF@PEMEXMBXVS02.jellyfishnet.co.uk.local> References: <78e0dabc0912151659h5d2a9bd4i5a0c4f5a1ff69884@mail.gmail.com> In-Reply-To: <78e0dabc0912151659h5d2a9bd4i5a0c4f5a1ff69884@mail.gmail.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: RE: new firewall config X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Dec 2009 11:50:20 -0000 s/block all/block log all/=20 Or debug will come back and bite you.=20 Regards Greg -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On= Behalf Of David Mehler Sent: 16 December 2009 12:59 AM To: freebsd-pf@freebsd.org Subject: new firewall config Hello, I'm writing a new firewall for an 8.0 machine. It's a gateway box, it runs an ftp proxy, dhcp and dns services and ntp. It also routes. Other than that it should block everything else. I've got the below rules, and am wondering since it works if it's the most efficient it can be or if there are any holes in it? Comments appreciated. Thanks. Dave. # Required order: options, normalization, queueing, translation, filtering. # Macros and tables may be defined and used anywhere. ext_if=3D"em0" # replace with actual external interface name i.e., dc0 int_if=3D"em1" # replace with actual internal interface name i.e., dc1 internal_net=3D"192.168.5.0/24" tcp_services=3D"{ ftp-data, ftp, ssh, domain, http, pop3, https, 1503, 1863, 3389, 5999, 7001, 8000, 8080 }" udp_services=3D"{ 9, domain, bootps, ntp, 7001 }" icmp_types =3D "echoreq" set optimization normal set block-policy return set require-order yes set fingerprints "/etc/pf.os" set skip on lo0 scrub in all nat on $ext_if from $internal_net to any -> ($ext_if) nat-anchor "ftp-proxy/*" rdr-anchor "ftp-proxy/*" rdr pass on $int_if proto tcp from any to any port ftp -> 127.0.0.1 \ port 8021 antispoof for $ext_if antispoof for $int_if block all anchor "ftp-proxy/*" pass out proto tcp from 127.0.0.1 to any port 21 keep state pass quick inet proto tcp to any port $tcp_services flags S/SA keep state pass quick inet proto { tcp, udp } to any port $udp_services keep state pass inet proto icmp all icmp-type $icmp_types keep state pass inet proto icmp all icmp-type unreach code needfrag keep state # allow out the default range for traceroute(8): # "base+nhops*nqueries-1" (33434+64*3-1) pass inet proto udp from any to any \ port 33433 >< 33626 keep state _______________________________________________ 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 Wed Dec 16 18:37:46 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C10D31065695 for ; Wed, 16 Dec 2009 18:37:46 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 83AFC8FC21 for ; Wed, 16 Dec 2009 18:37:46 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id B7D3A48B2C; Wed, 16 Dec 2009 18:21:35 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISQdfkBcLoV8; Wed, 16 Dec 2009 18:21:32 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 8A57548B26; Wed, 16 Dec 2009 18:21:30 +0000 (GMT) Message-ID: <4B2924D4.9010207@tomjudge.com> Date: Wed, 16 Dec 2009 18:20:04 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Kevin References: <003001ca7cdc$0b530540$21f90fc0$@com> In-Reply-To: <003001ca7cdc$0b530540$21f90fc0$@com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: PF Transparent Bridge Firewall + CARP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Dec 2009 18:37:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin wrote: > >> -----Original Message----- >> From: Kevin [mailto:k@kevinkevin.com] >> I have what I would consider not a standard firewall scenario that >> requires a second, redundant PF firewall. My first / main firewall is >> pf + transparent bridging with no internal network / ip addresses. > > > I realize that carp would require an ip address on both interfaces to work > properly... this is correct, right? Could I just assign the 1 ip address / > gateway on the bridge0 interface and add a carp interface to fail that over > to the 2nd firewall? This would be easier to do with spanning tree: [router] | [------switch 1------] | | [FW1]--{pfsync}--[FW2] | | [------switch 2------] | [clients] Then you can leave carp out of the equation and your network would be the same as before. FW1 /etc/rc.conf: cloned_interfaces="bridge0" ifconfig_em0="up -tso" ifconfig_em1="up -tso" ifconfig_em2="inet 192.168.255.1/30" ifconfig_bridge0="up addm em0 stp em0 addm em1 stp em1" pfsync_enable="YES" pfsync_syncdev="em2" pfsync_ifconfig="syncpeer 192.168.255.2" FW2 /etc/rc.conf: cloned_interfaces="bridge0" ifconfig_em0="up -tso" ifconfig_em1="up -tso" ifconfig_em2="inet 192.168.255.2/30" ifconfig_bridge0="up addm em0 stp em0 addm em1 stp em1" pfsync_enable="YES" pfsync_syncdev="em2" pfsync_ifconfig="syncpeer 192.168.255.1" Make sure that the spanning tree priority on either switch side is higher (smaller number) than the bridges so that they will remain the root bridges. Tom - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLKSTUAAoJEMSwVS7lr0OdVpMH/A1zQdIxKTiwm12dIklzCg4w CFp09ZPQEK3zjkes2qUpf6VGvg88rhhQE6iMn/BLIYhpdsqmoejHB2a3k397/qKq yevnl4iyB2xaOTZhbIufasI+dtMy1t30ZET4NlMSFZKEsIm6KQGVX8Il2DqyW2AB xW79glm6/YSHUnBCcL9UGEQzIOtkeqsApNAGIQc2TWvQUz0z7jbKaBU72dhl/Yni +ys3tG7/4m4/2ybMVNW+pjs4/TlEwz31HOgM96MfEkgl0xss4k249kSSnYvn5SZ5 lqre6l+xU2WgSVVXydzIJPNNYSThZrJhTfRNYMBv0bF0covT9aZ2IPzLxoqNeAg= =KoIu -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Wed Dec 16 19:25:23 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A8C21065695 for ; Wed, 16 Dec 2009 19:25:23 +0000 (UTC) (envelope-from k@kevinkevin.com) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com [209.85.211.172]) by mx1.freebsd.org (Postfix) with ESMTP id 1FF4D8FC0C for ; Wed, 16 Dec 2009 19:25:22 +0000 (UTC) Received: by ywh2 with SMTP id 2so1323190ywh.27 for ; Wed, 16 Dec 2009 11:25:22 -0800 (PST) Received: by 10.150.251.41 with SMTP id y41mr2309796ybh.247.1260991522434; Wed, 16 Dec 2009 11:25:22 -0800 (PST) Received: from kevin (not.enough.unixsluts.com [76.10.166.187]) by mx.google.com with ESMTPS id 9sm531044yxf.5.2009.12.16.11.25.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Dec 2009 11:25:20 -0800 (PST) From: "Kevin" To: "'Tom Judge'" References: <003001ca7cdc$0b530540$21f90fc0$@com> <4B2924D4.9010207@tomjudge.com> In-Reply-To: <4B2924D4.9010207@tomjudge.com> Date: Wed, 16 Dec 2009 14:25:06 -0500 Message-ID: <005301ca7e85$7a992f10$6fcb8d30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp+fJqzUx0FFR5mR7CbU/cqTutczQAB2tUw Content-Language: en-us Cc: freebsd-pf@freebsd.org Subject: RE: PF Transparent Bridge Firewall + CARP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Dec 2009 19:25:23 -0000 > -----Original Message----- > From: Tom Judge > Sent: Wednesday, December 16, 2009 1:20 PM > To: Kevin > Cc: freebsd-pf@freebsd.org > Subject: Re: PF Transparent Bridge Firewall + CARP > > [router] > | > [------switch 1------] > | | > [FW1]--{pfsync}--[FW2] > | | > [------switch 2------] > | > [clients] My environment would be better described as the following : [router] | [------switch 1 [vlan1]------] | | [FW1]--{pfsync}--[FW2] | | [------switch 1 [vlan2]------] | [clients] Also, I'm assumine em2 is a physical interface, which I probably will have to implement on fw2. Do you forsee problems doing this through vlans instead of two switches? Thanks. From owner-freebsd-pf@FreeBSD.ORG Wed Dec 16 19:49:05 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54F87106566C for ; Wed, 16 Dec 2009 19:49:05 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 1567E8FC08 for ; Wed, 16 Dec 2009 19:49:04 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id CED3148B2E; Wed, 16 Dec 2009 19:49:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5o76zJq34IBZ; Wed, 16 Dec 2009 19:49:00 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 7B2F148B2C; Wed, 16 Dec 2009 19:48:59 +0000 (GMT) Message-ID: <4B293955.3020203@tomjudge.com> Date: Wed, 16 Dec 2009 19:47:33 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Kevin References: <003001ca7cdc$0b530540$21f90fc0$@com> <4B2924D4.9010207@tomjudge.com> <005301ca7e85$7a992f10$6fcb8d30$@com> In-Reply-To: <005301ca7e85$7a992f10$6fcb8d30$@com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: PF Transparent Bridge Firewall + CARP X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Dec 2009 19:49:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin wrote: > > > > My environment would be better described as the following : > > [router] > | > [------switch 1 [vlan1]------] > | | > [FW1]--{pfsync}--[FW2] > | | > [------switch 1 [vlan2]------] > | > [clients] > > Also, I'm assumine em2 is a physical interface, which I probably will have > to implement on fw2. Do you forsee problems doing this through vlans instead > of two switches? > This poses some interesting questions: 1) Do you have 2 physical interfaces in each FW? 2) If the answer to 1 in yes, your ports into vlan 1+2 are access ports? 3) If you disable spanning tree in the ports will the switch forward the STP BPDUS ingressing on one port to another port on the switch (that has STP disabled)? If you and up with 1-3 yes then you are ok with one switch if any is no then you will need to get a second switch. You may be able to achieve the desired results with one switch if your switch supports MSTP but I have never tried it. I assume that the port would be detected as RSTP and the switch would convert the RSTP frame into an MSTP frame with the appropriate vlans bits toggled. Tom - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLKTlUAAoJEMSwVS7lr0OdWJoH/1AAkR6DcGBHXbIjIYKGrllP 0Q0Zbgj5dDOcsuPt2qSbpA3Wj0uCk2GeE2ZL7k4IkhurnXZH1o9FxfcZCqRE/KfV UbCvxwp5II5dFu099ioL77XzevJHQyQerzKPManEafzR74WxEbTfzSbgPE6cjDzj xDO8jNilHbeAzRPhYF0AOjTgOCkHPyEXchgVtwGKYh6Hq70BurnL/8x0zp2koHgL kKgjpVZF+ZNlBRvTYyI9J4UTQkArfAxCPQg72wUEmqO1B4E1V1gdqq6sHt2U4OKW oRVzfA6cy/2TT0rk6e55MD7+GqPnOF2jsAE0P3sLS3QYAIirEBDsRPcDlKOqaq8= =7p+9 -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 18 11:51:10 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 408F3106566C for ; Fri, 18 Dec 2009 11:51:10 +0000 (UTC) (envelope-from gofdp-freebsd-pf@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id F16488FC1A for ; Fri, 18 Dec 2009 11:51:09 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1NLbMR-0000Tl-8E for freebsd-pf@freebsd.org; Fri, 18 Dec 2009 12:51:07 +0100 Received: from p5798b9ce.dip.t-dialin.net ([87.152.185.206]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Dec 2009 12:51:07 +0100 Received: from jumper99 by p5798b9ce.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 18 Dec 2009 12:51:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-pf@freebsd.org From: "Helmut Schneider" Date: Fri, 18 Dec 2009 11:50:50 +0000 (UTC) Lines: 19 Message-ID: References: <237c27100912142221k6cf62b7ay97c8ae20bd0e7eb2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p5798b9ce.dip.t-dialin.net User-Agent: XanaNews/1.19.1.194 X-Ref: news.gmane.org ~XNS:00000011 Sender: news Subject: Re: Lots of weird PF behavior on 7.2-STABLE X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Dec 2009 11:51:10 -0000 Linda Messerschmidt wrote: > 1) TCP connections (mainly port 80) sometimes take 3 seconds to get > started instead of being virtually instant. > 2) Sometimes HTTP connections just stop responding. (Client program > times out waiting for response.) > 3) Sometimes connections get weirdly dropped ("Connection reset by > peer.") 4) Sometimes if I am ssh'd through the firewall, something > will happen and my inbound packets will start getting dropped, but > outbound packets still pass. For example, if I'm at the shell > prompt, it is non-responsive. But if I log alongside a stuck > connection and "write" to that tty, I will see it no problem. > 5) States that have no right to still be there continue to pile up > into the hundreds of thousands. If no suggestion helped so far try to scrub the mss to a smaller value like 1400 or even lower. Helmut From owner-freebsd-pf@FreeBSD.ORG Fri Dec 18 15:40:20 2009 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 344B21065679; Fri, 18 Dec 2009 15:40:20 +0000 (UTC) (envelope-from pierre.reveillon@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8E36D8FC08; Fri, 18 Dec 2009 15:40:19 +0000 (UTC) Received: by ewy26 with SMTP id 26so2505388ewy.3 for ; Fri, 18 Dec 2009 07:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=18ZVebnruDTvGY+WnA9ykcvArxYRyMhnuX8aRUQ1jxU=; b=LOLDwADukhoxO1UQ5b2gcEuiUiZIMyAaoQvMXXimMohOGsRDEG1xBgD9zGSUjKK8s8 PC691k5O6VT+/BJEfxH7lszcZG/+iLyys2oUCZ8qBDjEiqW0wse6BN99qdwP+85+HSZB tiJuJzQS73JRHDDl6rx0kQkksxO4b8fiWIQMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=Gs8xkQ6NBrZl9YbuWmCX0ywyoJmQwIVOdWL/QDxS8foIZR1u1anc1cbAMBqw+TodD1 fYqhaRdW6qzTm177C4to8UkRbDGWm3YbEBqQvPqhTMS5cEEt4em36KUg3gj2h2Ow55wO 8UpS06m2aiHjQXNS3b04KYE0bRBjPlD0wTmTk= Received: by 10.213.102.66 with SMTP id f2mr4925552ebo.12.1261149290058; Fri, 18 Dec 2009 07:14:50 -0800 (PST) Received: from ?192.168.51.51? (lns-bzn-50f-81-56-231-226.adsl.proxad.net [81.56.231.226]) by mx.google.com with ESMTPS id 23sm5268407eya.3.2009.12.18.07.14.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 18 Dec 2009 07:14:49 -0800 (PST) Message-ID: <4B2B9C67.2010801@gmail.com> Date: Fri, 18 Dec 2009 16:14:47 +0100 From: "pierre.reveillon" User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Network ACK loss problem X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 18 Dec 2009 15:40:20 -0000 Hi, I just upgraded a server to 8.0_RELEASE and I started having network problems when pf is enabled (even with only "pass all" rules). It seems that some ACK are loss (see tcpdump results at the end). I still have some strange mail server problems when pf is disabled but I'm not sure it's linked. Thanks, Pierre Informations about my configuration : [root@papaya ~]# uname -a FreeBSD papaya.yyy.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 [root@papaya ~]# dmesg | grep vge0 vge0: port 0xfc00-0xfcff mem 0xfdfff000-0xfdfff0ff irq 18 at device 14.0 on pci0 miibus0: on vge0 vge0: WARNING: using obsoleted if_watchdog interface vge0: Ethernet address: 00:xx:xx:xx:xx:xx vge0: [ITHREAD] vge0: link state changed to UP vge0: promiscuous mode enabled vge0: promiscuous mode disabled [root@papaya ~]# pfctl -sr No ALTQ support in kernel ALTQ related functions disabled pass in all flags S/SA keep state pass out all flags S/SA keep state Tcpdump output: ******************** BAD ONE (pf enabled) ******************** listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:29:26.847488 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [S], seq 4010981448, win 5840, options [mss 1460,sackOK,TS val 27823034 ecr 0,nop,wscale 7], length 0 15:29:26.891968 IP papaya.yyy.net.www > bagherra.local.42567: Flags [S.], seq 3588656077, ack 4010981449, win 65535, options [mss 1412,nop,wscale 3,sackOK,TS val 1087266140 ecr 27823034], length 0 15:29:26.892034 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [.], ack 1, win 46, options [nop,nop,TS val 27823045 ecr 1087266140], length 0 15:29:26.892281 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [P.], seq 1:120, ack 1, win 46, options [nop,nop,TS val 27823045 ecr 1087266140], length 119 15:29:26.982496 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1:1401, ack 120, win 8225, options [nop,nop,TS val 1087266186 ecr 27823045], length 1400 15:29:26.982536 IP bagherra.local.42567 > papaya.yyy.net.www: Flags [.], ack 1401, win 69, options [nop,nop,TS val 27823068 ecr 1087266186], length 0 15:29:27.027653 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087266275 ecr 27823068], length 1400 15:29:27.028035 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 2801:4201, ack 120, win 8225, options [nop,nop,TS val 1087266275 ecr 27823068], length 1400 15:29:27.446470 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087266694 ecr 27823068], length 1400 15:29:28.082905 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087267331 ecr 27823068], length 1400 15:29:29.156079 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087268404 ecr 27823068], length 1400 15:29:31.100271 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087270349 ecr 27823068], length 1400 15:29:34.788167 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087274038 ecr 27823068], length 1400 15:29:40.266521 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087279519 ecr 27823068], length 1400 15:29:51.023919 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087290280 ecr 27823068], length 1400 15:30:12.336745 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087311601 ecr 27823068], length 1400 15:30:54.762699 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087354042 ecr 27823068], length 1400 15:31:58.740422 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087418043 ecr 27823068], length 1400 15:33:02.718736 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087482044 ecr 27823068], length 1400 15:34:06.696421 IP papaya.yyy.net.www > bagherra.local.42567: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1087546045 ecr 27823068], length 1400 ********************** GOOD ONE (pf disabled) ********************** listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 15:35:20.857405 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [S], seq 989268196, win 5840, options [mss 1460,sackOK,TS val 27911536 ecr 0,nop,wscale 7], length 0 15:35:20.901493 IP papaya.yyy.net.www > bagherra.local.52734: Flags [S.], seq 2220327620, ack 989268197, win 65535, options [mss 1412,nop,wscale 3,sackOK,TS val 1324570413 ecr 27911536], length 0 15:35:20.901541 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 1, win 46, options [nop,nop,TS val 27911548 ecr 1324570413], length 0 15:35:20.901682 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [P.], seq 1:120, ack 1, win 46, options [nop,nop,TS val 27911548 ecr 1324570413], length 119 15:35:20.949199 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 1:1401, ack 120, win 8225, options [nop,nop,TS val 1324570459 ecr 27911548], length 1400 15:35:20.949243 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 1401, win 69, options [nop,nop,TS val 27911559 ecr 1324570459], length 0 15:35:20.994274 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 1401:2801, ack 120, win 8225, options [nop,nop,TS val 1324570504 ecr 27911559], length 1400 15:35:20.994310 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 2801, win 91, options [nop,nop,TS val 27911571 ecr 1324570504], length 0 15:35:20.994758 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 2801:4201, ack 120, win 8225, options [nop,nop,TS val 1324570504 ecr 27911559], length 1400 15:35:20.994772 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 4201, win 114, options [nop,nop,TS val 27911571 ecr 1324570504], length 0 15:35:21.038843 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 4201:5601, ack 120, win 8225, options [nop,nop,TS val 1324570549 ecr 27911571], length 1400 15:35:21.038876 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 5601, win 137, options [nop,nop,TS val 27911582 ecr 1324570549], length 0 15:35:21.039366 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 5601:7001, ack 120, win 8225, options [nop,nop,TS val 1324570549 ecr 27911571], length 1400 15:35:21.039383 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 7001, win 159, options [nop,nop,TS val 27911582 ecr 1324570549], length 0 15:35:21.040337 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 7001:8401, ack 120, win 8225, options [nop,nop,TS val 1324570550 ecr 27911571], length 1400 15:35:21.040351 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 8401, win 182, options [nop,nop,TS val 27911582 ecr 1324570550], length 0 15:35:21.084159 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 8401:9801, ack 120, win 8225, options [nop,nop,TS val 1324570594 ecr 27911582], length 1400 15:35:21.084201 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 9801, win 204, options [nop,nop,TS val 27911593 ecr 1324570594], length 0 15:35:21.085054 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], seq 9801:11201, ack 120, win 8225, options [nop,nop,TS val 1324570595 ecr 27911582], length 1400 15:35:21.085076 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 11201, win 227, options [nop,nop,TS val 27911593 ecr 1324570595], length 0 15:35:21.085088 IP papaya.yyy.net.www > bagherra.local.52734: Flags [P.], seq 11201:11727, ack 120, win 8225, options [nop,nop,TS val 1324570595 ecr 27911582], length 526 15:35:21.085098 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 11727, win 249, options [nop,nop,TS val 27911593 ecr 1324570595], length 0 15:35:21.085950 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [F.], seq 120, ack 11727, win 249, options [nop,nop,TS val 27911594 ecr 1324570595], length 0 15:35:21.131345 IP papaya.yyy.net.www > bagherra.local.52734: Flags [.], ack 121, win 8225, options [nop,nop,TS val 1324570642 ecr 27911594], length 0 15:35:21.131563 IP papaya.yyy.net.www > bagherra.local.52734: Flags [F.], seq 11727, ack 121, win 8225, options [nop,nop,TS val 1324570642 ecr 27911594], length 0 15:35:21.131596 IP bagherra.local.52734 > papaya.yyy.net.www: Flags [.], ack 11728, win 249, options [nop,nop,TS val 27911605 ecr 1324570642], length 0