From owner-freebsd-pf@FreeBSD.ORG Mon Jan 26 22:40:06 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4C3B17D for ; Mon, 26 Jan 2015 22:40:06 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95090C0D for ; Mon, 26 Jan 2015 22:40:06 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id va2so10493309obc.7 for ; Mon, 26 Jan 2015 14:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opendns.com; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=0TTy14dqLIxcrcgtFDWqjJusbtVkqTGA/jEn3KC9rkA=; b=HGvrNb4ZKV99LcQhLGZyLK+bg0JJpa+Z4PO+oYOXHhY2YH2lGPoAnT22p2CVJ9k7qV oOMlnzVxvXbf1v6DR64uqyXVuQs4Q3pqGHkO7DccK0y+g1sqCZp4ijBi/5mJ1ylWRWlT Xazv0jVwv6uJ6UBl2HzbzzcfVu6Z+TZHRCNsU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=0TTy14dqLIxcrcgtFDWqjJusbtVkqTGA/jEn3KC9rkA=; b=IiRTZ4i5d5EvSmC+PGgpxb+GMd8fgCNOjeFW5f8sIBOt5amR4PjcztJsgDaYAaTR3Y zIg6zm7o5nPlx6ut+pKvDKmD+OOalhRmXmJykRcJesVNTNFje4UOl+mOzteX7Gmg1Eg/ 482bK7G/1wXPPF67lU94cqGT+MlhAfQ0uOXgyTA/pysG/ktClMh81xfj6LAukiUG1hyt krczRcp3CRtCHiz18BHg9WPW6jTkzacW1u+HzSblLr5JN7Z5keUb+cU6YzP20qLKSk14 Iu4XKmdnwKBZrWcOVj+CuZx5OdUwJvZuVkYtYIz+hHKW/IjfPKipRNJ9mAEFIS2YjDMN VFmA== X-Gm-Message-State: ALoCoQlmi+WAE+iUelKyhYJrASHzd5w3HvTKR+PKJ3uNj2pn9p5Z8KzUwG72Gk7IT8p1zxM2N2SU MIME-Version: 1.0 X-Received: by 10.202.231.209 with SMTP id e200mr13613229oih.63.1422312005834; Mon, 26 Jan 2015 14:40:05 -0800 (PST) Received: by 10.202.211.9 with HTTP; Mon, 26 Jan 2015 14:40:05 -0800 (PST) Date: Mon, 26 Jan 2015 14:40:05 -0800 Message-ID: Subject: State Table Discrepancy: (pfctl -si "current entries") vs (pfctl -ss | wc -l) From: Alvin Wong To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 26 Jan 2015 22:40:06 -0000 Hi All, Hoping to see if anyone has observed a similar issue. We have 2 x FreeBSD 10.1 hosts with pf(4) and pfsync with each other. We're finding our primary firewall is showing different pfctl -si "current entries" value when compared to our secondary firewall it is pfsync'd with. For further investigation into the discrepancy we used two different methods to see what is really in the state table: * Method 1: pfctl -s states | wc -l (basically getting a line count for the full enumeration of the state table) * Method 2: pfctl -s info and then recording the "current entries" counter value. One would expect that both methods would yield similar or almost identical values per firewall. Instead, we are finding that our primary firewall is consistently seeing an extra ~35k "current entries" with method 2 when compared with method 1 line count of the full state table. Strange that our second firewall didn't have the same issue (it had matching values). To track, we've been running a cron job on fw1 every 5 minutes for last 4 hours to record Method 1 (line count) vs Method 2 (counter): Mon Jan 26 17:40:00 UTC 2015 Line Count: 58995 Counter: 94852 Mon Jan 26 17:45:00 UTC 2015 Line Count: 87836 Counter: 123729 Mon Jan 26 17:50:00 UTC 2015 Line Count: 79204 Counter: 114893 Mon Jan 26 17:55:00 UTC 2015 Line Count: 69101 Counter: 104928 Mon Jan 26 18:00:00 UTC 2015 Line Count: 67976 Counter: 103878 Mon Jan 26 18:05:00 UTC 2015 Line Count: 59865 Counter: 95707 Mon Jan 26 18:10:00 UTC 2015 Line Count: 81221 Counter: 117034 Mon Jan 26 18:15:00 UTC 2015 Line Count: 61474 Counter: 97352 Mon Jan 26 18:20:00 UTC 2015 Line Count: 61095 Counter: 97321 Mon Jan 26 18:25:00 UTC 2015 Line Count: 62899 Counter: 98787 Mon Jan 26 18:30:00 UTC 2015 Line Count: 64778 Counter: 100677 Mon Jan 26 18:35:00 UTC 2015 Line Count: 63193 Counter: 99028 Mon Jan 26 18:40:00 UTC 2015 Line Count: 65119 Counter: 101056 Mon Jan 26 18:45:00 UTC 2015 Line Count: 67810 Counter: 103605 Mon Jan 26 18:50:00 UTC 2015 Line Count: 65420 Counter: 101592 Mon Jan 26 18:55:00 UTC 2015 Line Count: 63278 Counter: 99130 Mon Jan 26 19:00:00 UTC 2015 Line Count: 70237 Counter: 105966 Mon Jan 26 19:05:00 UTC 2015 Line Count: 70560 Counter: 106404 Mon Jan 26 19:10:00 UTC 2015 Line Count: 66994 Counter: 102886 Mon Jan 26 19:15:00 UTC 2015 Line Count: 73560 Counter: 109429 Mon Jan 26 19:20:00 UTC 2015 Line Count: 72352 Counter: 108589 Mon Jan 26 19:25:00 UTC 2015 Line Count: 66957 Counter: 102740 Mon Jan 26 19:30:00 UTC 2015 Line Count: 82602 Counter: 118415 Mon Jan 26 19:35:00 UTC 2015 Line Count: 67278 Counter: 103079 Mon Jan 26 19:40:00 UTC 2015 Line Count: 65059 Counter: 100956 Mon Jan 26 19:45:00 UTC 2015 Line Count: 63738 Counter: 99809 Mon Jan 26 19:50:00 UTC 2015 Line Count: 67083 Counter: 102882 Mon Jan 26 19:55:00 UTC 2015 Line Count: 69313 Counter: 105204 Mon Jan 26 20:00:00 UTC 2015 Line Count: 70163 Counter: 106053 Mon Jan 26 20:05:00 UTC 2015 Line Count: 66946 Counter: 102864 Mon Jan 26 20:10:00 UTC 2015 Line Count: 71366 Counter: 107242 Mon Jan 26 20:15:00 UTC 2015 Line Count: 63283 Counter: 99221 Mon Jan 26 20:20:00 UTC 2015 Line Count: 72958 Counter: 109133 Mon Jan 26 20:25:00 UTC 2015 Line Count: 70693 Counter: 106605 Mon Jan 26 20:30:00 UTC 2015 Line Count: 68270 Counter: 104229 Mon Jan 26 20:35:00 UTC 2015 Line Count: 74372 Counter: 110309 Mon Jan 26 20:40:00 UTC 2015 Line Count: 65283 Counter: 101149 Mon Jan 26 20:45:00 UTC 2015 Line Count: 65804 Counter: 101729 Mon Jan 26 20:50:00 UTC 2015 Line Count: 69494 Counter: 105730 Mon Jan 26 20:55:00 UTC 2015 Line Count: 68158 Counter: 104058 Mon Jan 26 21:00:00 UTC 2015 Line Count: 96569 Counter: 132325 Mon Jan 26 21:05:00 UTC 2015 Line Count: 80072 Counter: 115951 Mon Jan 26 21:10:00 UTC 2015 Line Count: 72740 Counter: 108723 Mon Jan 26 21:15:00 UTC 2015 Line Count: 75114 Counter: 110990 Mon Jan 26 21:20:00 UTC 2015 Line Count: 80720 Counter: 116927 Mon Jan 26 21:25:00 UTC 2015 Line Count: 82644 Counter: 118533 Any insight would be appreciated. Perhaps this is a pfctl -si bug? Thanks, Alvin Wong From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 06:40:17 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2D8CFC39 for ; Tue, 27 Jan 2015 06:40:17 +0000 (UTC) Received: from mail14.tpgi.com.au (smtp-out14.tpgi.com.au [220.244.226.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0D277AA for ; Tue, 27 Jan 2015 06:40:15 +0000 (UTC) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Tue, 27 Jan 2015 17:25:44 +1100 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail14.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id t0R6Pg2C025156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jan 2015 17:25:44 +1100 Received: from ip-211.ish.com.au ([203.29.62.211]:49942 helo=ish.com.au) by fish.ish.com.au with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YFzam-0001kB-08 for freebsd-pf@freebsd.org; Tue, 27 Jan 2015 17:25:40 +1100 Received: from [203.29.62.182] (HELO Aristedess-MacBook-Pro.local) by ish.com.au (CommuniGate Pro SMTP 6.1c1) with ESMTPS id 17972871 for freebsd-pf@freebsd.org; Tue, 27 Jan 2015 17:25:39 +1100 Message-ID: <54C72F63.8040908@ish.com.au> Date: Tue, 27 Jan 2015 17:25:39 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: meaning of State-mismatch Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 06:40:17 -0000 I have been unable to find much documentation about the counter called "state-mismatch". I notice it going up on my firewall (FreeBSD 10.1) but only at a slow rate (maybe at around 1 per minute). What is the significance of this value? Is it indicative of dropped states (and I should be increasing the state timeout)? Thank you Ari In full, I see this: # pfctl -si No ALTQ support in kernel ALTQ related functions disabled Status: Enabled for 14 days 18:57:27 Debug: Urgent State Table Total Rate current entries 3768 searches 927120779 725.5/s inserts 40516048 31.7/s removals 40512275 31.7/s Counters match 37456359 29.3/s bad-offset 0 0.0/s fragment 2 0.0/s short 2 0.0/s normalize 368 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 21848 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 0 0.0/s Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 07:46:35 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7CFE4AF1 for ; Tue, 27 Jan 2015 07:46:35 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B49DDC2 for ; Tue, 27 Jan 2015 07:46:35 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::c917:66ee:a8b8:73e5] (unknown [IPv6:2001:7b8:3a7:0:c917:66ee:a8b8:73e5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 146A55C2E; Tue, 27 Jan 2015 08:46:32 +0100 (CET) Subject: Re: meaning of State-mismatch Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DC335CBF-B200-4739-BFAC-93546E4EF352"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: Dimitry Andric In-Reply-To: <54C72F63.8040908@ish.com.au> Date: Tue, 27 Jan 2015 08:46:24 +0100 Message-Id: References: <54C72F63.8040908@ish.com.au> To: Aristedes Maniatis X-Mailer: Apple Mail (2.1993) Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 07:46:35 -0000 --Apple-Mail=_DC335CBF-B200-4739-BFAC-93546E4EF352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Jan 2015, at 07:25, Aristedes Maniatis wrote: >=20 > I have been unable to find much documentation about the counter called = "state-mismatch". I notice it going up on my firewall (FreeBSD 10.1) but = only at a slow rate (maybe at around 1 per minute). >=20 > What is the significance of this value? Is it indicative of dropped = states (and I should be increasing the state timeout)? It's not really documented in our pfctl(8) manpage, but the OpenBSD = version does mention it: state-mismatch packet was associated with a state entry, but sequence = numbers did not match So maybe something is dropping packets, making holes in the sequence = numbers? Or maybe somebody is trying something sneaky? :) -Dimitry --Apple-Mail=_DC335CBF-B200-4739-BFAC-93546E4EF352 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlTHQlcACgkQsF6jCi4glqOzQgCgqNvy/o3oYNJwI5G8TEJPFUFa 3r0AnjhekhVq1Eoltj4NRewPbPopadPc =RJek -----END PGP SIGNATURE----- --Apple-Mail=_DC335CBF-B200-4739-BFAC-93546E4EF352-- From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 07:49:41 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7118AB5A for ; Tue, 27 Jan 2015 07:49:41 +0000 (UTC) Received: from mail14.tpgi.com.au (mail14.tpgi.com.au [203.12.160.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F2866DD5 for ; Tue, 27 Jan 2015 07:49:40 +0000 (UTC) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Tue, 27 Jan 2015 18:49:36 +1100 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail14.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id t0R7nYbl003839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jan 2015 18:49:36 +1100 Received: from ip-211.ish.com.au ([203.29.62.211]:25495 helo=ish.com.au) by fish.ish.com.au with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YG0tn-0006Ow-34; Tue, 27 Jan 2015 18:49:24 +1100 Received: from [203.29.62.182] (HELO Aristedess-MacBook-Pro.local) by ish.com.au (CommuniGate Pro SMTP 6.1c1) with ESMTPS id 17972958; Tue, 27 Jan 2015 18:49:23 +1100 Message-ID: <54C74303.1070601@ish.com.au> Date: Tue, 27 Jan 2015 18:49:23 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: meaning of State-mismatch References: <54C72F63.8040908@ish.com.au> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 07:49:41 -0000 On 27/01/2015 6:46pm, Dimitry Andric wrote: > On 27 Jan 2015, at 07:25, Aristedes Maniatis wrote: >> >> I have been unable to find much documentation about the counter called "state-mismatch". I notice it going up on my firewall (FreeBSD 10.1) but only at a slow rate (maybe at around 1 per minute). >> >> What is the significance of this value? Is it indicative of dropped states (and I should be increasing the state timeout)? > > It's not really documented in our pfctl(8) manpage, but the OpenBSD version does > mention it: > > state-mismatch > packet was associated with a state entry, but sequence numbers did not > match > > So maybe something is dropping packets, making holes in the sequence numbers? Or > maybe somebody is trying something sneaky? :) > > -Dimitry Ah, thanks for that. Maybe you could add that doc to the FreeBSD man page. Could it simply be a packet loss issue where a packet is lost and the next packet arrives out of order? Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 08:07:31 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EE04CF95 for ; Tue, 27 Jan 2015 08:07:31 +0000 (UTC) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AB413FEA for ; Tue, 27 Jan 2015 08:07:31 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::c917:66ee:a8b8:73e5] (unknown [IPv6:2001:7b8:3a7:0:c917:66ee:a8b8:73e5]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id D103D5C2E; Tue, 27 Jan 2015 09:07:22 +0100 (CET) Subject: Re: meaning of State-mismatch Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_68BC1EE8-3796-4317-8254-5A246704A3F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: Dimitry Andric In-Reply-To: <54C74303.1070601@ish.com.au> Date: Tue, 27 Jan 2015 09:07:18 +0100 Message-Id: <8A242C55-A2D7-49C2-A0CC-AFB1E447C494@FreeBSD.org> References: <54C72F63.8040908@ish.com.au> <54C74303.1070601@ish.com.au> To: Aristedes Maniatis X-Mailer: Apple Mail (2.1993) Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 08:07:32 -0000 --Apple-Mail=_68BC1EE8-3796-4317-8254-5A246704A3F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Jan 2015, at 08:49, Aristedes Maniatis wrote: >=20 > On 27/01/2015 6:46pm, Dimitry Andric wrote: >> On 27 Jan 2015, at 07:25, Aristedes Maniatis wrote: >>>=20 >>> I have been unable to find much documentation about the counter = called "state-mismatch". I notice it going up on my firewall (FreeBSD = 10.1) but only at a slow rate (maybe at around 1 per minute). >>>=20 >>> What is the significance of this value? Is it indicative of dropped = states (and I should be increasing the state timeout)? >>=20 >> It's not really documented in our pfctl(8) manpage, but the OpenBSD = version does >> mention it: >>=20 >> state-mismatch >> packet was associated with a state entry, but sequence = numbers did not >> match >>=20 >> So maybe something is dropping packets, making holes in the sequence = numbers? Or >> maybe somebody is trying something sneaky? :) >>=20 >> -Dimitry >=20 > Ah, thanks for that. Maybe you could add that doc to the FreeBSD man = page. Could it simply be a packet loss issue where a packet is lost and = the next packet arrives out of order? Well, that is just a likely cause. If you let tcpdump run for a while, you might be able to spot it, in e.g. Wireshark? -Dimitry --Apple-Mail=_68BC1EE8-3796-4317-8254-5A246704A3F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.26 iEYEARECAAYFAlTHRzoACgkQsF6jCi4glqMxywCguwW1n5GGmyb9DlC7jA5zbzkV HmoAoNfofcPWQByZv9fAU9DPhDdhUo4x =mJ8o -----END PGP SIGNATURE----- --Apple-Mail=_68BC1EE8-3796-4317-8254-5A246704A3F3-- From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 08:17:45 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD080206 for ; Tue, 27 Jan 2015 08:17:45 +0000 (UTC) Received: from mail14.tpgi.com.au (mail14.tpgi.com.au [203.12.160.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.tpg.com.au", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 492FF16E for ; Tue, 27 Jan 2015 08:17:45 +0000 (UTC) X-TPG-Junk-Status: Message not scanned X-TPG-Antivirus: Passed X-TPG-Abuse: host=[202.161.115.54]; ip=202.161.115.54; date=Tue, 27 Jan 2015 19:17:42 +1100 Received: from fish.ish.com.au (202-161-115-54.static.tpgi.com.au [202.161.115.54] (may be forged)) by mail14.tpgi.com.au (envelope-from ari@ish.com.au) (8.14.3/8.14.3) with ESMTP id t0R8Heb4025331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jan 2015 19:17:42 +1100 Received: from ip-211.ish.com.au ([203.29.62.211]:29253 helo=ish.com.au) by fish.ish.com.au with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YG1L5-00085P-0p; Tue, 27 Jan 2015 19:17:36 +1100 Received: from [203.29.62.182] (HELO Aristedess-MacBook-Pro.local) by ish.com.au (CommuniGate Pro SMTP 6.1c1) with ESMTPS id 17972985; Tue, 27 Jan 2015 19:17:35 +1100 Message-ID: <54C7499E.6090805@ish.com.au> Date: Tue, 27 Jan 2015 19:17:34 +1100 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Thunderbird/34.0 MIME-Version: 1.0 To: Dimitry Andric Subject: Re: meaning of State-mismatch References: <54C72F63.8040908@ish.com.au> <54C74303.1070601@ish.com.au> <8A242C55-A2D7-49C2-A0CC-AFB1E447C494@FreeBSD.org> In-Reply-To: <8A242C55-A2D7-49C2-A0CC-AFB1E447C494@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 08:17:45 -0000 On 27/01/2015 7:07pm, Dimitry Andric wrote: > On 27 Jan 2015, at 08:49, Aristedes Maniatis wrote: >> >> On 27/01/2015 6:46pm, Dimitry Andric wrote: >>> On 27 Jan 2015, at 07:25, Aristedes Maniatis wrote: >>>> >>>> I have been unable to find much documentation about the counter called "state-mismatch". I notice it going up on my firewall (FreeBSD 10.1) but only at a slow rate (maybe at around 1 per minute). >>>> >>>> What is the significance of this value? Is it indicative of dropped states (and I should be increasing the state timeout)? >>> >>> It's not really documented in our pfctl(8) manpage, but the OpenBSD version does >>> mention it: >>> >>> state-mismatch >>> packet was associated with a state entry, but sequence numbers did not >>> match >>> >>> So maybe something is dropping packets, making holes in the sequence numbers? Or >>> maybe somebody is trying something sneaky? :) >>> >>> -Dimitry >> >> Ah, thanks for that. Maybe you could add that doc to the FreeBSD man page. Could it simply be a packet loss issue where a packet is lost and the next packet arrives out of order? > > Well, that is just a likely cause. If you let tcpdump run for a while, > you might be able to spot it, in e.g. Wireshark? > > -Dimitry > If I attach tcpdump to pflog0 is there an easy way to filter for just these events? I assume there is nothing like "block in log flags state-mismatch" to trap these packets? If I knew which IP and port they were going to, I'd have a better idea of where to look. Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 15:26:09 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D8803BA for ; Tue, 27 Jan 2015 15:26:09 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 324ACAC1 for ; Tue, 27 Jan 2015 15:26:09 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id hn18so5259706igb.2 for ; Tue, 27 Jan 2015 07:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B+SlqlU8mLGXLu/8MCD2RErIX1beNo/5pBiIji8tXlw=; b=hKCrMQ+Y8vZ38tHCJ9vdCsSKI2EeNLK1n6wrKfr/1gIVxbU8wDG5xcP3vCfuq7Vkw0 E2l20xTL/icvPrOJ4cRmnV6VAelifhATvf7NR0p9uWA4eidWIoiurn50eRed59GTtIBH JzZkdi2PG4lKo8Ul0EicWZC0kk9HjjbQ57HR1CZUGx+JuUaT/qryODWoVhyWU+/A8OEZ vcZ2JfgzEnh83deIUKG455/dahdDosT9Fa2vGNShkC8dItqJ+5l4o8Pvu9rNSpt5tGOf thXW0prnvLS0qBlXJfXioovh29HMRq46IyrWYZpwSPVYMD2EzvEPz9+jQ4GarQp5e0GC zhXQ== MIME-Version: 1.0 X-Received: by 10.107.32.195 with SMTP id g186mr1996526iog.3.1422372368606; Tue, 27 Jan 2015 07:26:08 -0800 (PST) Received: by 10.50.243.38 with HTTP; Tue, 27 Jan 2015 07:26:08 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Jan 2015 07:26:08 -0800 Message-ID: Subject: Re: State Table Discrepancy: (pfctl -si "current entries") vs (pfctl -ss | wc -l) From: Rumen Telbizov To: Alvin Wong Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 15:26:09 -0000 No one else experiencing this same problem? I was wondering if this might be related to the new SMP version of PF? On Mon, Jan 26, 2015 at 2:40 PM, Alvin Wong wrote: > Hi All, > > Hoping to see if anyone has observed a similar issue. > > We have 2 x FreeBSD 10.1 hosts with pf(4) and pfsync with each other. > We're finding our primary firewall is showing different pfctl -si "current > entries" value when compared to our secondary firewall it is pfsync'd with. > > For further investigation into the discrepancy we used two different > methods to see what is really in the state table: > > * Method 1: pfctl -s states | wc -l (basically getting a line count for > the full enumeration of the state table) > * Method 2: pfctl -s info and then recording the "current entries" counter > value. > > One would expect that both methods would yield similar or almost identical > values per firewall. Instead, we are finding that our primary firewall is > consistently seeing an extra ~35k "current entries" with method 2 when > compared with method 1 line count of the full state table. Strange that > our second firewall didn't have the same issue (it had matching values). > > To track, we've been running a cron job on fw1 every 5 minutes for last 4 > hours to record Method 1 (line count) vs Method 2 (counter): > > Mon Jan 26 17:40:00 UTC 2015 Line Count: 58995 Counter: 94852 > Mon Jan 26 17:45:00 UTC 2015 Line Count: 87836 Counter: 123729 > Mon Jan 26 17:50:00 UTC 2015 Line Count: 79204 Counter: 114893 > Mon Jan 26 17:55:00 UTC 2015 Line Count: 69101 Counter: 104928 > Mon Jan 26 18:00:00 UTC 2015 Line Count: 67976 Counter: 103878 > Mon Jan 26 18:05:00 UTC 2015 Line Count: 59865 Counter: 95707 > Mon Jan 26 18:10:00 UTC 2015 Line Count: 81221 Counter: 117034 > Mon Jan 26 18:15:00 UTC 2015 Line Count: 61474 Counter: 97352 > Mon Jan 26 18:20:00 UTC 2015 Line Count: 61095 Counter: 97321 > Mon Jan 26 18:25:00 UTC 2015 Line Count: 62899 Counter: 98787 > Mon Jan 26 18:30:00 UTC 2015 Line Count: 64778 Counter: 100677 > Mon Jan 26 18:35:00 UTC 2015 Line Count: 63193 Counter: 99028 > Mon Jan 26 18:40:00 UTC 2015 Line Count: 65119 Counter: 101056 > Mon Jan 26 18:45:00 UTC 2015 Line Count: 67810 Counter: 103605 > Mon Jan 26 18:50:00 UTC 2015 Line Count: 65420 Counter: 101592 > Mon Jan 26 18:55:00 UTC 2015 Line Count: 63278 Counter: 99130 > Mon Jan 26 19:00:00 UTC 2015 Line Count: 70237 Counter: 105966 > Mon Jan 26 19:05:00 UTC 2015 Line Count: 70560 Counter: 106404 > Mon Jan 26 19:10:00 UTC 2015 Line Count: 66994 Counter: 102886 > Mon Jan 26 19:15:00 UTC 2015 Line Count: 73560 Counter: 109429 > Mon Jan 26 19:20:00 UTC 2015 Line Count: 72352 Counter: 108589 > Mon Jan 26 19:25:00 UTC 2015 Line Count: 66957 Counter: 102740 > Mon Jan 26 19:30:00 UTC 2015 Line Count: 82602 Counter: 118415 > Mon Jan 26 19:35:00 UTC 2015 Line Count: 67278 Counter: 103079 > Mon Jan 26 19:40:00 UTC 2015 Line Count: 65059 Counter: 100956 > Mon Jan 26 19:45:00 UTC 2015 Line Count: 63738 Counter: 99809 > Mon Jan 26 19:50:00 UTC 2015 Line Count: 67083 Counter: 102882 > Mon Jan 26 19:55:00 UTC 2015 Line Count: 69313 Counter: 105204 > Mon Jan 26 20:00:00 UTC 2015 Line Count: 70163 Counter: 106053 > Mon Jan 26 20:05:00 UTC 2015 Line Count: 66946 Counter: 102864 > Mon Jan 26 20:10:00 UTC 2015 Line Count: 71366 Counter: 107242 > Mon Jan 26 20:15:00 UTC 2015 Line Count: 63283 Counter: 99221 > Mon Jan 26 20:20:00 UTC 2015 Line Count: 72958 Counter: 109133 > Mon Jan 26 20:25:00 UTC 2015 Line Count: 70693 Counter: 106605 > Mon Jan 26 20:30:00 UTC 2015 Line Count: 68270 Counter: 104229 > Mon Jan 26 20:35:00 UTC 2015 Line Count: 74372 Counter: 110309 > Mon Jan 26 20:40:00 UTC 2015 Line Count: 65283 Counter: 101149 > Mon Jan 26 20:45:00 UTC 2015 Line Count: 65804 Counter: 101729 > Mon Jan 26 20:50:00 UTC 2015 Line Count: 69494 Counter: 105730 > Mon Jan 26 20:55:00 UTC 2015 Line Count: 68158 Counter: 104058 > Mon Jan 26 21:00:00 UTC 2015 Line Count: 96569 Counter: 132325 > Mon Jan 26 21:05:00 UTC 2015 Line Count: 80072 Counter: 115951 > Mon Jan 26 21:10:00 UTC 2015 Line Count: 72740 Counter: 108723 > Mon Jan 26 21:15:00 UTC 2015 Line Count: 75114 Counter: 110990 > Mon Jan 26 21:20:00 UTC 2015 Line Count: 80720 Counter: 116927 > Mon Jan 26 21:25:00 UTC 2015 Line Count: 82644 Counter: 118533 > > Any insight would be appreciated. Perhaps this is a pfctl -si bug? > > Thanks, > > Alvin Wong > _______________________________________________ > 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" > -- Rumen Telbizov Unix Systems Administrator From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 15:54:53 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 05267848 for ; Tue, 27 Jan 2015 15:54:53 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6618CDB7 for ; Tue, 27 Jan 2015 15:54:52 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id q1so14079412lam.2 for ; Tue, 27 Jan 2015 07:54:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=e2ybqdbn1TSfbuhZNw9AW87rIYmlTtZlsG15T6zFUSw=; b=AdgPuKDYR24IDQRSDIpoWesYXw2dlAgtrxHp42GTPLyDLkv2dHlRezN4/0gFUwUfbV JDx20HXCsD1nlNMJA04loK/Gnfaj8HWvcglJlWnh1JvDp7Fmqn9oVD+9QDq/HDCcxLEK nu/wB3G4em6dpZN8YNxvbQGXIeMJhuubrIBfZvBdFGsEAyJjmceFWvoGxxLMs+g5Yvpj apqVw86T4Ddl51tncJFxVITxfThfuphZdldnhWEYxbaECvh1LlgkfdvmA/g7rV5EpCVM fby/mVXgxIuilj3C0ZgsSCz3B1wnnxLV3PjeqnEGLgJBX90AVpdvjE/mH+bBVfNNvZul E4XA== X-Received: by 10.152.21.10 with SMTP id r10mr2541872lae.11.1422374090404; Tue, 27 Jan 2015 07:54:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.138.4 with HTTP; Tue, 27 Jan 2015 07:54:10 -0800 (PST) In-Reply-To: <54BF2F92.4060102@manotom.com> References: <54BDD62E.4040003@bluerosetech.com> <54BF2F92.4060102@manotom.com> From: Odhiambo Washington Date: Tue, 27 Jan 2015 18:54:10 +0300 Message-ID: Subject: Re: Controlling P2P with PF To: Konstantin Nikolaev Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-pf@freebsd org" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 15:54:53 -0000 On 21 January 2015 at 07:48, Konstantin Nikolaev wrote: > > > *An example of a live horse: *if_ext =3D "fxp1" # =F7=CE= =C5=DB=CE=C9=CA > =C9=CE=D4. =D3=CD=CF=D4=D2=D1=DD=C9=CA =D7 TOMICH =D3 IP 195.211.197.17 > if_int =3D "fxp0" # =E9=CE=D4=C5=D2=C6=C5=CA=D3 =D3=CD=CF= =D4=D2=D1=DD=C9=CA =D7 =E4=ED=FA =D3 IP > 195.211.196.65 > > default_ports =3D "{ 0:1000 3389 6666 7777}" > > altq on $if_ext hfsc bandwidth 100Mb queue { default_up, slow_up, ack_up= } > queue default_up bandwidth 70Mb priority 5 hfsc( default ) > queue slow_up bandwidth 2000Kb priority 4 hfsc( realtime 1000K= b > linkshare 2000Kb upperlimit 2Mb) > queue ack_up bandwidth 28Mb priority 7 hfsc( realtime 10Mb > linkshare 28Mb ) > > altq on $if_int hfsc bandwidth 100Mb queue { default_down, slow_down, > ack_down } > queue default_down bandwidth 70Mb priority 5 hfsc( default ) > queue slow_down bandwidth 2000Kb priority 4 hfsc( realtime > 1000Kb linkshare 2000Kb upperlimit 2Mb) > queue ack_down bandwidth 28Mb priority 7 hfsc( realtime 10Mb > linkshare 28Mb ) > > #Output DMZ network $Mnet: > # 1) > pass in quick on $if_int from $if_int:network to any no state > pass out quick on $if_ext proto { tcp udp } from $if_int:network to any > port $default_ports queue ( default_up ack_up ) no state > # 2) > pass out on $if_ext from $if_int:network to any queue ( default_up ack_up > ) no state > # 3) > pass out on $if_ext proto { tcp udp } from $if_int:network to ! > queue ( slow_up ack_up ) no state > > #Answers on requests > # 1) > pass in quick on $if_ext from any to $if_int:network no state > pass out quick on $if_int proto {tcp udp} from any port $default_ports to > $if_int:network queue (default_down ack_down ) no state > # 2) > pass out on $if_int from any to $if_int:network queue ( default_down > ack_down ) no state > # 3) > pass out on $if_int proto { tcp } from ! to $if_int:network queue = ( > slow_down ack_down ) no state > > > *Not very good, but as an example descend* > I am thinking of doing it from the top: 1. Give higher priority to all the known traffic on known ports 2. Leave only 1% to unknown traffic on unknown ports, BUT, if capacity is there because known traffic are 'asleep', let unknown traffic use it Reading an example from: https://www.pantz.org/software/pf/pfconfigfile.htm= l, and with a up/down link of 2/2Mbps altq on $ext_if bandwidth 1968Kb hfsc queue { q_pri, q_def, q_mus, q_tor } queue q_pri bandwidth 49% priority 7 hfsc queue q_def bandwidth 49% priority 5 hfsc (linkshare 49%) {q_smtp,q_http,ssh_login,q_def1} queue ssh_login bandwidth 96% priority 5 hfsc queue q_http bandwidth 1% priority 4 hfsc queue q_smtp bandwidth 1% priority 4 hfsc queue q_def1 bandwidth 1% priority 3 hfsc (default) queue q_mus bandwidth 1% qlimit 200 priority 4 hfsc queue q_tor bandwidth 1% qlimit 25 priority 3 hfsc (upperlimit 272Kb) Although I would want to add more known ports.. I am still reading about PF and this queues stuff so it's not easy to sink it it still. I don't understand why this example only dealt with ext_if and did nothing on the int_if :( Someone must have done this in a way that ensures torrents work when there is capacity and get relegated when there is important traffic. --=20 Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." From owner-freebsd-pf@FreeBSD.ORG Tue Jan 27 21:46:22 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AF915817 for ; Tue, 27 Jan 2015 21:46:22 +0000 (UTC) Received: from krichy.tvnetwork.hu (unknown [IPv6:2a01:be00:0:2::10]) by mx1.freebsd.org (Postfix) with ESMTP id 75138F29 for ; Tue, 27 Jan 2015 21:46:22 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id 12FE7A61B; Tue, 27 Jan 2015 22:46:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id 125E6A61A for ; Tue, 27 Jan 2015 22:46:20 +0100 (CET) Date: Tue, 27 Jan 2015 22:46:20 +0100 (CET) From: krichy@tvnetwork.hu To: freebsd-pf@freebsd.org Subject: synproxy+reassemble tcp Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 27 Jan 2015 21:46:22 -0000 Dear pf users, I've set up a FreeBSD 10.1 pf, with scrub all no-df random-id reassemble tcp and synproxy rules And synproxy does not work when 'reassemble tcp' is specified on scrub. Any one to reproduce/confirm this? Regards, Kojedzinszky Richard Euronet Magyarorszag Informatika Zrt. From owner-freebsd-pf@FreeBSD.ORG Wed Jan 28 13:55:11 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 48DC43E6 for ; Wed, 28 Jan 2015 13:55:11 +0000 (UTC) Received: from krichy.tvnetwork.hu (unknown [IPv6:2a01:be00:0:2::10]) by mx1.freebsd.org (Postfix) with ESMTP id 0E88A6D0 for ; Wed, 28 Jan 2015 13:55:10 +0000 (UTC) Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id AB61210B0; Wed, 28 Jan 2015 14:55:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id AA79310AF; Wed, 28 Jan 2015 14:55:08 +0100 (CET) Date: Wed, 28 Jan 2015 14:55:08 +0100 (CET) From: krichy@tvnetwork.hu To: misc@openbsd.org Subject: pf synproxy Message-ID: User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Jan 2015 13:55:11 -0000 Dear all, I've setup a pf firewall with synproxy. I've ran a simulated DDoS for a service behind pf, everything went fine, until I've found that rarely a tcp connection got established to the service behind pf. The reason was (due to a configuraion problem) that the firewall actually was connected to the Internet, and it continued the tcp handshake. As the spoofed source addresses sometimes were real alive systems on the Internet, the SYN+ACK packet got to them. Mainly they replied with an RST packet, but some replaied with RST+ACK. And in pf's source code I found that the synproxy code only checks for the ACK flag, and if set, it declares the connection established. This way, one could find some machines with such TCP implementations, and use them to actually DDoS the target service. Opinions? Kojedzinszky Richard Euronet Magyarorszag Informatika Zrt. From owner-freebsd-pf@FreeBSD.ORG Wed Jan 28 15:11:10 2015 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F5ED176 for ; Wed, 28 Jan 2015 15:11:10 +0000 (UTC) Received: from upn.univ-paris13.fr (upn.univ-paris13.fr [194.254.164.7]) by mx1.freebsd.org (Postfix) with ESMTP id 54FE7FE2 for ; Wed, 28 Jan 2015 15:11:09 +0000 (UTC) Received: from smtp.univ-paris13.fr (smtp.univ-paris13.fr [192.168.0.72]) by upn.univ-paris13.fr (Mail Server) with ESMTP id 732342881D6 for ; Wed, 28 Jan 2015 16:01:54 +0100 (CET) Received: from [81.194.43.41] (unknown [81.194.43.41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated user : hidden) by smtp.univ-paris13.fr (Postfix) with ESMTPSA id 6A3C83EA0C8 for ; Wed, 28 Jan 2015 16:01:54 +0100 (CET) Message-ID: <54C8F9DC.5060803@univ-paris13.fr> Date: Wed, 28 Jan 2015 16:01:48 +0100 From: Nicolas Greneche User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: Active/Active PF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.18-1 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, 28 Jan 2015 15:11:10 -0000 Hi all, I browse list archives to get information about active/active PF. I tried several keywords : active/active, load balancing ... I have this setup : |-----| |-----| | |----- FW1 ------| | | SW1 | | SW2 | | |----- FW2 ------| | |-----| |-----| There is an etherchannel between SW1 and SW2. FW1 is bridged on the first physical link of the etherchannel. FW2 is on the second link. With stateless rules, everything is OK. With stateful filtering it seems that pfsync is not fast enough to sync state table. I tried to set maxupd to 1 to avoid pfsync update bufferization. I also enabled the defer mode on. Do you have any idea ? -- Nicolas Grenèche Old blog : http://blog.etcshadow.fr New blog : http://nsm.etcshadow.fr Tel : 01 49 40 40 35 Fax : 01 48 22 81 50