From owner-freebsd-pf@FreeBSD.ORG Thu Jun 18 09:00:27 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 586B2795 for ; Thu, 18 Jun 2015 09:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 42C45E90 for ; Thu, 18 Jun 2015 09:00:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5I90Rxw090254 for ; Thu, 18 Jun 2015 09:00:27 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 183198] [pf] pf tables not loaded if only used inside anchor Date: Thu, 18 Jun 2015 09:00:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.0-BETA1 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: krichy@cflinux.hu X-Bugzilla-Status: In Progress X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 09:00:27 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183198 --- Comment #7 from krichy@cflinux.hu --- Is there any updates regarding this report? OpenBSD has already accepted the patch. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 18 09:01:03 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C26118C3 for ; Thu, 18 Jun 2015 09:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AD268EC6 for ; Thu, 18 Jun 2015 09:01:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5I913uO002383 for ; Thu, 18 Jun 2015 09:01:03 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 196314] pf nested inline anchors does not work Date: Thu, 18 Jun 2015 09:01:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: krichy@cflinux.hu X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 09:01:03 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196314 --- Comment #1 from krichy@cflinux.hu --- Any updates on this bug report? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 18 09:02:08 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 016F1930 for ; Thu, 18 Jun 2015 09:02:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E028DF1F for ; Thu, 18 Jun 2015 09:02:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5I927OS042589 for ; Thu, 18 Jun 2015 09:02:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 197484] fix pf 3whs ACK handling Date: Thu, 18 Jun 2015 09:02:08 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: krichy@cflinux.hu X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-pf@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 09:02:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197484 --- Comment #1 from krichy@cflinux.hu --- Any updates on this? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-pf@FreeBSD.ORG Thu Jun 18 15:53:37 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0A25BB0A for ; Thu, 18 Jun 2015 15:53:37 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA4FD908 for ; Thu, 18 Jun 2015 15:53:36 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t5IFranl003809 for ; Thu, 18 Jun 2015 15:53:36 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t5IFraWo003805; Thu, 18 Jun 2015 15:53:36 GMT (envelope-from daemon-user) Date: Thu, 18 Jun 2015 15:53:36 +0000 To: freebsd-pf@freebsd.org From: "nvass-gmx.com (Nikos Vassiliadis)" Reply-to: D1944+331+90181aefda88703e@FreeBSD.org Subject: [Differential] [Updated, 170 lines] D1944: PF and VIMAGE fixes Message-ID: <0f1c72a4a2ff12f041db4bba0b930ff9@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFWC6YA= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_0f1c72a4a2ff12f041db4bba0b930ff9" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 15:53:37 -0000 --b1_0f1c72a4a2ff12f041db4bba0b930ff9 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: 8bit nvass-gmx.com updated this revision to Diff 6288. nvass-gmx.com added a comment. Updated to today's head branch. Please review CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1944?vs=5290&id=6288 REVISION DETAIL https://reviews.freebsd.org/D1944 AFFECTED FILES sys/net/pfvar.h sys/netpfil/pf/pf.c sys/netpfil/pf/pf_if.c sys/netpfil/pf/pf_ioctl.c sys/netpfil/pf/pf_norm.c EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, kristof, gnn, glebius, rodrigc Cc: julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list --b1_0f1c72a4a2ff12f041db4bba0b930ff9 Content-Type: text/x-patch; charset=utf-8; name="D1944.6288.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D1944.6288.patch" ZGlmZiAtLWdpdCBhL3N5cy9uZXRwZmlsL3BmL3BmX25vcm0uYyBiL3N5cy9uZXRwZmlsL3BmL3Bm X25vcm0uYwotLS0gYS9zeXMvbmV0cGZpbC9wZi9wZl9ub3JtLmMKKysrIGIvc3lzL25ldHBmaWwv cGYvcGZfbm9ybS5jCkBAIC0xODAsNyArMTgwLDcgQEAKICNlbmRpZgkvKiBJTkVUICovCiAKIHZv aWQKLXBmX25vcm1hbGl6ZV9pbml0KHZvaWQpCitwZl92bmV0X25vcm1hbGl6ZV9pbml0KHZvaWQp CiB7CiAKIAlWX3BmX2ZyYWdfeiA9IHVtYV96Y3JlYXRlKCJwZiBmcmFncyIsIHNpemVvZihzdHJ1 Y3QgcGZfZnJhZ21lbnQpLApkaWZmIC0tZ2l0IGEvc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwuYyBi L3N5cy9uZXRwZmlsL3BmL3BmX2lvY3RsLmMKLS0tIGEvc3lzL25ldHBmaWwvcGYvcGZfaW9jdGwu YworKysgYi9zeXMvbmV0cGZpbC9wZi9wZl9pb2N0bC5jCkBAIC04Nyw3ICs4Nyw4IEBACiAjaW5j bHVkZSA8bmV0L2FsdHEvYWx0cS5oPgogI2VuZGlmCiAKLXN0YXRpYyBpbnQJCSBwZmF0dGFjaCh2 b2lkKTsKK3N0YXRpYyBpbnQJCSBwZl92bmV0X2luaXQodm9pZCk7CitzdGF0aWMgaW50CQkgcGZf dm5ldF91bmluaXQodm9pZCk7CiBzdGF0aWMgc3RydWN0IHBmX3Bvb2wJKnBmX2dldF9wb29sKGNo YXIgKiwgdV9pbnQzMl90LCB1X2ludDhfdCwgdV9pbnQzMl90LAogCQkJICAgIHVfaW50OF90LCB1 X2ludDhfdCwgdV9pbnQ4X3QpOwogCkBAIC0xNDksNiArMTUwLDcgQEAKICNkZWZpbmUgRFBGUFJJ TlRGKG4sIHgpIGlmIChWX3BmX3N0YXR1cy5kZWJ1ZyA+PSAobikpIHByaW50ZiB4CiAKIHN0cnVj dCBjZGV2ICpwZl9kZXY7CitpbnQgbnVtYmVyX29mX3ZuZXRzID0gMDsKIAogLyoKICAqIFhYWCAt IFRoZXNlIGFyZSBuZXcgYW5kIG5lZWQgdG8gYmUgY2hlY2tlZCB3aGVuIG1vdmVpbmcgdG8gYSBu ZXcgdmVyc2lvbgpAQCAtMjA1LDE3ICsyMDcsMTYgQEAKIHBmbG9nX3BhY2tldF90CQkJKnBmbG9n X3BhY2tldF9wdHIgPSBOVUxMOwogCiBzdGF0aWMgaW50Ci1wZmF0dGFjaCh2b2lkKQorcGZfdm5l dF9pbml0KHZvaWQpCiB7CiAJdV9pbnQzMl90ICpteV90aW1lb3V0ID0gVl9wZl9kZWZhdWx0X3J1 bGUudGltZW91dDsKIAlpbnQgZXJyb3I7CiAKLQlpZiAoSVNfREVGQVVMVF9WTkVUKGN1cnZuZXQp KQotCQlwZl9tdGFnX2luaXRpYWxpemUoKTsKLQlwZl9pbml0aWFsaXplKCk7CisJbnVtYmVyX29m X3ZuZXRzKys7CisJcGZfdm5ldF9pbml0aWFsaXplKCk7CiAJcGZyX2luaXRpYWxpemUoKTsKLQlw ZmlfaW5pdGlhbGl6ZSgpOwotCXBmX25vcm1hbGl6ZV9pbml0KCk7CisJcGZpX3ZuZXRfaW5pdGlh bGl6ZSgpOworCXBmX3ZuZXRfbm9ybWFsaXplX2luaXQoKTsKIAogCVZfcGZfbGltaXRzW1BGX0xJ TUlUX1NUQVRFU10ubGltaXQgPSBQRlNUQVRFX0hJV0FUOwogCVZfcGZfbGltaXRzW1BGX0xJTUlU X1NSQ19OT0RFU10ubGltaXQgPSBQRlNOT0RFX0hJV0FUOwpAQCAtMjg3LDcgKzI4OCw2MyBAQAog CiAJcmV0dXJuICgwKTsKIH0KK1ZORVRfU1lTSU5JVChwZl92bmV0X2luaXQsIFNJX1NVQl9QUk9U T19JRkFUVEFDSERPTUFJTiwgU0lfT1JERVJfQU5ZIC0gMjU1LAorICAgIHBmX3ZuZXRfaW5pdCwg TlVMTCk7CiAKK3N0YXRpYyBpbnQKK3BmX3ZuZXRfdW5pbml0KHZvaWQpCit7CisJaW50IGVycm9y ID0gMDsKKworCW51bWJlcl9vZl92bmV0cy0tOworCUtBU1NFUlQobnVtYmVyX29mX3ZuZXRzID49 IDAsICgibnVtYmVyIG9mIHZuZXRzIDwgMCIpKTsKKworCVBGX1JVTEVTX1JMT0NLKCk7CisJVl9w Zl9lbmRfdGhyZWFkcysrOworCVBGX1JVTEVTX1JVTkxPQ0soKTsKKwl3YWtldXAocGZfcHVyZ2Vf dGhyZWFkKTsKKwl3aGlsZSAoVl9wZl9lbmRfdGhyZWFkcyA8IDIpCisJCXBhdXNlKCJwZnVubGQi LCBoeiAvIDkpOworCisJVl9wZl9zdGF0dXMucnVubmluZyA9IDA7CisJc3dpX3JlbW92ZShWX3Bm X3N3aV9jb29raWUpOworCWVycm9yID0gZGVob29rX3BmKCk7CisJaWYgKGVycm9yKSB7CisJCS8q CisJCSAqIFNob3VsZCBub3QgaGFwcGVuIQorCQkgKiBYWFggRHVlIHRvIGVycm9yIGNvZGUgRVNS Q0gsIGtsZHVubG9hZCB3aWxsIHNob3cKKwkJICogYSBtZXNzYWdlIGxpa2UgJ05vIHN1Y2ggcHJv Y2VzcycuCisJCSAqLworCQlwcmludGYoIiVzIDogcGZpbCB1bnJlZ2lzdGVyYXRpb24gZmFpbFxu IiwgX19GVU5DVElPTl9fKTsKKwkJcmV0dXJuIGVycm9yOworCX0KKwlQRl9SVUxFU19XTE9DSygp OworCXNodXRkb3duX3BmKCk7CisJcGZfbm9ybWFsaXplX2NsZWFudXAoKTsKKwlwZmlfY2xlYW51 cCgpOworCXBmcl9jbGVhbnVwKCk7CisJcGZfb3NmcF9mbHVzaCgpOworCXBmX2NsZWFudXAoKTsK KworCS8qCisJICogRm9yIHRoZSBsYXN0IFZORVQgd2UgcGVyZm9ybSB0aGUgZmluYWwgY2xlYW51 cAorCSAqLworCWlmIChudW1iZXJfb2Zfdm5ldHMgPT0gMCkgeworCQlwZl91bmluaXRfZXZlbnRo YW5kbGVycygpOworCQlwZl9tdGFnX2NsZWFudXAoKTsKKwl9CisJUEZfUlVMRVNfV1VOTE9DSygp OworCWlmIChudW1iZXJfb2Zfdm5ldHMgPT0gMCkgeworCQlkZXN0cm95X2RldihwZl9kZXYpOwor CQlyd19kZXN0cm95KCZwZl9ydWxlc19sb2NrKTsKKwkJc3hfZGVzdHJveSgmcGZfaW9jdGxfbG9j ayk7CisJfQorCisJcmV0dXJuIChlcnJvcik7Cit9CitWTkVUX1NZU1VOSU5JVChwZl92bmV0X3Vu aW5pdCwgU0lfU1VCX1BST1RPX0lGQVRUQUNIRE9NQUlOLCBTSV9PUkRFUl9BTlkgLSAyNTUsCisg ICAgcGZfdm5ldF91bmluaXQsIE5VTEwpOworCiBzdGF0aWMgc3RydWN0IHBmX3Bvb2wgKgogcGZf Z2V0X3Bvb2woY2hhciAqYW5jaG9yLCB1X2ludDMyX3QgdGlja2V0LCB1X2ludDhfdCBydWxlX2Fj dGlvbiwKICAgICB1X2ludDMyX3QgcnVsZV9udW1iZXIsIHVfaW50OF90IHJfbGFzdCwgdV9pbnQ4 X3QgYWN0aXZlLApAQCAtMzcwNywyNyArMzc2NCwxMiBAQAogc3RhdGljIGludAogcGZfbG9hZCh2 b2lkKQogewotCWludCBlcnJvcjsKIAotCVZORVRfSVRFUkFUT1JfREVDTCh2bmV0X2l0ZXIpOwot Ci0JVk5FVF9MSVNUX1JMT0NLKCk7Ci0JVk5FVF9GT1JFQUNIKHZuZXRfaXRlcikgewotCQlDVVJW TkVUX1NFVCh2bmV0X2l0ZXIpOwotCQlWX3BmX3BmaWxfaG9va2VkID0gMDsKLQkJVl9wZl9lbmRf dGhyZWFkcyA9IDA7Ci0JCVRBSUxRX0lOSVQoJlZfcGZfdGFncyk7Ci0JCVRBSUxRX0lOSVQoJlZf cGZfcWlkcyk7Ci0JCUNVUlZORVRfUkVTVE9SRSgpOwotCX0KLQlWTkVUX0xJU1RfUlVOTE9DSygp OwotCiAJcndfaW5pdCgmcGZfcnVsZXNfbG9jaywgInBmIHJ1bGVzZXRzIik7CiAJc3hfaW5pdCgm cGZfaW9jdGxfbG9jaywgInBmIGlvY3RsIik7Ci0KIAlwZl9kZXYgPSBtYWtlX2RldigmcGZfY2Rl dnN3LCAwLCAwLCAwLCAwNjAwLCBQRl9OQU1FKTsKLQlpZiAoKGVycm9yID0gcGZhdHRhY2goKSkg IT0gMCkKLQkJcmV0dXJuIChlcnJvcik7CisJcGZfbXRhZ19pbml0aWFsaXplKCk7CisgICAgICAg IHBmX2luaXRfZXZlbnRoYW5kbGVycygpOwogCiAJcmV0dXJuICgwKTsKIH0KQEAgLTM3MzUsNDAg KzM3NzcsOCBAQAogc3RhdGljIGludAogcGZfdW5sb2FkKHZvaWQpCiB7Ci0JaW50IGVycm9yID0g MDsKIAotCVZfcGZfc3RhdHVzLnJ1bm5pbmcgPSAwOwotCXN3aV9yZW1vdmUoVl9wZl9zd2lfY29v a2llKTsKLQllcnJvciA9IGRlaG9va19wZigpOwotCWlmIChlcnJvcikgewotCQkvKgotCQkgKiBT aG91bGQgbm90IGhhcHBlbiEKLQkJICogWFhYIER1ZSB0byBlcnJvciBjb2RlIEVTUkNILCBrbGR1 bmxvYWQgd2lsbCBzaG93Ci0JCSAqIGEgbWVzc2FnZSBsaWtlICdObyBzdWNoIHByb2Nlc3MnLgot CQkgKi8KLQkJcHJpbnRmKCIlcyA6IHBmaWwgdW5yZWdpc3RlcmF0aW9uIGZhaWxcbiIsIF9fRlVO Q1RJT05fXyk7Ci0JCXJldHVybiBlcnJvcjsKLQl9Ci0JUEZfUlVMRVNfV0xPQ0soKTsKLQlzaHV0 ZG93bl9wZigpOwotCVZfcGZfZW5kX3RocmVhZHMgPSAxOwotCXdoaWxlIChWX3BmX2VuZF90aHJl YWRzIDwgMikgewotCQl3YWtldXBfb25lKHBmX3B1cmdlX3RocmVhZCk7Ci0JCXJ3X3NsZWVwKHBm X3B1cmdlX3RocmVhZCwgJnBmX3J1bGVzX2xvY2ssIDAsICJwZnRtbyIsIDApOwotCX0KLQlQRl9S VUxFU19XVU5MT0NLKCk7Ci0JcGZfbm9ybWFsaXplX2NsZWFudXAoKTsKLQlwZmlfY2xlYW51cCgp OwotCXBmcl9jbGVhbnVwKCk7Ci0JcGZfb3NmcF9mbHVzaCgpOwotCXBmX2NsZWFudXAoKTsKLQlp ZiAoSVNfREVGQVVMVF9WTkVUKGN1cnZuZXQpKQotCQlwZl9tdGFnX2NsZWFudXAoKTsKLQlkZXN0 cm95X2RldihwZl9kZXYpOwotCXJ3X2Rlc3Ryb3koJnBmX3J1bGVzX2xvY2spOwotCXN4X2Rlc3Ry b3koJnBmX2lvY3RsX2xvY2spOwotCi0JcmV0dXJuIChlcnJvcik7CisJcmV0dXJuICgwKTsKIH0K IAogc3RhdGljIGludApkaWZmIC0tZ2l0IGEvc3lzL25ldHBmaWwvcGYvcGZfaWYuYyBiL3N5cy9u ZXRwZmlsL3BmL3BmX2lmLmMKLS0tIGEvc3lzL25ldHBmaWwvcGYvcGZfaWYuYworKysgYi9zeXMv bmV0cGZpbC9wZi9wZl9pZi5jCkBAIC0xMDcsNyArMTA3LDcgQEAKICAgICBNVFhfREVGKTsKIAog dm9pZAotcGZpX2luaXRpYWxpemUodm9pZCkKK3BmaV92bmV0X2luaXRpYWxpemUodm9pZCkKIHsK IAlzdHJ1Y3QgaWZnX2dyb3VwICppZmc7CiAJc3RydWN0IGlmbmV0ICppZnA7CkBAIC0xMjMsMTYg KzEyMywyNCBAQAogCVBGX1JVTEVTX1dVTkxPQ0soKTsKIAogCUlGTkVUX1JMT0NLKCk7Ci0JVEFJ TFFfRk9SRUFDSChpZmcsICZWX2lmZ19oZWFkLCBpZmdfbmV4dCkKKwlUQUlMUV9GT1JFQUNIKGlm ZywgJlZfaWZnX2hlYWQsIGlmZ19uZXh0KSB7CiAJCXBmaV9hdHRhY2hfaWZncm91cChpZmcpOwot CVRBSUxRX0ZPUkVBQ0goaWZwLCAmVl9pZm5ldCwgaWZfbGluaykKKwl9CisJVEFJTFFfRk9SRUFD SChpZnAsICZWX2lmbmV0LCBpZl9saW5rKSB7CisJCUNVUlZORVRfU0VUKGlmcC0+aWZfdm5ldCk7 CiAJCXBmaV9hdHRhY2hfaWZuZXQoaWZwKTsKKwkJQ1VSVk5FVF9SRVNUT1JFKCk7CisJfQogCUlG TkVUX1JVTkxPQ0soKTsKK30KIAordm9pZAorcGZfaW5pdF9ldmVudGhhbmRsZXJzKHZvaWQpIHsK KwogCXBmaV9hdHRhY2hfY29va2llID0gRVZFTlRIQU5ETEVSX1JFR0lTVEVSKGlmbmV0X2Fycml2 YWxfZXZlbnQsCi0JICAgIHBmaV9hdHRhY2hfaWZuZXRfZXZlbnQsIE5VTEwsIEVWRU5USEFORExF Ul9QUklfQU5ZKTsKKwkgICAgcGZpX2F0dGFjaF9pZm5ldF9ldmVudCwgY3Vydm5ldCwgRVZFTlRI QU5ETEVSX1BSSV9BTlkpOwogCXBmaV9kZXRhY2hfY29va2llID0gRVZFTlRIQU5ETEVSX1JFR0lT VEVSKGlmbmV0X2RlcGFydHVyZV9ldmVudCwKLQkgICAgcGZpX2RldGFjaF9pZm5ldF9ldmVudCwg TlVMTCwgRVZFTlRIQU5ETEVSX1BSSV9BTlkpOworCSAgICBwZmlfZGV0YWNoX2lmbmV0X2V2ZW50 LCBjdXJ2bmV0LCBFVkVOVEhBTkRMRVJfUFJJX0FOWSk7CiAJcGZpX2F0dGFjaF9ncm91cF9jb29r aWUgPSBFVkVOVEhBTkRMRVJfUkVHSVNURVIoZ3JvdXBfYXR0YWNoX2V2ZW50LAogCSAgICBwZmlf YXR0YWNoX2dyb3VwX2V2ZW50LCBjdXJ2bmV0LCBFVkVOVEhBTkRMRVJfUFJJX0FOWSk7CiAJcGZp X2NoYW5nZV9ncm91cF9jb29raWUgPSBFVkVOVEhBTkRMRVJfUkVHSVNURVIoZ3JvdXBfY2hhbmdl X2V2ZW50LApAQCAtMTQwLDEzICsxNDgsMTEgQEAKIAlwZmlfZGV0YWNoX2dyb3VwX2Nvb2tpZSA9 IEVWRU5USEFORExFUl9SRUdJU1RFUihncm91cF9kZXRhY2hfZXZlbnQsCiAJICAgIHBmaV9kZXRh Y2hfZ3JvdXBfZXZlbnQsIGN1cnZuZXQsIEVWRU5USEFORExFUl9QUklfQU5ZKTsKIAlwZmlfaWZh ZGRyX2V2ZW50X2Nvb2tpZSA9IEVWRU5USEFORExFUl9SRUdJU1RFUihpZmFkZHJfZXZlbnQsCi0J ICAgIHBmaV9pZmFkZHJfZXZlbnQsIE5VTEwsIEVWRU5USEFORExFUl9QUklfQU5ZKTsKKwkgICAg cGZpX2lmYWRkcl9ldmVudCwgY3Vydm5ldCwgRVZFTlRIQU5ETEVSX1BSSV9BTlkpOwogfQogCiB2 b2lkCi1wZmlfY2xlYW51cCh2b2lkKQotewotCXN0cnVjdCBwZmlfa2lmICpwOworcGZfdW5pbml0 X2V2ZW50aGFuZGxlcnModm9pZCkgewogCiAJRVZFTlRIQU5ETEVSX0RFUkVHSVNURVIoaWZuZXRf YXJyaXZhbF9ldmVudCwgcGZpX2F0dGFjaF9jb29raWUpOwogCUVWRU5USEFORExFUl9ERVJFR0lT VEVSKGlmbmV0X2RlcGFydHVyZV9ldmVudCwgcGZpX2RldGFjaF9jb29raWUpOwpAQCAtMTU0LDcg KzE2MCwxMyBAQAogCUVWRU5USEFORExFUl9ERVJFR0lTVEVSKGdyb3VwX2NoYW5nZV9ldmVudCwg cGZpX2NoYW5nZV9ncm91cF9jb29raWUpOwogCUVWRU5USEFORExFUl9ERVJFR0lTVEVSKGdyb3Vw X2RldGFjaF9ldmVudCwgcGZpX2RldGFjaF9ncm91cF9jb29raWUpOwogCUVWRU5USEFORExFUl9E RVJFR0lTVEVSKGlmYWRkcl9ldmVudCwgcGZpX2lmYWRkcl9ldmVudF9jb29raWUpOworfQogCit2 b2lkCitwZmlfY2xlYW51cCh2b2lkKQoreworCXN0cnVjdCBwZmlfa2lmICpwOworCiAJVl9wZmlf YWxsID0gTlVMTDsKIAl3aGlsZSAoKHAgPSBSQl9NSU4ocGZpX2lmaGVhZCwgJlZfcGZpX2lmcykp KSB7CiAJCVJCX1JFTU9WRShwZmlfaWZoZWFkLCAmVl9wZmlfaWZzLCBwKTsKQEAgLTgxMSw5ICs4 MjMsNyBAQAogcGZpX2F0dGFjaF9ncm91cF9ldmVudCh2b2lkICphcmcgLCBzdHJ1Y3QgaWZnX2dy b3VwICppZmcpCiB7CiAKLQlDVVJWTkVUX1NFVCgoc3RydWN0IHZuZXQgKilhcmcpOwogCXBmaV9h dHRhY2hfaWZncm91cChpZmcpOwotCUNVUlZORVRfUkVTVE9SRSgpOwogfQogCiBzdGF0aWMgdm9p ZApAQCAtODIzLDEzICs4MzMsMTEgQEAKIAogCWtpZiA9IG1hbGxvYyhzaXplb2YoKmtpZiksIFBG SV9NVFlQRSwgTV9XQUlUT0spOwogCi0JQ1VSVk5FVF9TRVQoKHN0cnVjdCB2bmV0ICopYXJnKTsK IAlQRl9SVUxFU19XTE9DSygpOwogCVZfcGZpX3VwZGF0ZSsrOwogCWtpZiA9IHBmaV9raWZfYXR0 YWNoKGtpZiwgZ25hbWUpOwogCXBmaV9raWZfdXBkYXRlKGtpZik7CiAJUEZfUlVMRVNfV1VOTE9D SygpOwotCUNVUlZORVRfUkVTVE9SRSgpOwogfQogCiBzdGF0aWMgdm9pZApkaWZmIC0tZ2l0IGEv c3lzL25ldHBmaWwvcGYvcGYuYyBiL3N5cy9uZXRwZmlsL3BmL3BmLmMKLS0tIGEvc3lzL25ldHBm aWwvcGYvcGYuYworKysgYi9zeXMvbmV0cGZpbC9wZi9wZi5jCkBAIC03NTQsNyArNzU0LDcgQEAK IAogLyogUGVyLXZuZXQgZGF0YSBzdG9yYWdlIHN0cnVjdHVyZXMgaW5pdGlhbGl6YXRpb24uICov CiB2b2lkCi1wZl9pbml0aWFsaXplKCkKK3BmX3ZuZXRfaW5pdGlhbGl6ZSgpCiB7CiAJc3RydWN0 IHBmX2tleWhhc2gJKmtoOwogCXN0cnVjdCBwZl9pZGhhc2gJKmloOwpkaWZmIC0tZ2l0IGEvc3lz L25ldC9wZnZhci5oIGIvc3lzL25ldC9wZnZhci5oCi0tLSBhL3N5cy9uZXQvcGZ2YXIuaAorKysg Yi9zeXMvbmV0L3BmdmFyLmgKQEAgLTE0OTQsNyArMTQ5NCw5IEBACiBWTkVUX0RFQ0xBUkUoc3Ry dWN0IHBmX3J1bGVxdWV1ZSwgcGZfdW5saW5rZWRfcnVsZXMpOwogI2RlZmluZQlWX3BmX3VubGlu a2VkX3J1bGVzCVZORVQocGZfdW5saW5rZWRfcnVsZXMpCiAKLXZvaWQJCQkJIHBmX2luaXRpYWxp emUodm9pZCk7Cit2b2lkCQkJCSBwZl9pbml0X2V2ZW50aGFuZGxlcnModm9pZCk7Cit2b2lkCQkJ CSBwZl91bmluaXRfZXZlbnRoYW5kbGVycyh2b2lkKTsKK3ZvaWQJCQkJIHBmX3ZuZXRfaW5pdGlh bGl6ZSh2b2lkKTsKIHZvaWQJCQkJIHBmX210YWdfaW5pdGlhbGl6ZSh2b2lkKTsKIHZvaWQJCQkJ IHBmX210YWdfY2xlYW51cCh2b2lkKTsKIHZvaWQJCQkJIHBmX2NsZWFudXAodm9pZCk7CkBAIC0x NTkwLDcgKzE1OTIsNyBAQAogCSAgICBzdHJ1Y3QgcGZfYWRkciAqLCBzYV9mYW1pbHlfdCk7CiBp bnQJcGZfbWF0Y2hfcG9ydCh1X2ludDhfdCwgdV9pbnQxNl90LCB1X2ludDE2X3QsIHVfaW50MTZf dCk7CiAKLXZvaWQJcGZfbm9ybWFsaXplX2luaXQodm9pZCk7Cit2b2lkCXBmX3ZuZXRfbm9ybWFs aXplX2luaXQodm9pZCk7CiB2b2lkCXBmX25vcm1hbGl6ZV9jbGVhbnVwKHZvaWQpOwogaW50CXBm X25vcm1hbGl6ZV90Y3AoaW50LCBzdHJ1Y3QgcGZpX2tpZiAqLCBzdHJ1Y3QgbWJ1ZiAqLCBpbnQs IGludCwgdm9pZCAqLAogCSAgICBzdHJ1Y3QgcGZfcGRlc2MgKik7CkBAIC0xNjQ4LDcgKzE2NTAs NyBAQAogVk5FVF9ERUNMQVJFKHN0cnVjdCBwZmlfa2lmICosCQkgcGZpX2FsbCk7CiAjZGVmaW5l CVZfcGZpX2FsbAkgCQkgVk5FVChwZmlfYWxsKQogCi12b2lkCQkgcGZpX2luaXRpYWxpemUodm9p ZCk7Cit2b2lkCQkgcGZpX3ZuZXRfaW5pdGlhbGl6ZSh2b2lkKTsKIHZvaWQJCSBwZmlfY2xlYW51 cCh2b2lkKTsKIHZvaWQJCSBwZmlfa2lmX3JlZihzdHJ1Y3QgcGZpX2tpZiAqKTsKIHZvaWQJCSBw Zmlfa2lmX3VucmVmKHN0cnVjdCBwZmlfa2lmICopOwoK --b1_0f1c72a4a2ff12f041db4bba0b930ff9-- From owner-freebsd-pf@FreeBSD.ORG Thu Jun 18 21:24:35 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 158C49DA for ; Thu, 18 Jun 2015 21:24:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F3555847 for ; Thu, 18 Jun 2015 21:24:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5ILOYAB026108 for ; Thu, 18 Jun 2015 21:24:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-pf@FreeBSD.org Subject: [Bug 200330] panic: pf_addr_cmp: unknown address family 0 when scrub fragment drop-ovl is used Date: Thu, 18 Jun 2015 21:24:35 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: kp@freebsd.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 21:24:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200330 --- Comment #19 from commit-hook@freebsd.org --- A commit references this bug: Author: kp Date: Thu Jun 18 21:23:42 UTC 2015 New revision: 284580 URL: https://svnweb.freebsd.org/changeset/base/284580 Log: Merge r284222, r284260 pf: address family must be set when creating a pf_fragment Fix a panic when handling fragmented ip4 packets with 'drop-ovl' set. In that scenario we take a different branch in pf_normalize_ip(), taking us to pf_fragcache() (rather than pf_reassemble()). In pf_fragcache() we create a pf_fragment, but do not set the address family. This leads to a panic when we try to insert that into pf_frag_tree because pf_addr_cmp(), which is used to compare the pf_fragments doesn't know what to do if the address family is not set. Simply ensure that the address family is set correctly (always AF_INET in this path). When we try to look up a pf_fragment with pf_find_fragment() we compare (see pf_frag_compare()) addresses (and family), but also protocol. We failed to save the protocol to the pf_fragment in pf_fragcache(), resulting in failing reassembly. PR: 200330 Differential Revision: https://reviews.freebsd.org/D2824 Reviewed by: gnn Changes: _U stable/10/ stable/10/sys/netpfil/pf/pf_norm.c -- You are receiving this mail because: You are on the CC list for the bug. From owner-freebsd-pf@FreeBSD.ORG Fri Jun 19 04:50:43 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 16C4D83E for ; Fri, 19 Jun 2015 04:50:43 +0000 (UTC) (envelope-from chuck@mantis.biz) Received: from zip.c7hosting.com (zip.c7hosting.com [96.47.41.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3797DFB for ; Fri, 19 Jun 2015 04:50:42 +0000 (UTC) (envelope-from chuck@mantis.biz) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mantis.biz; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Nm0M+AFab9TkxN/xhYdc9y0/Pmrbaqukkad7NlqbDB0=; b=EO3HcsaXm0gZxNVhpoPAjUTWzULinO+ZpyPq2oJ2h+6ADybHi4sqqIRXIw8VnlMB82RDiKH1OrttkYcKG3pgKLlM9wgmQvmO+44+zThxGfp/m8sehGCRf5V1H0xZN111; Received: from toroon4213w-lp130-04-1176445566.dsl.bell.ca ([70.31.34.126]:64992 helo=[192.168.2.13]) by zip.c7hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1Z5ncx-0008JW-7U for freebsd-pf@freebsd.org; Fri, 19 Jun 2015 00:10:03 -0400 Message-ID: <55839619.8000603@mantis.biz> Date: Fri, 19 Jun 2015 00:10:01 -0400 From: "Chuck @ Mantis" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: adding an additional block & gateway Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - zip.c7hosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mantis.biz X-Get-Message-Sender-Via: zip.c7hosting.com: authenticated_id: chuck@mantis.biz X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 04:50:43 -0000 I'm currently using FreeBSD and PF as a gateway and firewall in front of a handful of web servers. External: defaultrouter="79.112.227.33" ifconfig_bge0="inet 79.112.227.34 netmask 255.255.255.224" I've asked the datacenter for an additional block and received: Gateway : 60.34.75.209 IP block : 60.34.75.208/28 Subnet : 255.255.255.240 Since the gateways are different, I'm assuming I need to use PF or BSD to somehow direct (route?) traffic which came via the new block out through the new gateway? Do I need an additional NIC or would aliases work? Where should the routing rules happen (freebsd routes or in pf somehow)? Thank you for any advice (1st post here) From owner-freebsd-pf@FreeBSD.ORG Fri Jun 19 07:11:18 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF07D55F; Fri, 19 Jun 2015 07:11:18 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from mail.tyknet.dk (mail.tyknet.dk [IPv6:2a01:4f8:201:2327:144:76:253:226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7382F2A2; Fri, 19 Jun 2015 07:11:17 +0000 (UTC) (envelope-from thomas@gibfest.dk) Received: from [10.10.2.24] (217.71.4.82.static.router4.bolignet.dk [217.71.4.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.tyknet.dk (Postfix) with ESMTPSA id 9920549BA84; Fri, 19 Jun 2015 07:11:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.9.2 mail.tyknet.dk 9920549BA84 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gibfest.dk; s=default; t=1434697866; bh=9O/3KKSYe3y7yOGxc4tSnT0ndMkD2m6EbdPDxAYgbtM=; h=To:From:Subject:Date; b=wGyGAGQnr+XEIzgJUP+3S2j/oJMOjWgkEVOOOoYyiBJIHgVUjOFPmyDvzFHBQADN/ i0kQhVKqzNrA2XX7WU3Uw1dyNF25f4kNRqecrxhnBKOY/Jt1XDS0RU0VOi66HfBJe5 mYR7xfZbYk+FpNsH3ohd2sugSdQwmIA27tV4sN3jqWzOYGlOPedt/jNpkuNEnOVlDx y19VRMm+U/It7I0q9QwCbhB88wP9+VpiPHbSMG13AE00m2UaN1TQ/YOHziIy0ykfJf XtuXqaduyFQJhP5wV1Zof4jG2giqa6vIp/V1N9PoM5SOt8e7lABS7ceHWUQDPP4mvp iIXvVSEGYrx8Q== To: freebsd-net@freebsd.org, freebsd-pf@freebsd.org From: Thomas Steen Rasmussen Subject: Issue with routing table entries, jails and pf filtering on loopback interfaces X-Enigmail-Draft-Status: N1110 Message-ID: <5583C089.8090507@gibfest.dk> Date: Fri, 19 Jun 2015 09:11:05 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 07:11:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =20 Hello list, This will be a long post, apologies, but it is a complex issue. First I will explain how the server is configured, then I will explain the problem and the workaround I found. When I add one or more IP aliases to a non-loopback interface, lagg0 in this example, FreeBSD adds two routing table entries per IP: 185.96.88.18 link#6 UHS lo0 185.96.88.18/32 link#6 U lagg0 The first entry, the one with "lo0" as it's interface is the problem. The server also has an extra loopback interface with rfc1918 addresses for jails that do not need a real, public IP. A pretty common setup. I also run pf on the server, first filtering rule is "block log all" so I explicitly need to permit traffic on every interface (I do "set skip on lo0" though). I permit all outgoing traffic both on lo1 and on lagg0, so only incoming traffic needs to be permitted. The problem is that with this setup an rfc1918 jail _cannot_ establish a TCP connection to a service listening on an IP on the lagg0 interface. I think this is because the "lo0" routing table entry forces the traffic through an interface where it logically should not appear. The symptom: When I try to ssh from a jail with an rfc1918 IP (say 10.0.0.1) on lo1 to a jail with IP 185.96.88.18 on lagg0, then pf blocks the traffic, but not as I'd expect. I'd expect it to block an incoming packet on lagg0 from the rfc1918 ip to the jailhosts IP. Instead it blocks the syn/ack packet, but in the wrong direction, check this tcpdump from pflog= 0: 06:51:38.188170 rule 0..16777216/0(match): block out on lo1: 185.96.88.18.22 > 10.0.0.1.39228: Flags [S.], seq 573771477, ack 2565048197, win 65535, options [mss 16344,nop,wscale 6,sackOK,TS val 3503997415 ecr 53572243], length 0 This traffic should never appear in this direction on this interface. No wonder it gets blocked. The workaround: I've been able to workaround this issue by deleting the "lo0" routes for the IPs on lagg0. If I try SSH again everything looks correct again: 06:57:44.590356 rule 0..16777216/0(match): block in on lagg0: 10.0.0.1.48211 > 185.96.88.18.22: Flags [S], seq 3762725019, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 53938646 ecr 0], length 0 The syn packet is blocked where I'd expect it to get blocked, and if I permit 10.0.0.1 to SSH to 185.96.88.18 in pf.conf it works as expected. I've been asking around and it seems like I'm not the only one with this problem. People just do "set skip on lo1" and never notice it. From a security perspective though I really don't want traffic between jails to be unfirewalled. Can anyone shine a light on this? Thanks a bunch in advance :) Best regards Thomas Steen Rasmussen ps. For what it's worth OpenBSD adds an lo0 route for IP aliases on real interfaces too. No idea if the same problem is present though. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) =20 iQIcBAEBAgAGBQJVg8CJAAoJEHcv938JcvpY5gwQAIAvWW6WYbmhQcQK6CQ+Gqf4 jfkKasCoDFB7X4Fb+K2R7WViN2kt+u8IKO5iavnjQvz7A6Gfrn8LSfeHLCREDBRS IUROx2xPl0WDINhKeGgEdMHN9dldiG5XKJeZuZ0XSc2yPdP/nZGKcy0xBKc7GsPk uJ5CFt9xb9T+wngfySHHj39iKqQezEeYxJYrvtCB0ldq5Le1YQjGDr/fXm6xlV+Y 4UecXTMyU20T9ochJ4JIU+cVLVVjV/CZcnL5O4OWznIojt0y1FufMGpJ4ZPmXn8e xNz4efd5zlbA/e0BFO/OgIDlHlv09CELeudIitlnQniTyEmdRwpNF+Spw6hhsP20 6GEt3WXPbYFU22Y8/v4aN9Jb80kfRkY1Ts7naubLBc21JZZMOIWjKKeFfK8EjQlb wmduqqIdHcAqcEPkkZ5e3VLgqE6HrarbhaiEGHh9v90/BjMDXUoedUwa3DCTy0tO o6SiAGvphMU7s7UFjb6wvhfK7cAplbPNhyQkT8K2FIOU+WFzEvrqT9zXAwehI2pI sIk5v8K2cYevt+JHU7UPcun0NIR5iHfMTzhohs0TeEgPHcqZN9NgQji5i7seS9sN Rj9J4KwtctkGy0y/4yDf0I38IeL88n7NJBfpLr1cFxD8dv7t5mNXbKQSckfWvaqc sDso3GnRwzyvtrLj0zvA =3Dkt7G -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Fri Jun 19 07:24:12 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32823708 for ; Fri, 19 Jun 2015 07:24:12 +0000 (UTC) (envelope-from freebsd-pf@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C09807AD for ; Fri, 19 Jun 2015 07:24:10 +0000 (UTC) (envelope-from freebsd-pf@dino.sk) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 19 Jun 2015 09:18:58 +0200 id 00EB081E.5583C262.000002F6 Date: Fri, 19 Jun 2015 09:18:57 +0200 From: Milan Obuch To: freebsd-pf@freebsd.org Subject: Large scale NAT with PF - some weird problem Message-ID: <20150619091857.304b707b@zeta.dino.sk> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; i386-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 07:24:12 -0000 Hi, I am managing FreeBSD 9 based router for a network using PF for NAT. I think I can call it large scale - there is approximately 3000 customers' devices (home routers and similar) with private IPs in segment 172.16.0.0/12 translated to /23 public address block. Basically, in pf.conf, there is nat on $if_ext from $net_int to any -> $pool_ext round-robin sticky-address and handful of binat on $if_ext from 172.16.x.y to any -> a.b.c.d statements. It works, basically, but for some time now there are some intermitent outages. When it occurs, customer's device loses access to internet. I can verify it with simple ping to any address outside of the network. The weird thing is, I can see icmp request packets coming out of external interface, but no icmp echo packets coming back. While I can't verify on uplink router that these replies are actually coming in on interface, I am pretty sure it does, but they are not visible in tcpdump's output. (When I am pinging some device outside of the network, which is under my control, I can see there both icmp requests and icmp echo packets. Also, if I ping address to which thich ping is translated from outside, I see it on external interface coming in.) I think I have a problem with same table being too small, but no idea where it is. It is not state table, I have set limit states 500000 in my pf.conf, and pfctl -vs info tells State Table Total Rate current entries 36668 searches 1996138369 29280.5/s inserts 15757727 231.1/s removals 15770004 231.3/s so I think I have plenty of room here. It was set in past when issue a bit similar occured and using bigger state table solved it. Also, pfctl -vs state | grep shows states for not working ping as all icmp a.b.c.d:538 <- 172.16.x.y:538 0:0 all icmp e.f.g.h:40011 (172.16.x.y:538) -> a.b.c.d:40011 0:0 where a.b.c.d is address being used as ping target (outside of network), 172.16.x.y is address of device with trouble access to internet, and e.f.g.h is translated address for this device, allocated dynamically. After doing /etc/rc.d/pf restart if works again, so I think, again, issue is with some table being too small. Restart empties it and things begin to work. Does this sound familiar to anybody? I was trying to find some tuning guide for pf and large scale nat, but no success yet. I would be gratefull for any help. Regards, Milan From owner-freebsd-pf@FreeBSD.ORG Fri Jun 19 12:18:09 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 20FC3E86 for ; Fri, 19 Jun 2015 12:18:09 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [IPv6:2001:4f8:3:ffe0:406a:0:50:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 015B66C0 for ; Fri, 19 Jun 2015 12:18:09 +0000 (UTC) (envelope-from daemon-user@FreeBSD.org) Received: from phabric-backend.isc.freebsd.org (phabric-backend.isc.freebsd.org [127.0.1.5]) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9) with ESMTP id t5JCI8S7073456 for ; Fri, 19 Jun 2015 12:18:08 GMT (envelope-from daemon-user@phabric-backend.isc.freebsd.org) Received: (from daemon-user@localhost) by phabric-backend.isc.freebsd.org (8.14.9/8.14.9/Submit) id t5JCI8JS073453; Fri, 19 Jun 2015 12:18:08 GMT (envelope-from daemon-user) Date: Fri, 19 Jun 2015 12:18:08 +0000 To: freebsd-pf@freebsd.org From: "robak (Bartek Rutkowski)" Reply-to: D1944+331+90181aefda88703e@FreeBSD.org Subject: [Differential] [Commented On] D1944: PF and VIMAGE fixes Message-ID: <668eba77c3369103d1e7d3a3068e6c07@localhost.localdomain> X-Priority: 3 Thread-Topic: D1944: PF and VIMAGE fixes X-Herald-Rules: none X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: X-Phabricator-Cc: In-Reply-To: References: Thread-Index: NDc2NzM0MzY4OTdiYThiNTU1MjY2ZDZmMTJiIFWECIA= Precedence: bulk X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 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, 19 Jun 2015 12:18:09 -0000 robak added a comment. Is there any chance to get these changes committed in time for 10.2-RELEASE? It would be great if we could have working VNET/PF before 11.0-R comes out... REVISION DETAIL https://reviews.freebsd.org/D1944 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: nvass-gmx.com, bz, zec, trociny, kristof, gnn, glebius, rodrigc Cc: julian, robak, freebsd-virtualization-list, freebsd-pf-list, freebsd-net-list From owner-freebsd-pf@FreeBSD.ORG Fri Jun 19 13:01:53 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 28E6967A for ; Fri, 19 Jun 2015 13:01:53 +0000 (UTC) (envelope-from kajetan.staszkiewicz@innogames.com) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0098.outbound.protection.outlook.com [157.55.234.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A51D52C1 for ; Fri, 19 Jun 2015 13:01:51 +0000 (UTC) (envelope-from kajetan.staszkiewicz@innogames.com) Authentication-Results: freebsd.org; dkim=none (message not signed) header.d=none; Received: from energia.localnet (2a00:1f78:fffb:320:6af7:28ff:fe68:c1f6) by AM3PR03MB1250.eurprd03.prod.outlook.com (10.163.185.12) with Microsoft SMTP Server (TLS) id 15.1.195.15; Fri, 19 Jun 2015 13:01:43 +0000 From: Kajetan Staszkiewicz To: Subject: Re: adding an additional block & gateway Date: Fri, 19 Jun 2015 15:01:36 +0200 Message-ID: <1704069.kZvlBVo68Y@energia> Organization: InnoGames GmbH User-Agent: KMail/4.14.1 (Linux/3.19.0-trunk-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <55839619.8000603@mantis.biz> References: <55839619.8000603@mantis.biz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9199065.CFbrja4Pd6"; micalg=pgp-sha1; protocol="application/pgp-signature" X-Originating-IP: [2a00:1f78:fffb:320:6af7:28ff:fe68:c1f6] X-ClientProxiedBy: DB5PR06CA0021.eurprd06.prod.outlook.com (25.162.165.31) To AM3PR03MB1250.eurprd03.prod.outlook.com (25.163.185.12) X-Microsoft-Exchange-Diagnostics: 1; AM3PR03MB1250; 2:Qznja6WfdAtBIzJLSUJwn2HjCzyAJ0MqfJ9BtNvBe6zfg0ikge6ZleC+Jl77kV3h; 3:C/o81PERoOJFG5ms226kphFOZnrkDEAhBPxF2W2kYXU8Jrg+eTuYFUJ/5+y0JL3esuRWYJeSWyDtm5sk8meyumhrS41gKfsUpZOGzB/TF5V7h4RA7IfULqOMuM51y7Yx+LblSsF7ydaZssR88a3l0A==; 20:voFMTyCHs4NmGMAVD4aQ79WWc3GB5UrxUkPl20WK9mD4Xp3A99vcYcwhxBWJ1FuhA8rXs7AjArbl5FUh3AVQ+D/Vf6TesnhkG7K3JFwoGbi/AEOtUVXPpD+3B5YyGlDG3viMTpGkivl1MxqKE8JcqBPC+x8xjXnrb8ksxJY8eb7hi+l4FPHjN415DZ/fOMPINS3gwAN2uGMW8ttPTPgDw0CEhGJF34oko1qdEyTFm/upMJWOaH6pbYNt2ymnsTsSiBWerOvow4WN0PHDQJI0cByOfkmxA7jmnY1YekTDuwTVuWVSmoGkyeBo7JdwhNVwC7WDrokPGFXUgSEo+agFYIByratoOFUs2E9gHY069uXPUbsX1WovTqj9/m/h4RSs8VP1ORFQHIncb9SXwsmdXuFcDcSQBNMZIsaheOLPsV0=; 4:WUaSxh8RB8uDaXJBGE9tXwhXo31Va4pnJUTnVYq1boSfBHRZTZcAxo8jloc02axZTO3ArKRLY/NKjtKh1NyooEuDrDslsAvco74i2lR+mUKT7bqpKc84ffg0SS9eO6PmhElIFnmlHllPJm98iwRIp5j8mKcH7slTw4LNi37MzOgBY5PcrINB8DZ/0v5IenE1IwG+3t73tsVZmCGqYiLDdbonAKB81nQElC+f4fYLKhV3+UwO4jQX9f0t6Eq6fmLziRzxAV5Y+0mneYrelwjXHhVN32c3cRFE/80h7e9jUU0= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR03MB1250; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:AM3PR03MB1250; BCL:0; PCL:0; RULEID:; SRVR:AM3PR03MB1250; X-Forefront-PRVS: 0612E553B4 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(19580395003)(74482002)(46102003)(84326002)(2950100001)(77096005)(4001350100001)(33716001)(2351001)(512874002)(122386002)(50986999)(76176999)(54356999)(92566002)(83506001)(110136002)(42186005)(77156002)(62966003)(5001960100002)(40100003)(572594003)(87976001)(189998001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR03MB1250; H:energia.localnet; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; AM3PR03MB1250; 23:1iDk80KNwTOljKqvAtEdSW0B2i2BzJG9ObUUbLxLAc81h7DieoO5uaJ4QdW+qhIzSvp7pFfP8TIOj96lUQzssFDRNPK1T6FGR0UKW//NhVoM1B59Z7DBavV/NUcb0Om+WgD+ir3mDuVPeOCL10/FCJ8sg1dsP5PmBCQgb6MwsTVsLIHUussRaxpqMTZjnb2czMR6EY9l52GaU2/Gi6uaGaq6tht+/PXTXgtPJSH0mad2bK4OjkxlD/ofwpn6Tnnm5kQ47m/lw0sP/y4ghlmJ9tWP2O1qvJKPKv6kf1Wzt3DMPgzz/jRfvfChhp2rJGNCNCnS1KQyCxk+o4U2gmpdmTxbJEBVZg4LYL4HgWQdh9pIprRuoANIND6WPZB25BkcfDdK6xV0aYD2px3gBVx5Ww/ZwlPwrwsROgFzaWiB9aAKHx1xo2AvHle6zpSGurPvChWf4Ib8xwGAsd2HdEWRhp8GMR09Q6BqeOB3klec0VZC5KFqlbGF4ee8WjZeDFftqvoIem4+K2uzokUXtPKlQx+jeXX5CLVCdrWtCX9fhEE2xV5huiONtbM04jmsfpR4UP7QEhWnicxq7AKYSRuE/2g+KE+J6w5dYF0MwWr0VfcvTBrQHLAf0Cbaj/Fmva1smdvzE0Q7BnD78mijZBiL465GFAS7Wm9lMig/mRiCNkxovDNSOvPg46BTh/a6Ymi+bETcq6Iwt3LeVj99IKdUIV7ahFIkb538mEA9VzAm/z72HSw79/jLm6LG6CqaCyf0MwKjcP7Ohf8BxYvLwCsZvaLfu6Pzb4Nbo6WFCArlMe4=; 5:wDqR4C9IRRhjH82ov3QzwUMVfrHbMLNqGeCg+51kK6oDZwJh7VjWF8yMmnAKb1QvIyQX1ICulK9491UfwxDrUqx3xL+jHOt5exy64N4j63J5d1cmfHwefH/d8MfML3h5u+ZF5i0BTYQIacDRHDNYXg== X-Microsoft-Exchange-Diagnostics: 1; AM3PR03MB1250; 24:ubKpylyOKl2/B2NA6n+BIyq4KnU95rHRsRyM+slYyMwV8HVYCcZGh9UV8uSkfQvG1CbgFE1yVCPwsNH0atZqE/AbqEvcaSLI+PnzFiFMQm8=; 20:lpi7LNYAROfEspsLc1jHJLC91hgGQ+ZeMqTlZgP+Blx69UMssfnhMK70uWYnypwvmGzMp+Bxm9FaAh8oO3rNJQ== X-OriginatorOrg: innogames.de X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jun 2015 13:01:43.6877 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR03MB1250 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 13:01:53 -0000 --nextPart9199065.CFbrja4Pd6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Dnia pi=C4=85tek, 19 czerwca 2015 00:10:01 Chuck @ Mantis pisze: > I'm currently using FreeBSD and PF as a gateway and firewall in front= of > a handful of web servers. >=20 > External: > defaultrouter=3D"79.112.227.33" > ifconfig_bge0=3D"inet 79.112.227.34 netmask 255.255.255.224" >=20 > I've asked the datacenter for an additional block and received: >=20 > Gateway : 60.34.75.209 > IP block : 60.34.75.208/28 > Subnet : 255.255.255.240 >=20 >=20 > Since the gateways are different, I'm assuming I need to use PF or BS= D > to somehow direct (route?) traffic which came via the new block out > through the new gateway? Are both subnets on-link or done by real routing? Of on-link and if bot= h are=20 on the same router and vlan from your provider, then it is going to wor= k fine=20 while using only one gateway. =2D-=20 Kajetan Staszkiewicz System Administrator Mobile: +49 151 4674 6636 InnoGames GmbH Friesenstra=C3=9Fe 13 - 20097 Hamburg - Germany Tel +49 40 7889335-0 Fax +49 40 7889335-22 Managing Directors: Hendrik Klindworth, Eike Klindworth, Michael Zillme= r VAT-ID: DE264068907 Amtsgericht Hamburg, HRB 108973 --nextPart9199065.CFbrja4Pd6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlWEErMACgkQ47RQr217OhTE3QCcDzD5nJGCEi7NpiUd8LQt1589 u0EAoNAGcDUp9qvJ8PCGqWfWtDoYIT82 =kgm1 -----END PGP SIGNATURE----- --nextPart9199065.CFbrja4Pd6-- From owner-freebsd-pf@FreeBSD.ORG Fri Jun 19 15:38:13 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94FFE680 for ; Fri, 19 Jun 2015 15:38:13 +0000 (UTC) (envelope-from chuck@mantis.biz) Received: from zip.c7hosting.com (zip.c7hosting.com [96.47.41.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D43FEC2 for ; Fri, 19 Jun 2015 15:38:12 +0000 (UTC) (envelope-from chuck@mantis.biz) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mantis.biz; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=P2EOIVbSWPtDt2NmoIfQ7o8tCYqPHeLT8A2qunvN95o=; b=tofMzDc1I+NI97isbnOmNcHNiWG4YAKwoG4C5jtDd31eO6GcI576YilEFAeSJs76F/0eAk3z5j7pK8djQa0Dv25jxesHbZmxj2yuBi13slQLQee2DhPn9Nf9RzrpN9QO; Received: from toroon4213w-lp130-04-1176445566.dsl.bell.ca ([70.31.34.126]:49513 helo=[192.168.2.13]) by zip.c7hosting.com with esmtpa (Exim 4.85) (envelope-from ) id 1Z5yMs-0008A1-Ll; Fri, 19 Jun 2015 11:38:10 -0400 Message-ID: <55843762.3040106@mantis.biz> Date: Fri, 19 Jun 2015 11:38:10 -0400 From: "Chuck @ Mantis" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kajetan Staszkiewicz , freebsd-pf@freebsd.org Subject: Re: adding an additional block & gateway References: <55839619.8000603@mantis.biz> <1704069.kZvlBVo68Y@energia> In-Reply-To: <1704069.kZvlBVo68Y@energia> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - zip.c7hosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mantis.biz X-Get-Message-Sender-Via: zip.c7hosting.com: authenticated_id: chuck@mantis.biz X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 15:38:13 -0000 Our data center responded to your question, here is the text: We can confirm that the new netblock is routed direct via your vlan as with your original netblock VLAN: vlan655-cbcbmedi-809, Created at: Mon Oct 20 13:42:05 2014 802.1Q Tag: 655, Internal index: 205, Admin State: Enabled, Origin: Static Layer 3 interface: vlan.655 (UP) IPV4 addresses: 60.34.75.209/28 79.112.227.33/27 Protocol: Port Mode, Mac aging time: 300 seconds Number of interfaces: Tagged 0 (Active = 0), Untagged 1 (Active = 1) ge-5/0/20.0*, untagged, access On 6/19/2015 9:01 AM, Kajetan Staszkiewicz wrote: > Dnia piątek, 19 czerwca 2015 00:10:01 Chuck @ Mantis pisze: >> I'm currently using FreeBSD and PF as a gateway and firewall in front of >> a handful of web servers. >> >> External: >> defaultrouter="79.112.227.33" >> ifconfig_bge0="inet 79.112.227.34 netmask 255.255.255.224" >> >> I've asked the datacenter for an additional block and received: >> >> Gateway : 60.34.75.209 >> IP block : 60.34.75.208/28 >> Subnet : 255.255.255.240 >> >> >> Since the gateways are different, I'm assuming I need to use PF or BSD >> to somehow direct (route?) traffic which came via the new block out >> through the new gateway? > Are both subnets on-link or done by real routing? Of on-link and if both are > on the same router and vlan from your provider, then it is going to work fine > while using only one gateway. > From owner-freebsd-pf@FreeBSD.ORG Sat Jun 20 15:38:16 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6968E75B for ; Sat, 20 Jun 2015 15:38:16 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06A70D25 for ; Sat, 20 Jun 2015 15:38:15 +0000 (UTC) (envelope-from ian.freislich@capeaugusta.com) Received: by wiwl6 with SMTP id l6so2698289wiw.0 for ; Sat, 20 Jun 2015 08:38:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:date:message-id:in-reply-to:references :user-agent:subject:mime-version:content-type :content-transfer-encoding; bh=UW7Skleic3XmBlJ1ID+9u8p0ckdbdufpgDQBQ3zZDuE=; b=QxdCWRGXTNvTFTxqMQPeQ36oyKFkAhAftdn7/IpmC4Py2ipuBkTlwrlTmnkXRNQwG1 zp0PZpQ1sd9wZqNdkhPa9rUAc6uVMqGcgSmYBOwWI4E5oKe0EmXYqTb1uJ/pfB7fYiP0 wE+cdXQfugZfDCNPlaA8MeedR2+i/y+m9/cg/HUXiRHGe4dFh60Ce68r08FRf6WAc7YH z8jpZqnWPEQ4QlymZaKAYhL1qjQ3w4E26qYoLKdepXW/wv2F8FuLBZ/QRFUg1Epgm6mL Wlc1oQXx0dI/hnzmoS5Q2NGhAJC04YevTsvgxIsmPFBpH5seild9v9r79EaE67X6o1u4 iE8Q== X-Gm-Message-State: ALoCoQmT+/aqSGfJ0hIp28UZdGvGw59s4++eHMbl7z/g8q1cWXD2iIHL9jVKTsIsJntAwk7w/kx6 X-Received: by 10.194.47.196 with SMTP id f4mr25548497wjn.46.1434814687721; Sat, 20 Jun 2015 08:38:07 -0700 (PDT) Received: from [10.0.0.38] ([197.89.156.54]) by mx.google.com with ESMTPSA id u7sm8603332wif.3.2015.06.20.08.38.05 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2015 08:38:07 -0700 (PDT) From: Ian FREISLICH To: Milan Obuch , Date: Sat, 20 Jun 2015 17:38:05 +0200 Message-ID: <14e119e8fa8.2755.abfb21602af57f30a7457738c46ad3ae@capeaugusta.com> In-Reply-To: <20150619091857.304b707b@zeta.dino.sk> References: <20150619091857.304b707b@zeta.dino.sk> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 AquaMail/1.5.7.21 (build: 21070086) Subject: Re: Large scale NAT with PF - some weird problem MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 15:38:16 -0000 Hi, How many NAT states in your table? I had a router translating a /20 and a /22 to a /24 and doing transparent interception of those and a /16 to a proxy pool and I never saw this. My state table was about 380000 to 850000 with a search rate about quadruple yours. If you can, give 10-STABLE a try. I ran the above router pair as 10-CURRENT for a long time. There are some significant performance improvements. Ian On 19 June 2015 09:24:22 Milan Obuch wrote: > Hi, > > I am managing FreeBSD 9 based router for a network using PF for NAT. I > think I can call it large scale - there is approximately 3000 customers' > devices (home routers and similar) with private IPs in segment > 172.16.0.0/12 translated to /23 public address block. Basically, in > pf.conf, there is > > nat on $if_ext from $net_int to any -> $pool_ext round-robin > sticky-address > > and handful of > > binat on $if_ext from 172.16.x.y to any -> a.b.c.d > > statements. It works, basically, but for some time now there are some > intermitent outages. When it occurs, customer's device loses access to > internet. I can verify it with simple ping to any address outside of > the network. > > The weird thing is, I can see icmp request packets coming out of > external interface, but no icmp echo packets coming back. While I can't > verify on uplink router that these replies are actually coming in on > interface, I am pretty sure it does, but they are not visible in > tcpdump's output. (When I am pinging some device outside of the > network, which is under my control, I can see there both icmp requests > and icmp echo packets. Also, if I ping address to which thich ping is > translated from outside, I see it on external interface coming in.) > > I think I have a problem with same table being too small, but no idea > where it is. It is not state table, I have > > set limit states 500000 > > in my pf.conf, and pfctl -vs info tells > > State Table Total Rate > current entries 36668 > searches 1996138369 29280.5/s > inserts 15757727 231.1/s > removals 15770004 231.3/s > > so I think I have plenty of room here. It was set in past when > issue a bit similar occured and using bigger state table solved it. > > Also, pfctl -vs state | grep shows states for > not working ping as > > all icmp a.b.c.d:538 <- 172.16.x.y:538 0:0 > all icmp e.f.g.h:40011 (172.16.x.y:538) -> a.b.c.d:40011 0:0 > > where a.b.c.d is address being used as ping target (outside of > network), 172.16.x.y is address of device with trouble access to > internet, and e.f.g.h is translated address for this device, allocated > dynamically. > > After doing /etc/rc.d/pf restart if works again, so I think, again, > issue is with some table being too small. Restart empties it and things > begin to work. > > Does this sound familiar to anybody? I was trying to find some tuning > guide for pf and large scale nat, but no success yet. I would be > gratefull for any help. > > Regards, > Milan > _______________________________________________ > 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 Sat Jun 20 16:24:44 2015 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0240FA2 for ; Sat, 20 Jun 2015 16:24:44 +0000 (UTC) (envelope-from freebsd-pf@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D5D4DA7A for ; Sat, 20 Jun 2015 16:24:42 +0000 (UTC) (envelope-from freebsd-pf@dino.sk) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sat, 20 Jun 2015 18:24:33 +0200 id 00EB08DE.558593C1.0000F241 Date: Sat, 20 Jun 2015 18:24:32 +0200 From: Milan Obuch To: Ian FREISLICH Cc: freebsd-pf@freebsd.org Subject: Re: Large scale NAT with PF - some weird problem Message-ID: <20150620182432.62797ec5@zeta.dino.sk> In-Reply-To: <14e119e8fa8.2755.abfb21602af57f30a7457738c46ad3ae@capeaugusta.com> References: <20150619091857.304b707b@zeta.dino.sk> <14e119e8fa8.2755.abfb21602af57f30a7457738c46ad3ae@capeaugusta.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; i386-portbld-freebsd10.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mailhost.netlabit.sk-62017-1434817473-0001-2" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 16:24:44 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_mailhost.netlabit.sk-62017-1434817473-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sat, 20 Jun 2015 17:38:05 +0200 Ian FREISLICH wrote: > Hi, > > How many NAT states in your table? > How can I find out? Is there another statistics collected I can gert out of pfctl? Full output of pfctl -vs info is attached (hopefully it will come unmangled through), is there anything interesting? > I had a router translating a /20 and a /22 to a /24 and doing > transparent interception of those and a /16 to a proxy pool and I > never saw this. My state table was about 380000 to 850000 with a > search rate about quadruple yours. > Did you do any pf tuning? What about limits in your case? > If you can, give 10-STABLE a try. I ran the above router pair as > 10-CURRENT for a long time. There are some significant performance > improvements. > It is possible, but not easy (read: needs some planning before switch) so as not interrupt the operation. > Ian > Thanks, Milan > On 19 June 2015 09:24:22 Milan Obuch wrote: > > > Hi, > > > > I am managing FreeBSD 9 based router for a network using PF for > > NAT. I think I can call it large scale - there is approximately > > 3000 customers' devices (home routers and similar) with private IPs > > in segment 172.16.0.0/12 translated to /23 public address block. > > Basically, in pf.conf, there is > > > > nat on $if_ext from $net_int to any -> $pool_ext round-robin > > sticky-address > > > > and handful of > > > > binat on $if_ext from 172.16.x.y to any -> a.b.c.d > > > > statements. It works, basically, but for some time now there are > > some intermitent outages. When it occurs, customer's device loses > > access to internet. I can verify it with simple ping to any address > > outside of the network. > > > > The weird thing is, I can see icmp request packets coming out of > > external interface, but no icmp echo packets coming back. While I > > can't verify on uplink router that these replies are actually > > coming in on interface, I am pretty sure it does, but they are not > > visible in tcpdump's output. (When I am pinging some device outside > > of the network, which is under my control, I can see there both > > icmp requests and icmp echo packets. Also, if I ping address to > > which thich ping is translated from outside, I see it on external > > interface coming in.) > > > > I think I have a problem with same table being too small, but no > > idea where it is. It is not state table, I have > > > > set limit states 500000 > > > > in my pf.conf, and pfctl -vs info tells > > > > State Table Total Rate > > current entries 36668 > > searches 1996138369 29280.5/s > > inserts 15757727 231.1/s > > removals 15770004 231.3/s > > > > so I think I have plenty of room here. It was set in past when > > issue a bit similar occured and using bigger state table solved it. > > > > Also, pfctl -vs state | grep shows states > > for not working ping as > > > > all icmp a.b.c.d:538 <- 172.16.x.y:538 0:0 > > all icmp e.f.g.h:40011 (172.16.x.y:538) -> a.b.c.d:40011 0:0 > > > > where a.b.c.d is address being used as ping target (outside of > > network), 172.16.x.y is address of device with trouble access to > > internet, and e.f.g.h is translated address for this device, > > allocated dynamically. > > > > After doing /etc/rc.d/pf restart if works again, so I think, again, > > issue is with some table being too small. Restart empties it and > > things begin to work. > > > > Does this sound familiar to anybody? I was trying to find some > > tuning guide for pf and large scale nat, but no success yet. I > > would be gratefull for any help. > > > > Regards, > > Milan > > > --=_mailhost.netlabit.sk-62017-1434817473-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=pfctl-vsinfo U3RhdHVzOiBFbmFibGVkIGZvciAxIGRheXMgMDg6NDA6MDMgICAgICAgICAgIERlYnVnOiBVcmdl bnQNCg0KSG9zdGlkOiAgIDB4ZGM5NmMwNWENCkNoZWNrc3VtOiAweGViMjA3YmU3YjAwN2MxMWRh M2Y5YmUzYzU0MWQ5MGQwDQoNClN0YXRlIFRhYmxlICAgICAgICAgICAgICAgICAgICAgICAgICBU b3RhbCAgICAgICAgICAgICBSYXRlDQogIGN1cnJlbnQgZW50cmllcyAgICAgICAgICAgICAgICAg ICAgNDk1MTggICAgICAgICAgICAgICANCiAgc2VhcmNoZXMgICAgICAgICAgICAgICAgICAgICAg NDIwMzExNjUyNCAgICAgICAgMzU3MzkuOS9zDQogIGluc2VydHMgICAgICAgICAgICAgICAgICAg ICAgICAgMzEwMDk1NTYgICAgICAgICAgMjYzLjcvcw0KICByZW1vdmFscyAgICAgICAgICAgICAg ICAgICAgICAgIDMxMDAwMzExICAgICAgICAgIDI2My42L3MNClNvdXJjZSBUcmFja2luZyBUYWJs ZQ0KICBjdXJyZW50IGVudHJpZXMgICAgICAgICAgICAgICAgICAgICAgNTQ4ICAgICAgICAgICAg ICAgDQogIHNlYXJjaGVzICAgICAgICAgICAgICAgICAgICAgICAgIDg2NzI2OTYgICAgICAgICAg IDczLjcvcw0KICBpbnNlcnRzICAgICAgICAgICAgICAgICAgICAgICAgICAgIDExMzQ4ICAgICAg ICAgICAgMC4xL3MNCiAgcmVtb3ZhbHMgICAgICAgICAgICAgICAgICAgICAgICAgICAxMDgwMCAg ICAgICAgICAgIDAuMS9zDQpDb3VudGVycw0KICBtYXRjaCAgICAgICAgICAgICAgICAgICAgICAg ICAgIDk4NzQ2MTg2ICAgICAgICAgIDgzOS43L3MNCiAgYmFkLW9mZnNldCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgMCAgICAgICAgICAgIDAuMC9zDQogIGZyYWdtZW50ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAyMDggICAgICAgICAgICAwLjAvcw0KICBzaG9ydCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMzQxICAgICAgICAgICAgMC4wL3MNCiAgbm9ybWFsaXplICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAgICAgICAgIDAuMC9zDQogIG1lbW9yeSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgICAgICAgICAwLjAvcw0KICBiYWQt dGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MNCiAg Y29uZ2VzdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMCAgICAgICAgICAgIDAuMC9z DQogIGlwLW9wdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgICAgICAgICAw LjAvcw0KICBwcm90by1ja3N1bSAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAg ICAgMC4wL3MNCiAgc3RhdGUtbWlzbWF0Y2ggICAgICAgICAgICAgICAgICAgICA0NDMxMSAgICAg ICAgICAgIDAuNC9zDQogIHN0YXRlLWluc2VydCAgICAgICAgICAgICAgICAgICAgICAgICAgMTIg ICAgICAgICAgICAwLjAvcw0KICBzdGF0ZS1saW1pdCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAwICAgICAgICAgICAgMC4wL3MNCiAgc3JjLWxpbWl0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA2NiAgICAgICAgICAgIDAuMC9zDQogIHN5bnByb3h5ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDAgICAgICAgICAgICAwLjAvcw0KTGltaXQgQ291bnRlcnMNCiAgbWF4IHN0YXRl cyBwZXIgcnVsZSAgICAgICAgICAgICAgICAgICAgMCAgICAgICAgICAgIDAuMC9zDQogIG1heC1z cmMtc3RhdGVzICAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgICAgICAgICAwLjAvcw0KICBt YXgtc3JjLW5vZGVzICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MN CiAgbWF4LXNyYy1jb25uICAgICAgICAgICAgICAgICAgICAgICAgIDM3NyAgICAgICAgICAgIDAu MC9zDQogIG1heC1zcmMtY29ubi1yYXRlICAgICAgICAgICAgICAgICAgICAyNzYgICAgICAgICAg ICAwLjAvcw0KICBvdmVybG9hZCB0YWJsZSBpbnNlcnRpb24gICAgICAgICAgICAgNjQ5ICAgICAg ICAgICAgMC4wL3MNCiAgb3ZlcmxvYWQgZmx1c2ggc3RhdGVzICAgICAgICAgICAgICAgIDY0OSAg ICAgICAgICAgIDAuMC9zDQo= --=_mailhost.netlabit.sk-62017-1434817473-0001-2--