From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 10:52:16 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 467741065672 for ; Sun, 5 Jun 2011 10:52:16 +0000 (UTC) (envelope-from admin@isphost.com.ua) Received: from mail.lviv.ua (fe20.uar.net [194.44.214.20]) by mx1.freebsd.org (Postfix) with ESMTP id 073458FC0C for ; Sun, 5 Jun 2011 10:52:15 +0000 (UTC) Received: from hoster.rv.uar.net ([194.44.252.247]) by mail.lviv.ua with esmtp (Exim 4.69) (envelope-from ) id 1QT9rU-0000Sg-P1 for freebsd-pf@freebsd.org; Sun, 05 Jun 2011 12:43:13 +0300 Message-ID: <4DEB4FA5.6020808@isphost.com.ua> Date: Sun, 05 Jun 2011 12:43:01 +0300 From: Dmitri Budko User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: pf speed drops X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 10:52:16 -0000 Hello. When I turn on the PF server internet speed drops from 500 megabits to 100, after the shutdown goes back to 500 The rules are simple pass in all pass out all OS: FreeBSD GW 7.3-RELEASE FreeBSD 7.3-RELEASE # 3 Network card: em0: How is it possible to solve this problem? From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 12:42:21 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88C6C106566B for ; Sun, 5 Jun 2011 12:42:21 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail2.jellyfishnet.co.uk (mail2.jellyfishnet.co.uk [93.91.20.10]) by mx1.freebsd.org (Postfix) with ESMTP id 23DE68FC13 for ; Sun, 5 Jun 2011 12:42:21 +0000 (UTC) Received: from pemexhub01.jellyfishnet.co.uk.local (93.91.20.2) by mail2.jellyfishnet.co.uk (93.91.20.10) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 5 Jun 2011 13:30:38 +0100 Received: from PEMEXMBXVS04.jellyfishnet.co.uk.local ([192.168.65.51]) by pemexhub01.jellyfishnet.co.uk.local ([192.168.65.7]) with mapi; Sun, 5 Jun 2011 13:31:29 +0100 From: Greg Hennessy To: Dmitri Budko , "freebsd-pf@freebsd.org" Date: Sun, 5 Jun 2011 13:31:26 +0100 Thread-Topic: pf speed drops Thread-Index: Acwjbqs9fkrW3tZXTyeAGAOU/qGmRQADQnvQ Message-ID: <9EB23F6C23A8B6488E8BCC92A48E8326127766A8D6@PEMEXMBXVS04.jellyfishnet.co.uk.local> References: <4DEB4FA5.6020808@isphost.com.ua> In-Reply-To: <4DEB4FA5.6020808@isphost.com.ua> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Subject: RE: pf speed drops X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 12:42:21 -0000 QXMgbWVhc3VyZWQgYnk/IA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogb3duZXItZnJlZWJzZC1wZkBmcmVlYnNkLm9yZyBbbWFpbHRvOm93bmVyLWZyZWVic2QtDQo+ IHBmQGZyZWVic2Qub3JnXSBPbiBCZWhhbGYgT2YgRG1pdHJpIEJ1ZGtvDQo+IFNlbnQ6IFN1bmRh eSwgNSBKdW5lIDIwMTEgNzo0MyBQTQ0KPiBUbzogZnJlZWJzZC1wZkBmcmVlYnNkLm9yZw0KPiBT dWJqZWN0OiBwZiBzcGVlZCBkcm9wcw0KPiANCj4gSGVsbG8uDQo+IFdoZW4gSSB0dXJuIG9uIHRo ZSBQRiBzZXJ2ZXIgaW50ZXJuZXQgc3BlZWQgZHJvcHMgZnJvbSA1MDAgbWVnYWJpdHMgdG8NCj4g MTAwLCBhZnRlciB0aGUgc2h1dGRvd24gZ29lcyBiYWNrIHRvIDUwMA0KPiANCj4gVGhlIHJ1bGVz IGFyZSBzaW1wbGUNCj4gDQo+IHBhc3MgaW4gYWxsDQo+IHBhc3Mgb3V0IGFsbA0KPiANCj4gT1M6 IEZyZWVCU0QgR1cgNy4zLVJFTEVBU0UgRnJlZUJTRCA3LjMtUkVMRUFTRSAjIDMNCj4gTmV0d29y ayBjYXJkOiBlbTA6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24gNi45LjY+ DQo+IA0KPiBIb3cgaXMgaXQgcG9zc2libGUgdG8gc29sdmUgdGhpcyBwcm9ibGVtPw0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBmcmVlYnNkLXBm QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFp bG1hbi9saXN0aW5mby9mcmVlYnNkLXBmDQo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWls IHRvICJmcmVlYnNkLXBmLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 13:11:03 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9904106564A for ; Sun, 5 Jun 2011 13:11:03 +0000 (UTC) (envelope-from admin@isphost.com.ua) Received: from mail.lviv.ua (fe22.uar.net [194.44.214.22]) by mx1.freebsd.org (Postfix) with ESMTP id 653DA8FC0C for ; Sun, 5 Jun 2011 13:11:02 +0000 (UTC) Received: from hoster.rv.uar.net ([194.44.252.247]) by mail.lviv.ua with esmtp (Exim 4.69) (envelope-from ) id 1QTD6a-0000nA-L6; Sun, 05 Jun 2011 16:11:01 +0300 Message-ID: <4DEB8058.6020708@isphost.com.ua> Date: Sun, 05 Jun 2011 16:10:48 +0300 From: Dmitri Budko User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Greg Hennessy References: <4DEB4FA5.6020808@isphost.com.ua> <9EB23F6C23A8B6488E8BCC92A48E8326127766A8D6@PEMEXMBXVS04.jellyfishnet.co.uk.local> In-Reply-To: <9EB23F6C23A8B6488E8BCC92A48E8326127766A8D6@PEMEXMBXVS04.jellyfishnet.co.uk.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "freebsd-pf@freebsd.org" Subject: Re: pf speed drops X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 13:11:03 -0000 Hello I look via systat -if 1 Greg Hennessy пишет: > As measured by? > > > >> -----Original Message----- >> From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd- >> pf@freebsd.org] On Behalf Of Dmitri Budko >> Sent: Sunday, 5 June 2011 7:43 PM >> To: freebsd-pf@freebsd.org >> Subject: pf speed drops >> >> Hello. >> When I turn on the PF server internet speed drops from 500 megabits to >> 100, after the shutdown goes back to 500 >> >> The rules are simple >> >> pass in all >> pass out all >> >> OS: FreeBSD GW 7.3-RELEASE FreeBSD 7.3-RELEASE # 3 >> Network card: em0: >> >> How is it possible to solve this problem? >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" >> From owner-freebsd-pf@FreeBSD.ORG Sun Jun 5 22:11:01 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A96351065674 for ; Sun, 5 Jun 2011 22:11:01 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from mail1.jellyfishnet.co.uk (mail1.jellyfishnet.co.uk [93.91.20.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4A1038FC22 for ; Sun, 5 Jun 2011 22:11:00 +0000 (UTC) Received: from pemexhub02.jellyfishnet.co.uk.local (93.91.20.2) by mail1.jellyfishnet.co.uk (93.91.20.9) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 5 Jun 2011 23:10:21 +0100 Received: from PEMEXMBXVS04.jellyfishnet.co.uk.local ([192.168.65.51]) by pemexhub02.jellyfishnet.co.uk.local ([192.168.65.8]) with mapi; Sun, 5 Jun 2011 23:11:00 +0100 From: Greg Hennessy To: Dmitri Budko Date: Sun, 5 Jun 2011 23:10:56 +0100 Thread-Topic: pf speed drops Thread-Index: AcwjggWrK1TnQ0uvRKSoyQWIuC/lxwASrY1A Message-ID: <9EB23F6C23A8B6488E8BCC92A48E8326127766A91B@PEMEXMBXVS04.jellyfishnet.co.uk.local> References: <4DEB4FA5.6020808@isphost.com.ua> <9EB23F6C23A8B6488E8BCC92A48E8326127766A8D6@PEMEXMBXVS04.jellyfishnet.co.uk.local> <4DEB8058.6020708@isphost.com.ua> In-Reply-To: <4DEB8058.6020708@isphost.com.ua> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-pf@freebsd.org" Subject: RE: pf speed drops X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2011 22:11:01 -0000 V2hhdCBpcyB0aGUgcHJvZmlsZSBvZiB0aGUgbmV0d29yayB0cmFmZmljID8gUHJvdG9jb2wgPyBD b25uZWN0aW9ucy9zZWNvbmQgPyBQYWNrZXQgc2l6ZSA/DQoNCg0KQ2hhbmdlIHRoZSBwb2xpY3kg dG8gDQoNCkJsb2NrIGxvZyBhbGwNClBhc3MgbG9nIGFsbCBrZWVwIHN0YXRlIA0KDQoNClBlcmZv cm0gdGhlIHRlc3QgYWdhaW4sIGNoZWNrIHRoZSBmaXJld2FsbCBsb2dzIHRvIHNlZSB3aGF0IGlm IGFueXRoaW5nIGlzIGJlaW5nIGRyb3BwZWQuIA0KDQo1MDAgbWVnYWJpdHMvc2Vjb25kIGEgbG90 IG9mIHRyYWZmaWMgZm9yIGFuIGludGVybmV0IGNvbm5lY3RlZCBkZXZpY2UuIFRoZSBzdGF0ZSB0 YWJsZSBjb3VsZCBiZSBmaWxsaW5nIHVwIGZvciBleGFtcGxlLiANCg0KaHR0cDovL3ByZWZldGNo Lm5ldC9hcnRpY2xlcy9tb25pdG9yaW5ncGYuaHRtbA0KDQpodHRwOi8vd3d3LnBhY2tldG1pc2No aWVmLmNhLzIwMTEvMDIvMTcvaGl0dGluZy10aGUtcGYtc3RhdGUtdGFibGUtbGltaXQvDQoNCg0K DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRG1pdHJpIEJ1ZGtvIFtt YWlsdG86YWRtaW5AaXNwaG9zdC5jb20udWFdDQo+IFNlbnQ6IFN1bmRheSwgNSBKdW5lIDIwMTEg MTE6MTEgUE0NCj4gVG86IEdyZWcgSGVubmVzc3kNCj4gQ2M6IGZyZWVic2QtcGZAZnJlZWJzZC5v cmcNCj4gU3ViamVjdDogUmU6IHBmIHNwZWVkIGRyb3BzDQo+IA0KPiBIZWxsbw0KPiBJIGxvb2sg dmlhIHN5c3RhdCAtaWYgMQ0KPiANCj4gR3JlZyBIZW5uZXNzeSDQv9C40YjQtdGCOg0KPiA+IEFz IG1lYXN1cmVkIGJ5Pw0KPiA+DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+PiBGcm9tOiBvd25lci1mcmVlYnNkLXBmQGZyZWVic2Qub3JnIFttYWlsdG86b3du ZXItZnJlZWJzZC0NCj4gPj4gcGZAZnJlZWJzZC5vcmddIE9uIEJlaGFsZiBPZiBEbWl0cmkgQnVk a28NCj4gPj4gU2VudDogU3VuZGF5LCA1IEp1bmUgMjAxMSA3OjQzIFBNDQo+ID4+IFRvOiBmcmVl YnNkLXBmQGZyZWVic2Qub3JnDQo+ID4+IFN1YmplY3Q6IHBmIHNwZWVkIGRyb3BzDQo+ID4+DQo+ ID4+IEhlbGxvLg0KPiA+PiBXaGVuIEkgdHVybiBvbiB0aGUgUEYgc2VydmVyIGludGVybmV0IHNw ZWVkIGRyb3BzIGZyb20gNTAwIG1lZ2FiaXRzIHRvDQo+ID4+IDEwMCwgYWZ0ZXIgdGhlIHNodXRk b3duIGdvZXMgYmFjayB0byA1MDANCj4gPj4NCj4gPj4gVGhlIHJ1bGVzIGFyZSBzaW1wbGUNCj4g Pj4NCj4gPj4gcGFzcyBpbiBhbGwNCj4gPj4gcGFzcyBvdXQgYWxsDQo+ID4+DQo+ID4+IE9TOiBG cmVlQlNEIEdXIDcuMy1SRUxFQVNFIEZyZWVCU0QgNy4zLVJFTEVBU0UgIyAzDQo+ID4+IE5ldHdv cmsgY2FyZDogZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uIDYuOS42 Pg0KPiA+Pg0KPiA+PiBIb3cgaXMgaXQgcG9zc2libGUgdG8gc29sdmUgdGhpcyBwcm9ibGVtPw0K PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ PiBmcmVlYnNkLXBmQGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiA+PiBodHRwOi8vbGlzdHMu ZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLXBmDQo+ID4+IFRvIHVuc3Vic2Ny aWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNkLXBmLXVuc3Vic2NyaWJlQGZyZWVic2Qub3Jn Ig0KPiA+Pg0KDQo= From owner-freebsd-pf@FreeBSD.ORG Mon Jun 6 11:07:11 2011 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6CBE1065690 for ; Mon, 6 Jun 2011 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8BCC48FC24 for ; Mon, 6 Jun 2011 11:07:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p56B7B5u037697 for ; Mon, 6 Jun 2011 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p56B7Aw2037695 for freebsd-pf@FreeBSD.org; Mon, 6 Jun 2011 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 6 Jun 2011 11:07:10 GMT Message-Id: <201106061107.p56B7Aw2037695@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2011 11:07:11 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/155736 pf [pf] [altq] borrow from parent queue does not work wit o kern/153307 pf [pf] Bug with PF firewall o kern/148290 pf [pf] "sticky-address" option of Packet Filter (PF) blo o kern/148260 pf [pf] [patch] pf rdr incompatible with dummynet o kern/147789 pf [pf] Firewall PF no longer drops connections by sendin o kern/146832 pf [pf] "(self)" not always matching all local IPv6 addre o kern/143543 pf [pf] [panic] PF route-to causes kernel panic o bin/143504 pf [patch] outgoing states are not killed by authpf(8) o conf/142961 pf [pf] No way to adjust pidfile in pflogd o conf/142817 pf [patch] etc/rc.d/pf: silence pfctl o kern/141905 pf [pf] [panic] pf kernel panic on 7.2-RELEASE with empty o kern/140697 pf [pf] pf behaviour changes - must be documented o kern/137982 pf [pf] when pf can hit state limits, random IP failures o kern/136781 pf [pf] Packets appear to drop with pf scrub and if_bridg o kern/135948 pf [pf] [gre] pf not natting gre protocol o kern/135162 pf [pfsync] pfsync(4) not usable with GENERIC kernel o kern/134996 pf [pf] Anchor tables not included when pfctl(8) is run w o kern/133732 pf [pf] max-src-conn issue o kern/132769 pf [pf] [lor] 2 LOR's with pf task mtx / ifnet and rtent f kern/132176 pf [pf] pf stalls connection when using route-to [regress o conf/130381 pf [rc.d] [pf] [ip6] ipv6 not fully configured when pf st o kern/129861 pf [pf] [patch] Argument names reversed in pf_table.c:_co o kern/127920 pf [pf] ipv6 and synproxy don't play well together o conf/127814 pf [pf] The flush in pf_reload in /etc/rc.d/pf does not w o kern/127439 pf [pf] deadlock in pf f kern/127345 pf [pf] Problem with PF on FreeBSD7.0 [regression] o kern/127121 pf [pf] [patch] pf incorrect log priority o kern/127042 pf [pf] [patch] pf recursion panic if interface group is o kern/125467 pf [pf] pf keep state bug while handling sessions between s kern/124933 pf [pf] [ip6] pf does not support (drops) IPv6 fragmented o kern/124364 pf [pf] [panic] Kernel panic with pf + bridge o kern/122773 pf [pf] pf doesn't log uid or pid when configured to o kern/122014 pf [pf] [panic] FreeBSD 6.2 panic in pf o kern/120281 pf [pf] [request] lost returning packets to PF for a rdr o kern/120057 pf [pf] [patch] Allow proper settings of ALTQ_HFSC. The c o bin/118355 pf [pf] [patch] pfctl(8) help message options order false o kern/114567 pf [pf] [lor] pf_ioctl.c + if.c o kern/114095 pf [carp] carp+pf delay with high state limit s conf/110838 pf [pf] tagged parameter on nat not working on FreeBSD 5. o kern/103283 pf pfsync fails to sucessfully transfer some sessions o kern/103281 pf pfsync reports bulk update failures o kern/93825 pf [pf] pf reply-to doesn't work o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/86635 pf [patch] pfctl(8): allow new page character (^L) in pf. o kern/82271 pf [pf] cbq scheduler cause bad latency 46 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Jun 6 15:51:22 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 270A11065673 for ; Mon, 6 Jun 2011 15:51:22 +0000 (UTC) (envelope-from switch@trueswitch.com) Received: from mail.trueswitch.com (mail.trueswitch.com [4.78.168.24]) by mx1.freebsd.org (Postfix) with ESMTP id B0CCB8FC1D for ; Mon, 6 Jun 2011 15:51:21 +0000 (UTC) Received: from service512.trueswitch.com ([192.168.0.182]) by mail.trueswitch.com (8.14.3/8.14.3) with ESMTP id p569aP4E079518 for ; Mon, 6 Jun 2011 05:36:25 -0400 (EDT) (envelope-from switch@trueswitch.com) Date: Mon, 6 Jun 2011 05:36:25 -0400 (EDT) From: New Facebook For Singles Sender: switch@trueswitch.com To: "freebsd-pf@freebsd.org" Message-ID: <1219746194.208254.1307352985245.JavaMail.vmail@service512.trueswitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: karl48866@gmail.com has a new email address X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ashley.mccoy@aol.com 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, 06 Jun 2011 15:51:22 -0000 [canvas1.gif] [canvas2.gif] New Facebook For Singles has a new e-mail address. Old E-mail Address: karl48866@gmail.com New E-mail Address:[1]ashley.mccoy@aol.com HERE IS THE NEW FACEBOOK FOR SINGLES [2]WWW.FBOOK-SINGLES.COM [3]Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more. References 1. mailto:ashley.mccoy@aol.com 2. http://www.fbook-singles.com/ 3. http://free.aol.com/thenewaol/index.adp From owner-freebsd-pf@FreeBSD.ORG Mon Jun 6 19:11:48 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D652C106566C for ; Mon, 6 Jun 2011 19:11:48 +0000 (UTC) (envelope-from switch@trueswitch.com) Received: from mail1.trueswitch.com (mail1.trueswitch.com [4.78.168.20]) by mx1.freebsd.org (Postfix) with ESMTP id 729A48FC13 for ; Mon, 6 Jun 2011 19:11:48 +0000 (UTC) Received: from service402.trueswitch.com (unknown [192.168.0.196]) by mail1.trueswitch.com (Postfix) with ESMTP id E671521B801C for ; Mon, 6 Jun 2011 14:30:01 -0400 (EDT) Date: Mon, 6 Jun 2011 14:30:33 -0400 (EDT) From: New Facebook For Singles Sender: switch@trueswitch.com To: "freebsd-pf@freebsd.org" Message-ID: <1271546598.261645.1307385033179.JavaMail.vmail@service402.trueswitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: karl48866@gmail.com has a new email address X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ashley.mccoy@aol.com 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, 06 Jun 2011 19:11:49 -0000 [canvas1.gif] [canvas2.gif] New Facebook For Singles has a new e-mail address. Old E-mail Address: karl48866@gmail.com New E-mail Address:[1]ashley.mccoy@aol.com HERE IS THE NEW FACEBOOK FOR SINGLES [2]WWW.FBOOK-SINGLES.COM [3]Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more. References 1. mailto:ashley.mccoy@aol.com 2. http://www.fbook-singles.com/ 3. http://free.aol.com/thenewaol/index.adp From owner-freebsd-pf@FreeBSD.ORG Mon Jun 6 23:09:08 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37DD51065670 for ; Mon, 6 Jun 2011 23:09:08 +0000 (UTC) (envelope-from switch@trueswitch.com) Received: from mailer3.trueswitch.com (mail3.trueswitch.com [64.152.25.242]) by mx1.freebsd.org (Postfix) with ESMTP id EFA328FC19 for ; Mon, 6 Jun 2011 23:09:07 +0000 (UTC) Received: from mail2.trueswitch.com (mail2 [192.168.0.26]) by mailer3.trueswitch.com (8.14.3/8.14.3) with ESMTP id p56N7s1t099088 for ; Mon, 6 Jun 2011 19:09:07 -0400 (EDT) (envelope-from switch@trueswitch.com) Received: from service402.trueswitch.com (unknown [192.168.0.196]) by mail2.trueswitch.com (Postfix) with ESMTP id 9ECAAD68086 for ; Mon, 6 Jun 2011 19:09:06 -0400 (EDT) Date: Mon, 6 Jun 2011 19:09:38 -0400 (EDT) From: New Facebook For Singles Sender: switch@trueswitch.com To: "freebsd-pf@freebsd.org" Message-ID: <634185255.264907.1307401778151.JavaMail.vmail@service402.trueswitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: karl48866@gmail.com has a new email address X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ashley.mccoy@aol.com 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, 06 Jun 2011 23:09:08 -0000 [canvas1.gif] [canvas2.gif] New Facebook For Singles has a new e-mail address. Old E-mail Address: karl48866@gmail.com New E-mail Address:[1]ashley.mccoy@aol.com HERE IS THE NEW FACEBOOK FOR SINGLES [2]WWW.FBOOK-SINGLES.COM [3]Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more. References 1. mailto:ashley.mccoy@aol.com 2. http://www.fbook-singles.com/ 3. http://free.aol.com/thenewaol/index.adp From owner-freebsd-pf@FreeBSD.ORG Tue Jun 7 19:51:01 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 007491065670; Tue, 7 Jun 2011 19:51:01 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id CD2C98FC0A; Tue, 7 Jun 2011 19:51:00 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QU2Ik-0001E5-1b; Tue, 07 Jun 2011 15:50:58 -0400 Date: Tue, 7 Jun 2011 15:50:57 -0400 From: Gary Palmer To: freebsd-pf@freebsd.org Message-ID: <20110607195057.GA37735@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Subject: IPv6 day, PF and IPv6 fragments X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 19:51:01 -0000 Hi, I noticed after running test-ipv6.com at home that I was getting 2011-06-07 20:35:55.588335 rule 279/0(match): block in on gif0: 2001:4998:0:6::11 > : frag (0|1424) 80 > 62594: . 0:1392(1392) ack 1 win 8211 2011-06-07 20:35:55.588521 rule 279/0(match): block in on gif0: 2001:4998:0:6::11 > : frag (1424|16) on my FreeBSD 7.3-RELEASE firewall. "man pf.conf" says Currently, only IPv4 fragments are supported and IPv6 fragments are blocked unconditionally. Is this correct? If so, what is the correct way of getting IPv6 fragmented packets through a pf firewall, or which version of FreeBSD introduces a PF version that natively handles IPv6 fragments? Thanks, Gary From owner-freebsd-pf@FreeBSD.ORG Tue Jun 7 21:14:41 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E03B1065674; Tue, 7 Jun 2011 21:14:41 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 943B68FC14; Tue, 7 Jun 2011 21:14:40 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 8B62025D3810; Tue, 7 Jun 2011 21:14:39 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9BC1315A131F; Tue, 7 Jun 2011 21:14:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id vYbzwzY0bduh; Tue, 7 Jun 2011 21:14:37 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0C24115A131D; Tue, 7 Jun 2011 21:14:36 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110607195057.GA37735@in-addr.com> Date: Tue, 7 Jun 2011 21:14:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <875CCF38-D6CE-45E7-8F41-2DBA79B12481@lists.zabbadoz.net> References: <20110607195057.GA37735@in-addr.com> To: Gary Palmer X-Mailer: Apple Mail (2.1084) Cc: freebsd-pf@freebsd.org Subject: Re: IPv6 day, PF and IPv6 fragments X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:14:41 -0000 On Jun 7, 2011, at 7:50 PM, Gary Palmer wrote: > I noticed after running test-ipv6.com at home that I was getting >=20 > 2011-06-07 20:35:55.588335 rule 279/0(match): block in on gif0: = 2001:4998:0:6::11 > : frag (0|1424) 80 > 62594: . 0:1392(1392) = ack 1 win 8211 > 2011-06-07 20:35:55.588521 rule 279/0(match): block in on gif0: = 2001:4998:0:6::11 > : frag (1424|16) >=20 > on my FreeBSD 7.3-RELEASE firewall. "man pf.conf" says >=20 > Currently, only IPv4 fragments are supported and IPv6 fragments = are > blocked unconditionally. >=20 > Is this correct? If so, what is the correct way of getting IPv6 = fragmented > packets through a pf firewall, or which version of FreeBSD introduces = a PF > version that natively handles IPv6 fragments? OpenBSD might have added it lately to their devel version though I am = not yet sure to which extend they now check. If you trust your hosts = you can use something like: pass log quick inet6 proto ipv6-frag all to let the ipv6 fragments pass through without inspection. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-pf@FreeBSD.ORG Tue Jun 7 21:29:59 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A61A6106566C; Tue, 7 Jun 2011 21:29:59 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-ew0-f54.google.com (mail-ew0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1AE9E8FC08; Tue, 7 Jun 2011 21:29:58 +0000 (UTC) Received: by ewy1 with SMTP id 1so2770119ewy.13 for ; Tue, 07 Jun 2011 14:29:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.28.139 with SMTP id m11mr2786787ebc.108.1307480603750; Tue, 07 Jun 2011 14:03:23 -0700 (PDT) Received: by 10.213.114.82 with HTTP; Tue, 7 Jun 2011 14:03:23 -0700 (PDT) In-Reply-To: <20110607195057.GA37735@in-addr.com> References: <20110607195057.GA37735@in-addr.com> Date: Tue, 7 Jun 2011 17:03:23 -0400 Message-ID: From: Michael Proto To: Gary Palmer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-pf@freebsd.org Subject: Re: IPv6 day, PF and IPv6 fragments X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:29:59 -0000 On Tue, Jun 7, 2011 at 3:50 PM, Gary Palmer wrote: > Hi, > > I noticed after running test-ipv6.com at home that I was getting > > 2011-06-07 20:35:55.588335 rule 279/0(match): block in on gif0: 2001:4998= :0:6::11 > : frag (0|1424) 80 > 62594: . 0:1392(1392) ack 1 win 8211= > 2011-06-07 20:35:55.588521 rule 279/0(match): block in on gif0: 2001:4998= :0:6::11 > : frag (1424|16) > > on my FreeBSD 7.3-RELEASE firewall. =A0"man pf.conf" says > > =A0 =A0 Currently, only IPv4 fragments are supported and IPv6 fragments a= re > =A0 =A0 blocked unconditionally. > > Is this correct? =A0If so, what is the correct way of getting IPv6 fragme= nted > packets through a pf firewall, or which version of FreeBSD introduces a P= F > version that natively handles IPv6 fragments? > > Thanks, > > Gary Unless I'm mistaken, there shouldn't be any fragments for IPv6, at least nothing traversing IPv6-capable routers. MTU path-discovery is supposed to take care of that and any fragmentation is supposed to be done on the sending host once path-discovery determines the correct MTU. http://en.wikipedia.org/wiki/IPv6_packet#Fragmentation -Proto From owner-freebsd-pf@FreeBSD.ORG Tue Jun 7 21:33:34 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D49B106566C; Tue, 7 Jun 2011 21:33:34 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 354018FC1A; Tue, 7 Jun 2011 21:33:34 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 24E7125D389C; Tue, 7 Jun 2011 21:33:33 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 6497E15A1402; Tue, 7 Jun 2011 21:33:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id ewhoX9rp9WUO; Tue, 7 Jun 2011 21:33:31 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 134E615A1401; Tue, 7 Jun 2011 21:33:30 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: Date: Tue, 7 Jun 2011 21:33:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <00EBAA07-0E65-49D0-A281-FF98DF6C98BA@lists.zabbadoz.net> References: <20110607195057.GA37735@in-addr.com> To: Michael Proto X-Mailer: Apple Mail (2.1084) Cc: freebsd-pf@freebsd.org Subject: Re: IPv6 day, PF and IPv6 fragments X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 21:33:34 -0000 On Jun 7, 2011, at 9:03 PM, Michael Proto wrote: > On Tue, Jun 7, 2011 at 3:50 PM, Gary Palmer = wrote: >> Hi, >>=20 >> I noticed after running test-ipv6.com at home that I was getting >>=20 >> 2011-06-07 20:35:55.588335 rule 279/0(match): block in on gif0: = 2001:4998:0:6::11 > : frag (0|1424) 80 > 62594: . 0:1392(1392) = ack 1 win 8211 >> 2011-06-07 20:35:55.588521 rule 279/0(match): block in on gif0: = 2001:4998:0:6::11 > : frag (1424|16) >>=20 >> on my FreeBSD 7.3-RELEASE firewall. "man pf.conf" says >>=20 >> Currently, only IPv4 fragments are supported and IPv6 fragments = are >> blocked unconditionally. >>=20 >> Is this correct? If so, what is the correct way of getting IPv6 = fragmented >> packets through a pf firewall, or which version of FreeBSD introduces = a PF >> version that natively handles IPv6 fragments? >>=20 >> Thanks, >>=20 >> Gary >=20 > Unless I'm mistaken, there shouldn't be any fragments for IPv6, at > least nothing traversing IPv6-capable routers. MTU path-discovery is > supposed to take care of that and any fragmentation is supposed to be > done on the sending host once path-discovery determines the correct > MTU. >=20 > http://en.wikipedia.org/wiki/IPv6_packet#Fragmentation Whatever they say and what you read. There are fragments in IPv6 as well. Indeed none fragments the packet on the path but if I am going to write 32k of data to UDP you'll see a lot of fragments no matter what. Actually this is the most common frag6 source I am seeing -- large DNS replies due to DNSsec, etc. /bz --=20 Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 08:06:24 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FB33106564A; Wed, 8 Jun 2011 08:06:24 +0000 (UTC) (envelope-from mohacsi@niif.hu) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by mx1.freebsd.org (Postfix) with ESMTP id 201EE8FC0A; Wed, 8 Jun 2011 08:06:24 +0000 (UTC) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 12E008755F; Wed, 8 Jun 2011 10:06:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id vD0mXVFPVcd1; Wed, 8 Jun 2011 10:06:19 +0200 (CEST) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 8BCF28754A; Wed, 8 Jun 2011 10:06:19 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 8371D87541; Wed, 8 Jun 2011 10:06:19 +0200 (CEST) Date: Wed, 8 Jun 2011 10:06:19 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Gary Palmer In-Reply-To: <20110607195057.GA37735@in-addr.com> Message-ID: References: <20110607195057.GA37735@in-addr.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-pf@freebsd.org Subject: Re: IPv6 day, PF and IPv6 fragments X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:06:24 -0000 Dear All On Tue, 7 Jun 2011, Gary Palmer wrote: > Hi, > > I noticed after running test-ipv6.com at home that I was getting > > 2011-06-07 20:35:55.588335 rule 279/0(match): block in on gif0: 2001:4998:0:6::11 > : frag (0|1424) 80 > 62594: . 0:1392(1392) ack 1 win 8211 > 2011-06-07 20:35:55.588521 rule 279/0(match): block in on gif0: 2001:4998:0:6::11 > : frag (1424|16) > > on my FreeBSD 7.3-RELEASE firewall. "man pf.conf" says > > Currently, only IPv4 fragments are supported and IPv6 fragments are > blocked unconditionally. > > Is this correct? If so, what is the correct way of getting IPv6 fragmented > packets through a pf firewall, or which version of FreeBSD introduces a PF > version that natively handles IPv6 fragments? Yes, PF did not support IPv6 fragmentation. In IPv6 the fragmentation is done in extension headers, which is not very well supported in either version of PF. Extension headers are very complicated to parse (and reassembly should be take place on for scrubbing!) , therefore probably PF implementors decided to write the support later when there is a need for it. However the situation not so bad. We are using PF on FreeBSD since 2005 (FreeBSD 6.x, 7.x 8.x) with IPv6 enabled and we have no complain about that PF is unconditionally dropping packets with fragmentation extension. OpenBSD pf in FreeBSD 8.2 still don't have support for IPv6 fragmentation header. > > Thanks, > > Gary > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 08:23:07 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78A70106567F for ; Wed, 8 Jun 2011 08:23:07 +0000 (UTC) (envelope-from mail@miketm.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 30C688FC1B for ; Wed, 8 Jun 2011 08:23:06 +0000 (UTC) Received: by gxk28 with SMTP id 28so133209gxk.13 for ; Wed, 08 Jun 2011 01:23:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.210.30 with SMTP id m30mr5992794anq.3.1307519899356; Wed, 08 Jun 2011 00:58:19 -0700 (PDT) Received: by 10.100.125.12 with HTTP; Wed, 8 Jun 2011 00:58:19 -0700 (PDT) X-Originating-IP: [123.243.191.201] Date: Wed, 8 Jun 2011 17:58:19 +1000 Message-ID: From: Mike M To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: rule not responding to incoming packets X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 08:23:07 -0000 Hi, I have an issue with pf where incoming packets matching a particular rule, are not being responded to, resulting in public users being unable to access a web server. =A0I'm receiving a SYN flood on 80/TCP (currently ~50mbit @ 100kpps) so am trying to implement some protection on the box. =A0I don't believe the current DDoS is actually causing this issue though, as packets matching the and tables, can establish connections without a problem. Other packets matching this other rule however, seem to be unable to establish a connection. =A0I see the SYN packets in via tcpdump, but they are not returned. =A0Eventually, the connection closes. Another thing I've noticed is that the src limits seem to have an effect (state table is typically 4k-7k entries), as without this in place, the state table fills rapidly, rendering the box near unusable. =A0Using 'synproxy state' also seems to have a similar effect. I have never observed any IP addresses within the table (via 'pfctl -T show -t attacksource') System is FreeBSD 8.2-RELEASE, 1GB RAM, Intel P4 3GHz (2 x CPU w/SMP) Have provided some sanitized information below -- any assistance would be much appreciated.... I'm pulling my hair out. Any other DDoS hardening advice based on below is also very welcome :> Please advise if more information is required. Cheers, - Mike [root@sb ~]# more /etc/pf.conf.conf # --- firewall # # ---- interfaces if_pub =3D "em0" if_priv =3D "em1" # -- loopback if_loop =3D "lo0" # ---- hosts # -- public interface h_pub =3D "10.0.1.1" # -- external hosts # TBA # ---- tables table persist table persist file "/etc/pf/blacklist.pf" table persist file "/etc/pf/whitelist.pf" table persist file "/etc/pf/staff.pf" # ---- set policies # -- rule optimization set optimization aggressive #set optimization normal # -- adaptive timeouts set timeout { tcp.first 20, adaptive.start 30000, adaptive.end 1800000 } # -- set max states set limit states 1800000 # -- statistics logging set loginterface $if_pub # -- don't filter on interface lo set skip on lo # -- normalization scrub in # ---- filter rules # -- block to start block in # -- disallow basic spoof antispoof quick for { lo } # -- whitelist pass quick from # -- blacklists block quick from block quick from # -- block juno flood traffic block in quick proto tcp from any port { 1024, 3072 } to any # -- block UDP floods block in quick proto udp from any to $h_pub # -- HTTP public pass in proto tcp from any to $h_pub port 80 flags S/SA keep state (max-src-conn 100, max-src-conn-rate 20/5, overload flush global) # -- HTTP staff pass in proto tcp from to any port 80 # ---- allow all outbound pass out keep state - EOF - PACKET CAPTURE ON WEB SERVER (10.0.1.1), WATCHING INCOMING PACKETS FROM A REMOTE TEST HOST (10.0.2.2) tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 byt= es 00:00:00.000000 b0:c6:9a:df:0b:80 > 00:30:48:73:16:60, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 7809, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x3e61 (correct), seq 2488345924, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 181704348 ecr 0], length 0 00:00:02.995155 b0:c6:9a:df:0b:80 > 00:30:48:73:16:60, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 7823, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x3d35 (correct), seq 2488345924, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 181704648 ecr 0], length 0 00:00:03.198923 b0:c6:9a:df:0b:80 > 00:30:48:73:16:60, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 54, id 7826, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x3bf5 (correct), seq 2488345924, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 181704968 ecr 0], length 0 00:00:03.199068 b0:c6:9a:df:0b:80 > 00:30:48:73:16:60, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 54, id 7828, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 00:00:03.198994 b0:c6:9a:df:0b:80 > 00:30:48:73:16:60, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 54, id 7830, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 00:00:03.198967 b0:c6:9a:df:0b:80 > 00:30:48:73:16:60, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 54, id 7833, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 00:00:06.198124 b0:c6:9a:df:0b:80 > 00:30:48:73:16:60, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 54, id 7835, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 PACKET CAPTURE ON REMOTE TEST HOST (10.0.2.2), WATCHING OUTGOING PACKETS TO WEB SERVER (10.0.1.1) tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96 byt= es 00:00:00.000000 00:50:56:b8:3c:dd > 00:0c:db:e8:8d:00, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 7809, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x3e61 (correct), seq 2488345924, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 181704348 ecr 0], length 0 00:00:02.995160 00:50:56:b8:3c:dd > 00:0c:db:e8:8d:00, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 7823, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x3d35 (correct), seq 2488345924, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 181704648 ecr 0], length 0 00:00:03.198889 00:50:56:b8:3c:dd > 00:0c:db:e8:8d:00, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 64, id 7826, offset 0, flags [DF], proto TCP (6), length 60) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x3bf5 (correct), seq 2488345924, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 181704968 ecr 0], length 0 00:00:03.198865 00:50:56:b8:3c:dd > 00:0c:db:e8:8d:00, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 7828, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 00:00:03.198888 00:50:56:b8:3c:dd > 00:0c:db:e8:8d:00, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 7830, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 00:00:03.198860 00:50:56:b8:3c:dd > 00:0c:db:e8:8d:00, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 7833, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 00:00:06.197917 00:50:56:b8:3c:dd > 00:0c:db:e8:8d:00, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 7835, offset 0, flags [DF], proto TCP (6), length 48) 10.0.2.2.21254 > 10.0.1.1.80: Flags [S], cksum 0x1bee (correct), seq 2488345924, win 65535, options [mss 1460,sackOK,eol], length 0 - [root@sb ~]# pfctl -s info Status: Enabled for 0 days 00:06:59 Debug: Urgent Interface Stats for em0 IPv4 IPv6 Bytes In 1975306344 0 Bytes Out 39548 0 Packets In Passed 121174 0 Blocked 41031088 0 Packets Out Passed 346 0 Blocked 0 0 State Table Total Rate current entries 6821 searches 41152607 98216.2/s inserts 120838 288.4/s removals 114017 272.1/s Counters match 41151925 98214.6/s bad-offset 0 0.0/s fragment 0 0.0/s short 0 0.0/s normalize 0 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 0 0.0/s proto-cksum 0 0.0/s state-mismatch 0 0.0/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 17662863 42154.8/s synproxy 0 0.0/s [root@sb ~]## pfctl -s memory states hard limit 1800000 src-nodes hard limit 10000 frags hard limit 5000 tables hard limit 1000 table-entries hard limit 200000 [root@sb ~]# vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAIL= URES UMA Kegs: 128, 0, 104, 16, 104, = 0 UMA Zones: 888, 0, 104, 0, 104, = 0 UMA Slabs: 284, 0, 521, 11, 1044, = 0 UMA RCntSlabs: 544, 0, 269, 4, 269, = 0 UMA Hash: 128, 0, 4, 26, 4, = 0 16 Bucket: 76, 0, 53, 47, 72, = 0 32 Bucket: 140, 0, 49, 7, 71, = 0 64 Bucket: 268, 0, 49, 7, 96, = 13 128 Bucket: 524, 0, 107, 5, 19206423, = 112 VM OBJECT: 136, 0, 1235, 128, 21092, = 0 MAP: 140, 0, 7, 21, 7, = 0 KMAP ENTRY: 72, 109657, 36, 229, 4128, = 0 MAP ENTRY: 72, 0, 656, 245, 39175, = 0 DP fakepg: 72, 0, 0, 0, 0, = 0 SG fakepg: 72, 0, 0, 0, 0, = 0 mt_zone: 2056, 0, 261, 0, 261, = 0 16: 16, 0, 2777, 471, 33486, = 0 32: 32, 0, 2202, 284, 34835, = 0 64: 64, 0, 4397, 323, 44761313, = 0 128: 128, 0, 2253, 117, 7923, = 0 256: 256, 0, 579, 51, 3860, = 0 512: 512, 0, 58, 30, 1022, = 0 1024: 1024, 0, 39, 141, 4871, = 0 2048: 2048, 0, 357, 29, 596, = 0 4096: 4096, 0, 132, 32, 5847, = 0 Files: 56, 0, 88, 314, 8532, = 0 TURNSTILE: 72, 0, 141, 39, 141, = 0 umtx pi: 52, 0, 0, 0, 0, = 0 MAC labels: 20, 0, 0, 0, 0, = 0 PROC: 680, 0, 52, 32, 1603, = 0 THREAD: 720, 0, 126, 14, 126, = 0 SLEEPQUEUE: 44, 0, 141, 95, 141, = 0 VMSPACE: 232, 0, 29, 39, 1581, = 0 cpuset: 40, 0, 2, 182, 2, = 0 audit_record: 816, 0, 0, 0, 0, = 0 mbuf_packet: 256, 0, 257, 255, 44749548, = 0 mbuf: 256, 0, 3, 265, 1175, = 0 mbuf_cluster: 2048, 128000, 512, 16, 512, = 0 mbuf_jumbo_page: 4096, 12800, 0, 5, 3, = 0 mbuf_jumbo_9k: 9216, 6400, 0, 0, 0, = 0 mbuf_jumbo_16k: 16384, 3200, 0, 0, 0, = 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, = 0 g_bio: 140, 0, 0, 336, 8357, = 0 ttyinq: 152, 0, 150, 84, 330, = 0 ttyoutq: 256, 0, 80, 10, 176, = 0 ata_request: 204, 0, 0, 114, 2111, = 0 ata_composite: 180, 0, 0, 0, 0, = 0 VNODE: 268, 0, 759, 25, 785, = 0 VNODEPOLL: 60, 0, 0, 0, 0, = 0 S VFS Cache: 72, 0, 761, 87, 7689, = 0 L VFS Cache: 292, 0, 0, 0, 0, = 0 NAMEI: 1024, 0, 0, 48, 24697, = 0 NFSMOUNT: 528, 0, 0, 0, 0, = 0 NFSNODE: 484, 0, 0, 0, 0, = 0 DIRHASH: 1024, 0, 39, 9, 39, = 0 pipe: 392, 0, 4, 36, 1138, = 0 ksiginfo: 80, 0, 69, 987, 109, = 0 itimer: 220, 0, 0, 0, 0, = 0 KNOTE: 72, 0, 0, 159, 14, = 0 socket: 412, 204804, 24, 30, 351, = 0 ipq: 32, 4068, 0, 0, 0, = 0 udp_inpcb: 220, 204804, 3, 51, 295, = 0 udpcb: 8, 204827, 3, 403, 295, = 0 tcp_inpcb: 220, 204804, 7, 47, 15, = 0 tcpcb: 632, 204804, 7, 11, 15, = 0 tcptw: 52, 31824, 0, 0, 0, = 0 syncache: 112, 15365, 0, 105, 8, = 0 hostcache: 76, 15400, 1, 99, 1, = 0 tcpreass: 20, 8112, 0, 0, 0, = 0 sackhole: 20, 0, 0, 0, 0, = 0 sctp_ep: 864, 65536, 0, 0, 0, = 0 sctp_asoc: 1488, 40000, 0, 0, 0, = 0 sctp_laddr: 24, 80040, 0, 145, 2, = 0 sctp_raddr: 420, 80001, 0, 0, 0, = 0 sctp_chunk: 92, 400008, 0, 0, 0, = 0 sctp_readq: 76, 400000, 0, 0, 0, = 0 sctp_stream_msg_out: 64, 400020, 0, 0, 0, = 0 sctp_asconf: 24, 400055, 0, 0, 0, = 0 sctp_asconf_ack: 24, 400055, 0, 0, 0, = 0 ripcb: 220, 204804, 0, 0, 0, = 0 unpcb: 172, 204815, 14, 55, 40, = 0 rtentry: 108, 0, 6, 66, 6, = 0 pfsrctrpl: 124, 10013, 10013, 0, 130907, 1920= 5233 pfrulepl: 828, 0, 15, 5, 15, = 0 pfstatepl: 284, 1800008, 6603, 3519, 131757, = 0 pfaltqpl: 224, 0, 0, 0, 0, = 0 pfpooladdrpl: 68, 0, 0, 0, 0, = 0 pfrktable: 1240, 1002, 5, 10, 10, = 0 pfrkentry: 156, 200000, 15, 35, 15, = 0 pfrkentry2: 156, 0, 0, 0, 0, = 0 pffrent: 16, 5075, 0, 203, 1, = 0 pffrag: 48, 0, 0, 156, 1, = 0 pffrcache: 48, 10062, 0, 0, 0, = 0 pffrcent: 12, 50141, 0, 0, 0, = 0 pfstatescrub: 28, 0, 0, 0, 0, = 0 pfiaddrpl: 100, 0, 0, 0, 0, = 0 pfospfen: 108, 0, 696, 24, 696, = 0 pfosfp: 28, 0, 407, 228, 407, = 0 selfd: 28, 0, 45, 336, 4495, = 0 ip4flow: 40, 50232, 2, 274, 13, = 0 ip6flow: 64, 50228, 0, 0, 0, = 0 SWAPMETA: 276, 121576, 0, 0, 0, = 0 Mountpoints: 644, 0, 3, 9, 3, = 0 FFS inode: 116, 0, 729, 63, 754, = 0 FFS1 dinode: 128, 0, 0, 0, 0, = 0 FFS2 dinode: 256, 0, 729, 36, 754, = 0 [root@sb ~]# netstat -m 262/518/780 mbufs in use (current/cache/total) 258/270/528/128000 mbuf clusters in use (current/cache/total/max) 258/254 mbuf+clusters out of packet secondary zone in use (current/cache) 0/5/5/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 581K/689K/1271K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/4/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines [root@sb ~]# vmstat -i interrupt total rate irq4: uart0 530 0 irq6: fdc0 6 0 irq14: ata0 2174 3 irq15: ata1 35 0 cpu0: timer 1150587 1994 cpu1: timer 1151248 1995 Total 2304580 3994 [root@sb ~]# [root@sb ~]# more /etc/sysctl.conf # -- forward for routing net.inet.ip.forwarding=3D1 # -- security & attack assistance net.inet.tcp.blackhole=3D2 net.inet.udp.blackhole=3D1 net.inet.tcp.drop_synfin=3D1 # -- allow more memory allocation kern.ipc.nmbclusters=3D128000 # -- increase max connections, for DDoS kern.ipc.somaxconn=3D65000 # -- icmp may not RST # -- useful for spoofed icmp/udp floods net.inet.tcp.icmp_may_rst=3D0 # -- max files allowed for in kernel kern.maxfiles=3D65536 kern.maxfilesperproc=3D32768 # -- decrease receive buffer to decrease liklihood of buffer overflow during DDoS #sysctl net.inet.tcp.recvspace=3D4096 # -- less stringent: #sysctl net.inet.tcp.recvspace=3D8192 # -- increase range of outgoing ports net.inet.ip.portrange.first=3D2000 # -- use ports in natural order net.inet.ip.portrange.randomized=3D0 # -- don't create TIME_WAIT for localhost connections net.inet.tcp.nolocaltimewait=3D1 # -- open sockets kern.ipc.maxsockets=3D204800 kern.ipc.maxsockbuf=3D16777216 # -- manipulate TCP keepalive # 10000 + (5000 x 8) =3D 50000 msec (50 sec) #net.inet.tcp.keepidle=3D10000 #net.inet.tcp.keepintvl=3D5000 # -- maximum segment life # -- how long to ait for SYN-ACK response (ACK) before closing # 5 secs net.inet.tcp.msl=3D5000 # -- limit ICMP replies to 50 p/sec net.inet.icmp.icmplim=3D50 # -- polling tuning kern.polling.idle_poll=3D1 kern.polling.reg_frac=3D20 kern.polling.user_frac=3D40 kern.polling.each_burst=3D20 kern.polling.burst_max=3D500 # -- use syncookies to reduce memory allocation during handshake net.inet.tcp.syncookies_only=3D1 # -- needed for pgsql kern.ipc.shm_use_phys=3D1 kern.ipc.shmall=3D32768 kern.ipc.shmmax=3D134217728 kern.ipc.semmap=3D256 [root@sb ~]# [root@sb ~]# sysctl -a | grep tcp net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 1 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.read_locking: 1 net.inet.tcp.recvbuf_max: 262144 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 1 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 2 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 262144 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 8112 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 0 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 0 net.inet.tcp.pcbcount: 7 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 1 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 5000 net.inet.tcp.nolocaltimewait: 1 net.inet.tcp.maxtcptw: 31767 net.inet.flowtable.tcp_expire: 86400 [root@sb ~]# From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 13:25:29 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E14FB106566C for ; Wed, 8 Jun 2011 13:25:29 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 776A78FC17 for ; Wed, 8 Jun 2011 13:25:29 +0000 (UTC) Received: by wyf23 with SMTP id 23so486171wyf.13 for ; Wed, 08 Jun 2011 06:25:28 -0700 (PDT) Received: by 10.216.254.82 with SMTP id g60mr4992111wes.36.1307539527324; Wed, 08 Jun 2011 06:25:27 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id m8sm418355wbh.11.2011.06.08.06.25.25 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 06:25:26 -0700 (PDT) Message-ID: <4DEF7844.7070208@my.gd> Date: Wed, 08 Jun 2011 15:25:24 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: rule not responding to incoming packets X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:25:30 -0000 Hey up Mike, My responses in between your own text. On 6/8/11 9:58 AM, Mike M wrote: > Hi, > > I have an issue with pf where incoming packets matching a particular > rule, are not being responded to, resulting in public users being > unable to access a web server. I'm receiving a SYN flood on 80/TCP > (currently ~50mbit @ 100kpps) so am trying to implement some > protection on the box. I don't believe the current DDoS is actually > causing this issue though, as packets matching the and > tables, can establish connections without a problem. > > Other packets matching this other rule however, seem to be unable to > establish a connection. I see the SYN packets in via tcpdump, but > they are not returned. Eventually, the connection closes. > If they're spoofed IPs, you're blacklisting randomly generated IPs. Call your upstream provider, THEY do have tools to fight DDoS, you don't. > Another thing I've noticed is that the src limits seem to have an > effect (state table is typically 4k-7k entries), as without this in > place, the state table fills rapidly, rendering the box near unusable. > Using 'synproxy state' also seems to have a similar effect. I have > never observed any IP addresses within the table (via > 'pfctl -T show -t attacksource') > Reduce your tcp timeout values so states are removed faster. > System is FreeBSD 8.2-RELEASE, 1GB RAM, Intel P4 3GHz (2 x CPU w/SMP) > > Have provided some sanitized information below -- any assistance would > be much appreciated.... I'm pulling my hair out. Any other DDoS > hardening advice based on below is also very welcome :> > > Please advise if more information is required. > > Cheers, > > - Mike > > > > [root@sb ~]# more /etc/pf.conf.conf > # --- firewall > # > > > # ---- interfaces > if_pub = "em0" > if_priv = "em1" > > # -- loopback > if_loop = "lo0" > > > > # ---- hosts > > # -- public interface > h_pub = "10.0.1.1" > > # -- external hosts > # TBA > > > > # ---- tables > table persist > table persist file "/etc/pf/blacklist.pf" > table persist file "/etc/pf/whitelist.pf" > table persist file "/etc/pf/staff.pf" > > > > # ---- set policies > > # -- rule optimization > set optimization aggressive > #set optimization normal > > # -- adaptive timeouts > set timeout { tcp.first 20, adaptive.start 30000, adaptive.end 1800000 } If you're under DDoS, adjust your timers so that TCP syn packets time out much faster. You can also set it only for your port 80 rule. > > # -- set max states > set limit states 1800000 > > # -- statistics logging > set loginterface $if_pub > > # -- don't filter on interface lo > set skip on lo > > # -- normalization > scrub in > > > > # ---- filter rules > > # -- block to start > block in > > # -- disallow basic spoof > antispoof quick for { lo } I do not see what you're hoping to achieve here. Also, you've set skip on lo, so you're adding rules that won't ever be applied. > > # -- whitelist > pass quick from Ok. > > # -- blacklists > block quick from Ok. > block quick from If these are spoofed IPs generated randomly, you'll saturate your table and you'll make your firewall work a lot for not much... > > # -- block juno flood traffic > block in quick proto tcp from any port { 1024, 3072 } to any Some people are actually stupid enough to use static source ports when flooding ? Ok. > > # -- block UDP floods > block in quick proto udp from any to $h_pub I do hope you don't host DNS on this box. > > # -- HTTP public > pass in proto tcp from any to $h_pub port 80 flags S/SA keep state > (max-src-conn 100, max-src-conn-rate 20/5, overload > flush global) flags S/SA is optional as it is the default. Why did you set $if_pub and $if_priv if you're not using them ? > > # -- HTTP staff > pass in proto tcp from to any port 80 > > # ---- allow all outbound > pass out keep state If you already allow all out, you should adjust your rules above (for the whitelist for example) so they only match INbound packets imo. 1/ I would suggest enabling logging on your default drop rule and run: tcpdump -nei pflog0 ip and port 80 You'll see what rule matches when dropping your packets to port 80. Chances are it will be your default drop rule, if so, this means your port 80 rule is not allowed to create any more state entries. 2/ Double check that your remote client test IP isn't in either or From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 13:56:02 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEDA5106564A for ; Wed, 8 Jun 2011 13:56:02 +0000 (UTC) (envelope-from mail@miketm.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id A31638FC15 for ; Wed, 8 Jun 2011 13:55:55 +0000 (UTC) Received: by gxk28 with SMTP id 28so272039gxk.13 for ; Wed, 08 Jun 2011 06:55:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.39.15 with SMTP id r15mr6209317anj.91.1307541353770; Wed, 08 Jun 2011 06:55:53 -0700 (PDT) Received: by 10.100.125.12 with HTTP; Wed, 8 Jun 2011 06:55:53 -0700 (PDT) X-Originating-IP: [123.243.191.201] In-Reply-To: <4DEF7844.7070208@my.gd> References: <4DEF7844.7070208@my.gd> Date: Wed, 8 Jun 2011 23:55:53 +1000 Message-ID: From: Mike M To: freebsd-pf@freebsd.org, Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: rule not responding to incoming packets X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 13:56:03 -0000 Hi Damien, Thanks for helping out, I've provided responses beneath yours below. On Wed, Jun 8, 2011 at 11:25 PM, Damien Fleuriot wrote: > Hey up Mike, > > > My responses in between your own text. > > On 6/8/11 9:58 AM, Mike M wrote: > > Hi, > > > > I have an issue with pf where incoming packets matching a particular > > rule, are not being responded to, resulting in public users being > > unable to access a web server. I'm receiving a SYN flood on 80/TCP > > (currently ~50mbit @ 100kpps) so am trying to implement some > > protection on the box. I don't believe the current DDoS is actually > > causing this issue though, as packets matching the and > > tables, can establish connections without a problem. > > > > Other packets matching this other rule however, seem to be unable to > > establish a connection. I see the SYN packets in via tcpdump, but > > they are not returned. Eventually, the connection closes. > > > > If they're spoofed IPs, you're blacklisting randomly generated IPs. > > Call your upstream provider, THEY do have tools to fight DDoS, you don't. > > Yeah, I'm aware of that but unfortunately not all providers can or will assist. My approach is to try and deal with what reaches my box as best I can. > > Another thing I've noticed is that the src limits seem to have an > > effect (state table is typically 4k-7k entries), as without this in > > place, the state table fills rapidly, rendering the box near unusable. > > Using 'synproxy state' also seems to have a similar effect. I have > > never observed any IP addresses within the table (via > > 'pfctl -T show -t attacksource') > > > > Reduce your tcp timeout values so states are removed faster. > > I think I've already done this but if you have specific sets or values that you can suggest, I'll definitely take them on board. > > System is FreeBSD 8.2-RELEASE, 1GB RAM, Intel P4 3GHz (2 x CPU w/SMP) > > > > Have provided some sanitized information below -- any assistance would > > be much appreciated.... I'm pulling my hair out. Any other DDoS > > hardening advice based on below is also very welcome :> > > > > Please advise if more information is required. > > > > Cheers, > > > > - Mike > > > > > > > > [root@sb ~]# more /etc/pf.conf.conf > > # --- firewall > > # > > > > > > # ---- interfaces > > if_pub = "em0" > > if_priv = "em1" > > > > # -- loopback > > if_loop = "lo0" > > > > > > > > # ---- hosts > > > > # -- public interface > > h_pub = "10.0.1.1" > > > > # -- external hosts > > # TBA > > > > > > > > # ---- tables > > table persist > > table persist file "/etc/pf/blacklist.pf" > > table persist file "/etc/pf/whitelist.pf" > > table persist file "/etc/pf/staff.pf" > > > > > > > > # ---- set policies > > > > # -- rule optimization > > set optimization aggressive > > #set optimization normal > > > > # -- adaptive timeouts > > set timeout { tcp.first 20, adaptive.start 30000, adaptive.end 1800000 } > > If you're under DDoS, adjust your timers so that TCP syn packets time > out much faster. > > You can also set it only for your port 80 rule. > > Any specific instruction for this? Open to suggestion! This box publicly, is *only* a webserver. > > > # -- set max states > > set limit states 1800000 > > > > # -- statistics logging > > set loginterface $if_pub > > > > # -- don't filter on interface lo > > set skip on lo > > > > # -- normalization > > scrub in > > > > > > > > # ---- filter rules > > > > # -- block to start > > block in > > > > # -- disallow basic spoof > > antispoof quick for { lo } > > I do not see what you're hoping to achieve here. > Also, you've set skip on lo, so you're adding rules that won't ever be > applied. > This one was added on suggestion I had read in forums, if it is unnecessary or not useful, I'll happily remove it? > > > > > # -- whitelist > > pass quick from > > Ok. > > > > > # -- blacklists > > block quick from > > Ok. > > > block quick from > > If these are spoofed IPs generated randomly, you'll saturate your table > and you'll make your firewall work a lot for not much... > > The idea behind this was from the 'overload' statement in my public 80/TCP rule below -- if I can identify those attacking sources, I should be able to drop those packets as quickly and efficiently as possible, no? What I've observed however, is that *zero* source IP's have been added to the table so I'm not sure it's doing its job. This is part of my reason to mail this list, I really don't know if this is a bug, or the behaviour I'm seeing is part of my configuration. If the latter, I'm getting undesired results so am interested in getting suggestions to mitigate this DDoS and remain serviceable to my public clients. > > > > # -- block juno flood traffic > > block in quick proto tcp from any port { 1024, 3072 } to any > > Some people are actually stupid enough to use static source ports when > flooding ? Ok. > > Yep, this happens, so this rule is fairly common to drop these packets quickly. > > > > # -- block UDP floods > > block in quick proto udp from any to $h_pub > > I do hope you don't host DNS on this box. > > Indeed I don't. The only public traffic I need to receive, is HTTP. > > > > # -- HTTP public > > pass in proto tcp from any to $h_pub port 80 flags S/SA keep state > > (max-src-conn 100, max-src-conn-rate 20/5, overload > > flush global) > > flags S/SA is optional as it is the default. > Why did you set $if_pub and $if_priv if you're not using them ? > > Yeah, understand the bit about the flags but this is handled when the conf is processed no? So I assume the inclusion adds no extra processing load. As far as the $if_priv var goes, yeah this is not utilised but again, wouldn't imagine the lack of use would create a noticeable load? It's merely there for future use. > > > > # -- HTTP staff > > pass in proto tcp from to any port 80 > > > > # ---- allow all outbound > > pass out keep state > > If you already allow all out, you should adjust your rules above (for > the whitelist for example) so they only match INbound packets imo. > > Point taken, will adjust, thanks. > > > 1/ I would suggest enabling logging on your default drop rule and run: > tcpdump -nei pflog0 ip and port 80 > Adding 'log' to my rules and monitoring pflog0 creates a substantial load on the box (and fills up the hard drive quickly in /var/log... so I'm not all that keen to add 'log' statements in my rules to do this. I've been looking at em0 with tcpdump to do my diagnostics. Any reason why this wouldn't suffice? > You'll see what rule matches when dropping your packets to port 80. > > Chances are it will be your default drop rule, if so, this means your > port 80 rule is not allowed to create any more state entries. > I really don't understand why the box isn't responding to packets that are matched by the public rule for 80/TCP when those matched by or tables are. This tells me that the DDoS load is not the cause of the problem, but rather the pf rule itself. Can anyone suggest why what I'm seeing, is actually happening? I can't see any drop rules occurring when 'log' is enabled, it's just that the incoming packets don't have anything go back 'out'. Is this kernel related? > > > 2/ Double check that your remote client test IP isn't in either > or > Again, there are *zero* entries in or -- what strikes me as weird, is that even though the overload entry exists in that rule, no IP's are actually inside (via 'pfctl -T show -t attacksource') -- but when I remove the overload statement and reload pf, the state table fills up rapidly and renders the box useless. This tells me that this overload condition is having an effect, but I don't understand why the table is empty. /still pulling hair out... please help! :> - Mike > > _______________________________________________ > 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" > -- Cheers, - Mike M mail@miketm.com +61 409 721 722 From owner-freebsd-pf@FreeBSD.ORG Wed Jun 8 17:26:45 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90C8F106564A for ; Wed, 8 Jun 2011 17:26:45 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D5A258FC08 for ; Wed, 8 Jun 2011 17:26:44 +0000 (UTC) Received: by wyf23 with SMTP id 23so737721wyf.13 for ; Wed, 08 Jun 2011 10:26:43 -0700 (PDT) Received: by 10.227.24.146 with SMTP id v18mr7850420wbb.84.1307554003652; Wed, 08 Jun 2011 10:26:43 -0700 (PDT) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id ge4sm578360wbb.30.2011.06.08.10.26.42 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 10:26:42 -0700 (PDT) Message-ID: <4DEFB0D1.3080607@my.gd> Date: Wed, 08 Jun 2011 19:26:41 +0200 From: Damien Fleuriot User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Mike M References: <4DEF7844.7070208@my.gd> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: rule not responding to incoming packets X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2011 17:26:45 -0000 Hey up Mike, Sorry about the delay, was busy at work ;) On 6/8/11 3:55 PM, Mike M wrote: > Hi Damien, > > Thanks for helping out, I've provided responses beneath yours below. > > On Wed, Jun 8, 2011 at 11:25 PM, Damien Fleuriot > wrote: > > Hey up Mike, > > > My responses in between your own text. > > On 6/8/11 9:58 AM, Mike M wrote: > > Hi, > > [snip] > > > Another thing I've noticed is that the src limits seem to have an > > effect (state table is typically 4k-7k entries), as without this in > > place, the state table fills rapidly, rendering the box near unusable. > > Using 'synproxy state' also seems to have a similar effect. I have > > never observed any IP addresses within the table (via > > 'pfctl -T show -t attacksource') > > > > Reduce your tcp timeout values so states are removed faster. > > > I think I've already done this but if you have specific sets or values > that you can suggest, I'll definitely take them on board. > These are the values we use on a production, high traffic website (3k hits/s) $ sudo pfctl -st tcp.first 5s tcp.opening 5s tcp.established 30s tcp.closing 5s tcp.finwait 10s tcp.closed 5s tcp.tsdiff 10s udp.first 10s udp.single 10s udp.multiple 30s icmp.first 10s icmp.error 5s other.first 10s other.single 10s other.multiple 10s frag 30s interval 5s adaptive.start 156000 states adaptive.end 312000 states src.track 0s > > # -- adaptive timeouts > > set timeout { tcp.first 20, adaptive.start 30000, adaptive.end > 1800000 } > > If you're under DDoS, adjust your timers so that TCP syn packets time > out much faster. > > You can also set it only for your port 80 rule. > > > Any specific instruction for this? Open to suggestion! > This is an example of a timeout set only for a very specific rule: pass quick on $vpnif keep state ( tcp.established 36000 ) > > # -- disallow basic spoof > > antispoof quick for { lo } > > I do not see what you're hoping to achieve here. > Also, you've set skip on lo, so you're adding rules that won't ever be > applied. > > > This one was added on suggestion I had read in forums, if it is > unnecessary or not useful, I'll happily remove it? > Please do, this antispoof won't help you. It would if you applied it on your PHYSICAL interfaces, but on loopback ? no sense at all. > > block quick from > > If these are spoofed IPs generated randomly, you'll saturate your table > and you'll make your firewall work a lot for not much... > > > The idea behind this was from the 'overload' statement in my public > 80/TCP rule below -- if I can identify those attacking sources, I should > be able to drop those packets as quickly and efficiently as possible, > no? What I've observed however, is that *zero* source IP's have been > added to the table so I'm not sure it's doing its job. > This is part of my reason to mail this list, I really don't know if this > is a bug, or the behaviour I'm seeing is part of my configuration. If > the latter, I'm getting undesired results so am interested in getting > suggestions to mitigate this DDoS and remain serviceable to my public > clients. > Obviously they're not hitting the limit you set in your pass rule for port 80 then. > > > > # -- HTTP public > > pass in proto tcp from any to $h_pub port 80 flags S/SA keep state > > (max-src-conn 100, max-src-conn-rate 20/5, overload > > flush global) > > flags S/SA is optional as it is the default. > Why did you set $if_pub and $if_priv if you're not using them ? > > > Yeah, understand the bit about the flags but this is handled when the > conf is processed no? So I assume the inclusion adds no extra > processing load. > Indeed, makes your ruleset file easier to read to the human eye though. > As far as the $if_priv var goes, yeah this is not utilised but again, > wouldn't imagine the lack of use would create a noticeable load? It's > merely there for future use. > You may safely use them like so: pass in on $if_pub inet proto tcp from any to $if_pub port 80 keep state (source track...) Notice that when you say "to $if_pub", PF automagically takes the IPs assigned to your public interface. In case of multiple IPs, PF creates one rule per IP. > > 1/ I would suggest enabling logging on your default drop rule and run: > tcpdump -nei pflog0 ip and port 80 > > > Adding 'log' to my rules and monitoring pflog0 creates a substantial > load on the box (and fills up the hard drive quickly in /var/log... so > I'm not all that keen to add 'log' statements in my rules to do this. > I've been looking at em0 with tcpdump to do my diagnostics. Any reason > why this wouldn't suffice? > Indeed, the idea is to not leave this running for very long... Find below the output produced by tcpdump'ing pflog0 with the -e flag set (-e adds rule numbers): # tcpdump -nei pflog0 ip tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 96 bytes 19:21:41.070165 rule 47/0(match): pass in on bce0: 109.0.65.3.12628 > 88.190.222.254.53: [|domain] 19:21:42.819873 rule 24/0(match): block in on bce0: 88.190.13.231.5353 > 224.0.0.251.5353: [|domain] 19:21:43.821475 rule 24/0(match): block in on bce0: 88.190.13.231.5353 > 224.0.0.251.5353: [|domain] ^C 3 packets captured 9 packets received by filter 0 packets dropped by kernel Notice how the log tells me what rule the packet matched (and ultimately passed or dropped). Later on, I can check my rules like so: pfctl -vvsr This outputs rules with their number, for example rule 47 is: @47 pass in log on bce0 inet proto udp from any to 88.190.222.254 port = domain keep state (if-bound) [ Evaluations: 4130668 Packets: 107887 Bytes: 10484013 States: 0 ] [ Inserted: uid 0 pid 20941 ] > > You'll see what rule matches when dropping your packets to port 80. > > Chances are it will be your default drop rule, if so, this means your > port 80 rule is not allowed to create any more state entries. > > > I really don't understand why the box isn't responding to packets that > are matched by the public rule for 80/TCP when those matched by > or tables are. This tells me that the DDoS load is > not the cause of the problem, but rather the pf rule itself. Can anyone > suggest why what I'm seeing, is actually happening? > See above my response about "pfctl -vvsr", it will give you counters for each of your rules. > I can't see any drop rules occurring when 'log' is enabled, it's just > that the incoming packets don't have anything go back 'out'. Is this > kernel related? > Then that would mean your rule works and connections are sent to your backend web server (same machine ? diff machine ?). You will want to ensure your backend web server can actually reach your clients' public IPs. > > 2/ Double check that your remote client test IP isn't in either > or > > > > Again, there are *zero* entries in or -- what > strikes me as weird, is that even though the overload entry exists in > that rule, no IP's are actually inside (via 'pfctl -T > show -t attacksource') -- but when I remove the overload statement and > reload pf, the state table fills up rapidly and renders the box useless. > This tells me that this overload condition is having an effect, but I > don't understand why the table is empty. > See above about "pfctl -vvsr" > /still pulling hair out... please help! :> > > - Mike > > > > _______________________________________________ > 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 > " > > > > > -- > Cheers, > > - Mike M > mail@miketm.com > +61 409 721 722 > > From owner-freebsd-pf@FreeBSD.ORG Thu Jun 9 05:47:54 2011 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A775106566C for ; Thu, 9 Jun 2011 05:47:54 +0000 (UTC) (envelope-from mail@miketm.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1266F8FC0A for ; Thu, 9 Jun 2011 05:47:53 +0000 (UTC) Received: by yie13 with SMTP id 13so886960yie.13 for ; Wed, 08 Jun 2011 22:47:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.131.29 with SMTP id i29mr255062ann.47.1307596717160; Wed, 08 Jun 2011 22:18:37 -0700 (PDT) Received: by 10.100.125.12 with HTTP; Wed, 8 Jun 2011 22:18:37 -0700 (PDT) X-Originating-IP: [123.243.191.201] In-Reply-To: <4DEFB0D1.3080607@my.gd> References: <4DEF7844.7070208@my.gd> <4DEFB0D1.3080607@my.gd> Date: Thu, 9 Jun 2011 15:18:37 +1000 Message-ID: From: Mike M To: Damien Fleuriot Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: rule not responding to incoming packets X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 05:47:54 -0000 Damien, Further responses below. On Thu, Jun 9, 2011 at 3:26 AM, Damien Fleuriot wrote: > Hey up Mike, > > > Sorry about the delay, was busy at work ;) > > On 6/8/11 3:55 PM, Mike M wrote: > > Hi Damien, > > > > Thanks for helping out, I've provided responses beneath yours below. > > > > On Wed, Jun 8, 2011 at 11:25 PM, Damien Fleuriot > > wrote: > > > > Hey up Mike, > > > > > > My responses in between your own text. > > > > On 6/8/11 9:58 AM, Mike M wrote: > > > Hi, > > > > [snip] > > > > > Another thing I've noticed is that the src limits seem to have an > > > effect (state table is typically 4k-7k entries), as without this in > > > place, the state table fills rapidly, rendering the box near > unusable. > > > Using 'synproxy state' also seems to have a similar effect. I > have > > > never observed any IP addresses within the table > (via > > > 'pfctl -T show -t attacksource') > > > > > > > Reduce your tcp timeout values so states are removed faster. > I understand that lowering these values helps remove the states quicker (and thus helps prevent the table from filling up so easily), but I don't believe this is the actual problem here (and the state table will still fill regardless when the packet rate is high). What I'm observing, is packets not being returned and thus connections in the handshake not being fully established. However, it's not happening for all connecting clients... I can connect to the web server fine because I match the table rule, as can others in the rule. The problem is only prevalent for users matching the rule containing the overload. However, if I remove the 'overload' bits with the max src settings, the state table fills instantly and renders the box unusable. However, the table never contains any entries, so how does this make sense? > > > > > > I think I've already done this but if you have specific sets or values > > that you can suggest, I'll definitely take them on board. > > > > These are the values we use on a production, high traffic website (3k > hits/s) > > $ sudo pfctl -st > tcp.first 5s > tcp.opening 5s > tcp.established 30s > tcp.closing 5s > tcp.finwait 10s > tcp.closed 5s > tcp.tsdiff 10s > udp.first 10s > udp.single 10s > udp.multiple 30s > icmp.first 10s > icmp.error 5s > other.first 10s > other.single 10s > other.multiple 10s > frag 30s > interval 5s > adaptive.start 156000 states > adaptive.end 312000 states > src.track 0s > > > > > # -- adaptive timeouts > > > set timeout { tcp.first 20, adaptive.start 30000, adaptive.end > > 1800000 } > > > > If you're under DDoS, adjust your timers so that TCP syn packets time > > out much faster. > > > > You can also set it only for your port 80 rule. > > > > > > Any specific instruction for this? Open to suggestion! > > > > This is an example of a timeout set only for a very specific rule: > pass quick on $vpnif keep state ( tcp.established 36000 ) > > > > > # -- disallow basic spoof > > > antispoof quick for { lo } > > > > I do not see what you're hoping to achieve here. > > Also, you've set skip on lo, so you're adding rules that won't ever > be > > applied. > > > > > > This one was added on suggestion I had read in forums, if it is > > unnecessary or not useful, I'll happily remove it? > > > > Please do, this antispoof won't help you. > > It would if you applied it on your PHYSICAL interfaces, but on loopback > ? no sense at all. > Roger that, will do. > > > > > block quick from > > > > If these are spoofed IPs generated randomly, you'll saturate your > table > > and you'll make your firewall work a lot for not much... > > > > > > The idea behind this was from the 'overload' statement in my public > > 80/TCP rule below -- if I can identify those attacking sources, I should > > be able to drop those packets as quickly and efficiently as possible, > > no? What I've observed however, is that *zero* source IP's have been > > added to the table so I'm not sure it's doing its job. > > This is part of my reason to mail this list, I really don't know if this > > is a bug, or the behaviour I'm seeing is part of my configuration. If > > the latter, I'm getting undesired results so am interested in getting > > suggestions to mitigate this DDoS and remain serviceable to my public > > clients. > > > > Obviously they're not hitting the limit you set in your pass rule for > port 80 then. > But how is it, that when I remove this bit from the rule, the state table fills instantly? It seems to have some sort of effect, but not the one I'd expect. This, is confusing. > > > > > > > > # -- HTTP public > > > pass in proto tcp from any to $h_pub port 80 flags S/SA keep state > > > (max-src-conn 100, max-src-conn-rate 20/5, overload > > > flush global) > > > > flags S/SA is optional as it is the default. > > Why did you set $if_pub and $if_priv if you're not using them ? > > > > > > Yeah, understand the bit about the flags but this is handled when the > > conf is processed no? So I assume the inclusion adds no extra > > processing load. > > > > Indeed, makes your ruleset file easier to read to the human eye though. > > > > As far as the $if_priv var goes, yeah this is not utilised but again, > > wouldn't imagine the lack of use would create a noticeable load? It's > > merely there for future use. > > > > You may safely use them like so: > > pass in on $if_pub inet proto tcp from any to $if_pub port 80 keep state > (source track...) > > Notice that when you say "to $if_pub", PF automagically takes the IPs > assigned to your public interface. > > In case of multiple IPs, PF creates one rule per IP. > > > > > 1/ I would suggest enabling logging on your default drop rule and > run: > > tcpdump -nei pflog0 ip and port 80 > > > > > > Adding 'log' to my rules and monitoring pflog0 creates a substantial > > load on the box (and fills up the hard drive quickly in /var/log... so > > I'm not all that keen to add 'log' statements in my rules to do this. > > I've been looking at em0 with tcpdump to do my diagnostics. Any reason > > why this wouldn't suffice? > > > > Indeed, the idea is to not leave this running for very long... > > Find below the output produced by tcpdump'ing pflog0 with the -e flag > set (-e adds rule numbers): > > # tcpdump -nei pflog0 ip > tcpdump: WARNING: pflog0: no IPv4 address assigned > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size > 96 bytes > 19:21:41.070165 rule 47/0(match): pass in on bce0: 109.0.65.3.12628 > > 88.190.222.254.53: [|domain] > 19:21:42.819873 rule 24/0(match): block in on bce0: 88.190.13.231.5353 > > 224.0.0.251.5353: [|domain] > 19:21:43.821475 rule 24/0(match): block in on bce0: 88.190.13.231.5353 > > 224.0.0.251.5353: [|domain] > ^C > 3 packets captured > 9 packets received by filter > 0 packets dropped by kernel > > > Notice how the log tells me what rule the packet matched (and ultimately > passed or dropped). > I've actually already done this and I can see the rule in question, is the one being matched. But there is no other block rule or anything else that helps me understand why packets don't go back out, and thus ending up with a fully established connection. If it's the kernel causing it, why can sources in the and table establish connections without problem? Is what I'm seeing, some sort of bug? > > Later on, I can check my rules like so: pfctl -vvsr > > This outputs rules with their number, for example rule 47 is: > @47 pass in log on bce0 inet proto udp from any to 88.190.222.254 port = > domain keep state (if-bound) > [ Evaluations: 4130668 Packets: 107887 Bytes: 10484013 States: > 0 ] > [ Inserted: uid 0 pid 20941 ] > > > > > You'll see what rule matches when dropping your packets to port 80. > > > > Chances are it will be your default drop rule, if so, this means your > > port 80 rule is not allowed to create any more state entries. > > > > > > I really don't understand why the box isn't responding to packets that > > are matched by the public rule for 80/TCP when those matched by > > or tables are. This tells me that the DDoS load is > > not the cause of the problem, but rather the pf rule itself. Can anyone > > suggest why what I'm seeing, is actually happening? > > > > See above my response about "pfctl -vvsr", it will give you counters for > each of your rules. > > > I can't see any drop rules occurring when 'log' is enabled, it's just > > that the incoming packets don't have anything go back 'out'. Is this > > kernel related? > > > > Then that would mean your rule works and connections are sent to your > backend web server (same machine ? diff machine ?). > The webserver is the same machine. Routing back works, if I stick the source IP's that are failing with this rule, in the or tables, everything works fine. This leads me to believe it's not a kernel setting (which is not dependant on IP), but rather a problem with this particular rule. But how to fix it? > > You will want to ensure your backend web server can actually reach your > clients' public IPs. > > > > > 2/ Double check that your remote client test IP isn't in either > > or > > > > > > > > Again, there are *zero* entries in or -- what > > strikes me as weird, is that even though the overload entry exists in > > that rule, no IP's are actually inside (via 'pfctl -T > > show -t attacksource') -- but when I remove the overload statement and > > reload pf, the state table fills up rapidly and renders the box useless. > > This tells me that this overload condition is having an effect, but I > > don't understand why the table is empty. > > > > See above about "pfctl -vvsr" > Unfortunately this doesn't help me. I can see the inbound rule is matched, but there is no explanation for why the packets don't get sent back... the handshake never completes so the connection isn't established... herein lies my problem! > > > /still pulling hair out... please help! :> > > > > - Mike > Any ideas? :> Cheers, - Mike