From owner-freebsd-ipfw@FreeBSD.ORG Sun Nov 4 23:31:42 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 50E4016A419 for ; Sun, 4 Nov 2007 23:31:42 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from mgw-ext11.nokia.com (smtp.nokia.com [131.228.20.170]) by mx1.freebsd.org (Postfix) with ESMTP id AD7B813C491 for ; Sun, 4 Nov 2007 23:31:41 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA4NEx4p015308; Mon, 5 Nov 2007 01:15:00 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 01:14:59 +0200 Received: from siebe101.NOE.Nokia.com ([172.30.195.47]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 01:14:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Nov 2007 07:14:54 +0800 Message-ID: In-Reply-To: <932971.53959.qm@web88014.mail.re2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFW Problem Thread-Index: AcgecIJ0UxBnczz5Tg2VwZgapmywmwAx4lnA References: <932971.53959.qm@web88014.mail.re2.yahoo.com> From: To: , X-OriginalArrivalTime: 04 Nov 2007 23:14:58.0674 (UTC) FILETIME=[84CD5D20:01C81F38] X-Nokia-AV: Clean Cc: Subject: RE: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2007 23:31:42 -0000 Hmm, I may well be missing something very obvious but rule 01000 seems to be doing exactly what it says it will. Are you sure you meant "deny" rather than "allow" on rule 01000 ? It seems very unfreindly to allow outgoing TCP connections and then the minute they are established deny any return traffic !! Usually the "established" test is there to detect valid incoming traffic associated with your own outgoing "safe" connections. Cheers John=20 -----Original Message----- From: owner-freebsd-ipfw@freebsd.org [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of ext Gardner Bell Sent: Sunday, November 04, 2007 8:51 AM To: freebsd-ipfw@freebsd.org Subject: IPFW Problem I'm hoping some of you can help me out with the problem that I'm having as I'm not very good when it comes to networking.. I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my LAN's firewall/router. After I initially access certain http sites, particularly google groups and yahoo web mail I'm noticing subsequent attempts take > 2mins to resolve the next link that I am interested in reading. =20 This appears to be caused by rule 01000 as the counter increases each time I access one of the above mentioned sites. Short of removing this rule, is there any other way that I can fix this issue? Below is a listing of my present ruleset and a tcpdump of a Windows XP machine trying to access a link on google groups. regards, Gardner mx1# ipfw show 00100 76 11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 00200 0 0 deny log logamount 10 ip from 127.0.0.1 to any 00300 0 0 deny log logamount 10 ip from any to 127.0.0.1 00400 0 0 deny log logamount 10 ip from any to any not verrevpath in 00500 0 0 deny log logamount 10 ip from any to any ipoptions ssrr,lsrr,rr,ts in 00600 0 0 deny ip from any to any frag 00700 0 0 allow icmp from any to any icmptypes 0,3,11,12 00800 1081 452405 divert 8668 ip from any to any via bge0 00900 0 0 check-state 01000 36 17682 deny tcp from any to any established 01100 2704 853904 allow ip from any to any via bge1 keep-state 01200 262 57586 allow tcp from any to any dst-port 80 keep-state 01300 0 0 allow tcp from any to any dst-port 443 keep-state 01400 102 7752 allow udp from me to any dst-port 123 keep-state 01500 0 0 allow tcp from me to any dst-port 53 setup keep-state 01600 169 30563 allow udp from me to any dst-port 53 keep-state 01700 0 0 allow tcp from any to any dst-port 1863 setup keep-state 01800 0 0 allow log logamount 10 udp from any to 255.255.255.255 dst-port 68 in via bge0 01900 0 0 allow tcp from x.x.x.x to x.x.x.x dst-port 22 keep-state 02000 0 0 deny log logamount 10 ip from any to any 65535 1 396 deny ip from any to any 131219 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 55490, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->4d44)!) x.x.x.x.2471 > 64.233.179.99.80: ., cksum 0x2bf0 (correct), a ck 26946 win 64330 046227 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 63, id 55493, offset 0, flags [DF], proto: TCP (6), length: 48, bad cksum 0 (->2a14)!) x.x.x.x.2474 > 72.14.207.99.80: S, cksum 0xf365 (correct), 22 96693740:2296693740(0) win 65535 007127 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 56, id 48846, offset 0, flags [none], proto: TCP (6), length: 48) 72.14.207.99.80 > x.x.x.x.2474: S, cksum 0x8043 (correct), 2154814567:2154814567(0 ) ack 2296693741 win 5720 000323 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 55494, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->2a1b)!) x.x.x.x.2474 > 72.14.207.99.80: ., cksum 0xc341 (correct), ac k 1 win 65535 000293 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 1155: (tos 0x0, ttl 63, id 55495, offset 0, fla gs [DF], proto: TCP (6), length: 1141, bad cksum 0 (->25cd)!) x.x.x.x.2474 > 72.14.207.99.80: P 1:1102(1101) ack 1 win 65535 015474 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 56, id 48847, offset 0, flags [none], proto: TCP (6), length: 40) 72.14.207.99.80 > x.x.x.x.2474: ., cksum 0xa0d9 (correct), ack 1102 win 7707 000879 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 383: (tos 0x0, ttl 56, id 48848, offset 0, flag s [none], proto: TCP (6), length: 369) 72.14.207.99.80 > x.x.x.x.2474: P 1:330(329) ack 1102 win 7707 003365 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 1484: (tos 0x0, ttl 54, id 5049, offset 0, flag s [none], proto: TCP (6), length: 1470) 64.233.179.99.80 > x.x.x.x.2472: . 1:1431(1430) ack 944 win 6797 001463 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 1484: (tos 0x0, ttl 54, id 5050, offset 0, flag s [none], proto: TCP (6), length: 1470) 64.233.179.99.80 > x.x.x.x.2472: . 1431:2861(1430) ack 944 win 6797 000478 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 55498, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->4d3c)!) x.x.x.x.2472 > 64.233.179.99.80: ., cksum 0xa354 (correct), a ck 2861 win 65535 000694 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 348: (tos 0x0, ttl 54, id 5051, offset 0, flags [none], proto: TCP (6), length: 334) 64.233.179.99.80 > x.x.x.x.2472: P 2861:3155(294) ack 944 win 6797 002086 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 841: (tos 0x0, ttl 63, id 55503, offset 0, flag s [DF], proto: TCP (6), length: 827, bad cksum 0 (->4a24)!) x.x.x.x.2471 > 64.233.179.99.80: P 900:1687(787) ack 26946 win 64330 039910 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 54, id 65197, offset 0, flags [none], proto: TCP (6), length: 40) 64.233.179.99.80 > x.x.x.x.2471: ., cksum 0xfff1 (correct), ack 1687 win 9270 081626 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 55504, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->2a11)!) x.x.x.x.2474 > 72.14.207.99.80: ., cksum 0xbef4 (correct), ac k 330 win 65206 006714 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 55505, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->4d35)!) x.x.x.x.2472 > 64.233.179.99.80: ., cksum 0xa354 (correct), a ck 3155 win 65241 023252 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 1484: (tos 0x0, ttl 54, id 65198, offset 0, fla gs [none], proto: TCP (6), length: 1470) 64.233.179.99.80 > x.x.x.x.2471: . 26946:28376(1430) ack 1687 win 9270 001610 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 1460: (tos 0x0, ttl 54, id 65199, offset 0, fla gs [none], proto: TCP (6), length: 1446) 64.233.179.99.80 > x.x.x.x.2471: P 28376:29782(1406) ack 1687 win 9270 000456 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 55506, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->4d34)!) x.x.x.x.2471 > 64.233.179.99.80: ., cksum 0x1914 (correct), a ck 29782 win 65535 000861 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 1484: (tos 0x0, ttl 54, id 65200, offset 0, fla gs [none], proto: TCP (6), length: 1470) 64.233.179.99.80 > x.x.x.x.2471: . 29782:31212(1430) ack 1687 win 9270 036857 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length 116: (tos 0x0, ttl 54, id 65201, offset 0, flag s [none], proto: TCP (6), length: 102) 64.233.179.99.80 > x.x.x.x.2471: P 31212:31274(62) ack 1687 win 9270 000164 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 63, id 55507, offset 0, flags [DF], proto: TCP (6), length: 40, bad cksum 0 (->4d33)!) x.x.x.x.2471 > 64.233.179.99.80: ., cksum 0x1340 (correct), a ck 31274 win 65535 _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 00:03:32 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0DA616A420 for ; Mon, 5 Nov 2007 00:03:32 +0000 (UTC) (envelope-from me@sharktooth.org) Received: from onyx.sharktooth.org (166-70-186-42.ip.xmission.com [166.70.186.42]) by mx1.freebsd.org (Postfix) with ESMTP id D62A913C48A for ; Mon, 5 Nov 2007 00:03:32 +0000 (UTC) (envelope-from me@sharktooth.org) Received: from localhost.sharktooth.org ([::1] helo=users.sharktooth.org) by onyx.sharktooth.org with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Ioowj-0007rG-Cx; Sun, 04 Nov 2007 16:32:02 -0700 Received: from 207.173.157.85 (SquirrelMail authenticated user me@sharktooth.org) by users.sharktooth.org with HTTP; Sun, 4 Nov 2007 16:32:01 -0700 (MST) Message-ID: <14144.207.173.157.85.1194219121.squirrel@users.sharktooth.org> In-Reply-To: References: <932971.53959.qm@web88014.mail.re2.yahoo.com> Date: Sun, 4 Nov 2007 16:32:01 -0700 (MST) From: "Jason Lewis" To: john.w.court@nokia.com User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Mail-From: me@sharktooth.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on onyx.sharktooth.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=NO_RELAYS autolearn=failed version=3.1.7 X-SA-Exim-Version: 4.2 X-SA-Exim-Scanned: Yes (on onyx.sharktooth.org) Cc: freebsd-ipfw@freebsd.org, gbell72@rogers.com Subject: RE: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 00:03:33 -0000 Greg, My guess would be to look at rule 00800. I suspect that the network that you are having problems with is on BGE0. NAT and keep-state do not play well with each other. Jason On Sun, November 4, 2007 4:14 pm, john.w.court@nokia.com wrote: > Hmm, I may well be missing something very obvious but rule 01000 seems > to be doing exactly what it says it will. Are you sure you meant "deny" > rather than "allow" on rule 01000 ? It seems very unfreindly to allow > outgoing TCP connections and then the minute they are established deny > any return traffic !! Usually the "established" test is there to detect > valid incoming traffic associated with your own outgoing "safe" > connections. > > Cheers > > John > > -----Original Message----- > From: owner-freebsd-ipfw@freebsd.org > [mailto:owner-freebsd-ipfw@freebsd.org] On Behalf Of ext Gardner Bell > Sent: Sunday, November 04, 2007 8:51 AM > To: freebsd-ipfw@freebsd.org > Subject: IPFW Problem > > I'm hoping some of you can help me out with the problem that I'm having > as I'm not very good when it comes to networking.. > > I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my > LAN's firewall/router. After I initially access certain http sites, > particularly google groups and yahoo web mail I'm noticing subsequent > attempts take > 2mins to resolve the next link that I am interested in > reading. > > This appears to be caused by rule 01000 as the counter increases each > time I access one of the above mentioned sites. > > Short of removing this rule, is there any other way that I can fix this > issue? Below is a listing of my present ruleset and a tcpdump of a > Windows XP machine trying to access a link on google groups. > > regards, > > Gardner > > mx1# ipfw show > 00100 76 11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > 00200 0 0 deny log logamount 10 ip from 127.0.0.1 to any > 00300 0 0 deny log logamount 10 ip from any to 127.0.0.1 > 00400 0 0 deny log logamount 10 ip from any to any not > verrevpath in > 00500 0 0 deny log logamount 10 ip from any to any ipoptions > ssrr,lsrr,rr,ts in > 00600 0 0 deny ip from any to any frag > 00700 0 0 allow icmp from any to any icmptypes 0,3,11,12 > 00800 1081 452405 divert 8668 ip from any to any via bge0 > 00900 0 0 check-state > 01000 36 17682 deny tcp from any to any established > 01100 2704 853904 allow ip from any to any via bge1 keep-state 01200 > 262 57586 allow tcp from any to any dst-port 80 keep-state > 01300 0 0 allow tcp from any to any dst-port 443 keep-state > 01400 102 7752 allow udp from me to any dst-port 123 keep-state > 01500 0 0 allow tcp from me to any dst-port 53 setup keep-state > 01600 169 30563 allow udp from me to any dst-port 53 keep-state > 01700 0 0 allow tcp from any to any dst-port 1863 setup > keep-state > 01800 0 0 allow log logamount 10 udp from any to > 255.255.255.255 dst-port 68 in via bge0 > 01900 0 0 allow tcp from x.x.x.x to x.x.x.x dst-port 22 > keep-state > 02000 0 0 deny log logamount 10 ip from any to any > 65535 1 396 deny ip from any to any > > 131219 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 54: (tos 0x0, ttl 63, id 55490, offset 0, flags [DF], proto: > TCP (6), length: 40, bad cksum 0 (->4d44)!) x.x.x.x.2471 >> 64.233.179.99.80: ., cksum 0x2bf0 (correct), a > ck 26946 win 64330 > 046227 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 62: (tos 0x0, ttl 63, id 55493, offset 0, flags [DF], proto: > TCP (6), length: 48, bad cksum 0 (->2a14)!) x.x.x.x.2474 >> 72.14.207.99.80: S, cksum 0xf365 (correct), 22 > 96693740:2296693740(0) win 65535 > 007127 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 62: (tos 0x0, ttl 56, id 48846, offset 0, flags [none], proto: > TCP (6), length: 48) 72.14.207.99.80 > x.x.x.x.2474: S, cksum 0x8043 > (correct), 2154814567:2154814567(0 > ) ack 2296693741 win 5720 > 000323 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 54: (tos 0x0, ttl 63, id 55494, offset 0, flags [DF], proto: > TCP (6), length: 40, bad cksum 0 (->2a1b)!) x.x.x.x.2474 >> 72.14.207.99.80: ., cksum 0xc341 (correct), ac > k 1 win 65535 > 000293 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 1155: (tos 0x0, ttl 63, id 55495, offset 0, fla gs [DF], proto: > TCP (6), length: 1141, bad cksum 0 (->25cd)!) > x.x.x.x.2474 > 72.14.207.99.80: P 1:1102(1101) ack 1 win > 65535 > 015474 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 60: (tos 0x0, ttl 56, id 48847, offset 0, flags [none], proto: > TCP (6), length: 40) 72.14.207.99.80 > x.x.x.x.2474: ., cksum 0xa0d9 > (correct), ack 1102 win 7707 > 000879 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 383: (tos 0x0, ttl 56, id 48848, offset 0, flag s [none], proto: > TCP (6), length: 369) 72.14.207.99.80 > x.x.x.x.2474: > P 1:330(329) ack 1102 win 7707 > 003365 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 1484: (tos 0x0, ttl 54, id 5049, offset 0, flag s [none], proto: > TCP (6), length: 1470) 64.233.179.99.80 > > x.x.x.x.2472: . 1:1431(1430) ack 944 win 6797 > 001463 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 1484: (tos 0x0, ttl 54, id 5050, offset 0, flag s [none], proto: > TCP (6), length: 1470) 64.233.179.99.80 > > x.x.x.x.2472: . 1431:2861(1430) ack 944 win 6797 > 000478 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 54: (tos 0x0, ttl 63, id 55498, offset 0, flags [DF], proto: > TCP (6), length: 40, bad cksum 0 (->4d3c)!) x.x.x.x.2472 >> 64.233.179.99.80: ., cksum 0xa354 (correct), a > ck 2861 win 65535 > 000694 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 348: (tos 0x0, ttl 54, id 5051, offset 0, flags [none], proto: > TCP (6), length: 334) 64.233.179.99.80 > x.x.x.x.2472: > P 2861:3155(294) ack 944 win 6797 > 002086 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 841: (tos 0x0, ttl 63, id 55503, offset 0, flag s [DF], proto: > TCP (6), length: 827, bad cksum 0 (->4a24)!) > x.x.x.x.2471 > 64.233.179.99.80: P 900:1687(787) ack 26946 win 64330 > 039910 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 60: (tos 0x0, ttl 54, id 65197, offset 0, flags [none], proto: > TCP (6), length: 40) 64.233.179.99.80 > x.x.x.x.2471: > ., cksum 0xfff1 (correct), ack 1687 win 9270 > 081626 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 54: (tos 0x0, ttl 63, id 55504, offset 0, flags [DF], proto: > TCP (6), length: 40, bad cksum 0 (->2a11)!) x.x.x.x.2474 >> 72.14.207.99.80: ., cksum 0xbef4 (correct), ac > k 330 win 65206 > 006714 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 54: (tos 0x0, ttl 63, id 55505, offset 0, flags [DF], proto: > TCP (6), length: 40, bad cksum 0 (->4d35)!) x.x.x.x.2472 >> 64.233.179.99.80: ., cksum 0xa354 (correct), a > ck 3155 win 65241 > 023252 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 1484: (tos 0x0, ttl 54, id 65198, offset 0, fla gs [none], > proto: TCP (6), length: 1470) 64.233.179.99.80 > > x.x.x.x.2471: . 26946:28376(1430) ack 1687 win 9270 001610 > 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), length > 1460: (tos 0x0, ttl 54, id 65199, offset 0, fla gs [none], proto: TCP > (6), length: 1446) 64.233.179.99.80 > > x.x.x.x.2471: P 28376:29782(1406) ack 1687 win 9270 > 000456 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 54: (tos 0x0, ttl 63, id 55506, offset 0, flags [DF], proto: > TCP (6), length: 40, bad cksum 0 (->4d34)!) x.x.x.x.2471 >> 64.233.179.99.80: ., cksum 0x1914 (correct), a > ck 29782 win 65535 > 000861 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 1484: (tos 0x0, ttl 54, id 65200, offset 0, fla gs [none], > proto: TCP (6), length: 1470) 64.233.179.99.80 > > x.x.x.x.2471: . 29782:31212(1430) ack 1687 win 9270 > 036857 00:13:5f:04:bd:05 > 00:e0:81:2e:c1:aa, ethertype IPv4 (0x0800), > length 116: (tos 0x0, ttl 54, id 65201, offset 0, flag s [none], proto: > TCP (6), length: 102) 64.233.179.99.80 > x.x.x.x.2471: > P 31212:31274(62) ack 1687 win 9270 > 000164 00:e0:81:2e:c1:aa > 00:13:5f:04:bd:05, ethertype IPv4 (0x0800), > length 54: (tos 0x0, ttl 63, id 55507, offset 0, flags [DF], proto: > TCP (6), length: 40, bad cksum 0 (->4d33)!) x.x.x.x.2471 >> 64.233.179.99.80: ., cksum 0x1340 (correct), a > ck 31274 win 65535 > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 00:11:35 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2289F16A418 for ; Mon, 5 Nov 2007 00:11:35 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from mgw-ext13.nokia.com (smtp.nokia.com [131.228.20.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB1713C4C4 for ; Mon, 5 Nov 2007 00:11:34 +0000 (UTC) (envelope-from john.w.court@nokia.com) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA509MPO015007; Mon, 5 Nov 2007 02:09:43 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 02:09:34 +0200 Received: from siebe101.NOE.Nokia.com ([172.30.195.47]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 02:09:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Nov 2007 08:09:20 +0800 Message-ID: In-Reply-To: <472E5A58.5090707@auckland.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPFW Problem Thread-Index: AcgfPUCCrcGgK/c0TBqLPaR9G7/RdQAAj8Gw References: <932971.53959.qm@web88014.mail.re2.yahoo.com> <472E5A58.5090707@auckland.ac.nz> From: To: X-OriginalArrivalTime: 05 Nov 2007 00:09:23.0999 (UTC) FILETIME=[1F166AF0:01C81F40] X-Nokia-AV: Clean Cc: freebsd-ipfw@freebsd.org, gbell72@rogers.com Subject: RE: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 00:11:35 -0000 Yep bad advice on my part, should have re-read the man page first. One thing that might also be useful however would be to use the "ipfw -e -d show" command when this occuring so that the expired and dynamic rule set is also displayed. I have logged bugs with IP6 keep-state in the past but not IP4 so this might not help but it can't hurt having more information :-) Cheers John=20 -----Original Message----- From: ext Russell Fulton [mailto:r.fulton@auckland.ac.nz]=20 Sent: Monday, November 05, 2007 9:49 AM To: Court John.W (Nokia-ES/Robina) Cc: gbell72@rogers.com; freebsd-ipfw@freebsd.org Subject: Re: IPFW Problem john.w.court@nokia.com wrote: > Hmm, I may well be missing something very obvious but rule 01000 seems > to be doing exactly what it says it will. Are you sure you meant "deny" > rather than "allow" on rule 01000 ? Note that it is immediately after the check state rule. What the Gardner intended was to drop established tcp traffic that was not part of a session for which there was already state. In fact this rule is redundant since (assuming I've read the rule set correctly) such traffic will get caught by the final deny rule. What is odd about this problem is that it appears to be a timeout problem and thus probably not related to the firewall at all. To me it seems that the initial SYN packet is getting lost and the retry gets through, hence the delay. I suggested to Gardner that he log all dropped packets so he can see if it really is the firewall which is causing the problem. Russell From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 01:04:23 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7078416A46D for ; Mon, 5 Nov 2007 01:04:23 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by mx1.freebsd.org (Postfix) with ESMTP id 3BF3413C4A6 for ; Mon, 5 Nov 2007 01:04:22 +0000 (UTC) (envelope-from r.fulton@auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2285618687; Mon, 5 Nov 2007 12:48:39 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXoO1ZlpkYH0; Mon, 5 Nov 2007 12:48:38 +1300 (NZDT) Received: from bluebottle2.insec.auckland.ac.nz (bluebottle2.insec.auckland.ac.nz [130.216.76.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailhost.auckland.ac.nz (Postfix) with ESMTP id DDB7118647; Mon, 5 Nov 2007 12:48:38 +1300 (NZDT) Message-ID: <472E5A58.5090707@auckland.ac.nz> Date: Mon, 05 Nov 2007 12:48:40 +1300 From: Russell Fulton User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: john.w.court@nokia.com References: <932971.53959.qm@web88014.mail.re2.yahoo.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, gbell72@rogers.com Subject: Re: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 01:04:23 -0000 john.w.court@nokia.com wrote: > Hmm, I may well be missing something very obvious but rule 01000 seems > to be doing exactly what it says it will. Are you sure you meant "deny" > rather than "allow" on rule 01000 ? Note that it is immediately after the check state rule. What the Gardner intended was to drop established tcp traffic that was not part of a session for which there was already state. In fact this rule is redundant since (assuming I've read the rule set correctly) such traffic will get caught by the final deny rule. What is odd about this problem is that it appears to be a timeout problem and thus probably not related to the firewall at all. To me it seems that the initial SYN packet is getting lost and the retry gets through, hence the delay. I suggested to Gardner that he log all dropped packets so he can see if it really is the firewall which is causing the problem. Russell From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 04:30:48 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93BA816A420 for ; Mon, 5 Nov 2007 04:30:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outO.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id 7A51413C4A6 for ; Mon, 5 Nov 2007 04:30:48 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sun, 04 Nov 2007 20:05:47 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id BE2B31268EF; Sun, 4 Nov 2007 20:05:46 -0800 (PST) Message-ID: <472E96BE.4050504@elischer.org> Date: Sun, 04 Nov 2007 20:06:22 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Gardner Bell References: <932971.53959.qm@web88014.mail.re2.yahoo.com> In-Reply-To: <932971.53959.qm@web88014.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 04:30:48 -0000 Gardner Bell wrote: > I'm hoping some of you can help me out with the problem that I'm having > as I'm not very good when it comes to networking.. > > I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my > LAN's firewall/router. After I initially access certain http sites, > particularly google groups and yahoo web mail I'm noticing subsequent > attempts take > 2mins to resolve the next link that I am interested in > reading. > > This appears to be caused by rule 01000 as the counter increases each > time I access one of the above mentioned sites. > > Short of removing this rule, is there any other way that I can fix this > issue? Below is a listing of my present ruleset and a tcpdump of a > Windows XP machine trying to access a link on google groups. > > regards, > > Gardner > > mx1# ipfw show > 00100 76 11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > 00200 0 0 deny log logamount 10 ip from 127.0.0.1 to any > 00300 0 0 deny log logamount 10 ip from any to 127.0.0.1 > 00400 0 0 deny log logamount 10 ip from any to any not > verrevpath in > 00500 0 0 deny log logamount 10 ip from any to any ipoptions > ssrr,lsrr,rr,ts in > 00600 0 0 deny ip from any to any frag > 00700 0 0 allow icmp from any to any icmptypes 0,3,11,12 > 00800 1081 452405 divert 8668 ip from any to any via bge0 > 00900 0 0 check-state > 01000 36 17682 deny tcp from any to any established > 01100 2704 853904 allow ip from any to any via bge1 keep-state > 01200 262 57586 allow tcp from any to any dst-port 80 keep-state > 01300 0 0 allow tcp from any to any dst-port 443 keep-state > 01400 102 7752 allow udp from me to any dst-port 123 keep-state > 01500 0 0 allow tcp from me to any dst-port 53 setup keep-state > 01600 169 30563 allow udp from me to any dst-port 53 keep-state > 01700 0 0 allow tcp from any to any dst-port 1863 setup > keep-state > 01800 0 0 allow log logamount 10 udp from any to > 255.255.255.255 dst-port 68 in via bge0 > 01900 0 0 allow tcp from x.x.x.x to x.x.x.x dst-port 22 > keep-state > 02000 0 0 deny log logamount 10 ip After many years fo doing ipfw rules at work I've cone to the conclusion that one needs to be more explicit about what is going on that most ipfw rulesets are: for example: Assuming bge0 is on the outside, and bge1 is on the inside... #split to incoming and outgoing (from this system) packets. ipfw add 1 skipto 1000 ip from any to any in ############ Output interface sorting ############# # now do output processing. Split up according to interface: ipfw add 100 allow ip from any to any via lo0 ipfw add 110 skipto 3400 ip from any to any out xmit bge0 ipfw add 120 skipto 2400 ip from any to any out xmit bge1 # what is left? should never happen. ipfw add 130 drop log ip from any to any ########### Input interface sorting ###########\ # split up according to source interface. # do checking for lo0 an dloopback addr. ipfw add 1000 accept ip from any to any via lo0 ipfw add 1010 drop log ip from any to 127.0.0.1/8 ipfw add 1020 skipto 2300 ip from any to any recv bge0 ipfw add 1030 skipto 3300 ip from any to any recv bge1 # should never happen so log it: ipfw add 1040 drop log ip from any to any ##################################################### ####### Per interface - per-direction filters ####### ##################################################### ######################################## #### Inside Interface input filters #### # trust the inside. ipfw add 2300 accept ip from any to any #### Inside interface output filters ### # things to do for packets leaving towards the inside. ipfw add 2400 allow ip from any to any ################################# #### Outside interface input #### # process packets coming in from the Internet. # do special processing for packets not of interest to NATD. ipfw add 3300 skipto 1260 ip from any to not me # If they are aimed at our inside address, pass them to NATD. # it should pass on packets that are just to us if set up right. ipfw add 3310 divert 8668 ip from any to me # packets diverted and reinjected come here ipfw add 3320 accept ip from any to any # for now no special processing.. ipfw add 3360 drop log ip from any to any #### Outside Interface output#### # things we need to do for packets leaving via bge0 to the Internet. # Nat packets that are suitable. Don't wast time NATing other packets. ipfw add 3400 divert 8668 ip from not me to any recv bge1 #nat'd packets will turn up here when re-injected. ipfw add 3410 allow ip from any to any. now you can put in rules that are specific to exactly certain traffic and know what the h*ck is going on. > From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 11:06:59 2007 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A20B116A4FD for ; Mon, 5 Nov 2007 11:06:59 +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 92A2F13C494 for ; Mon, 5 Nov 2007 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id lA5B6xFr026334 for ; Mon, 5 Nov 2007 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id lA5B6wwT026328 for freebsd-ipfw@FreeBSD.org; Mon, 5 Nov 2007 11:06:58 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Nov 2007 11:06:58 GMT Message-Id: <200711051106.lA5B6wwT026328@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 11:07:00 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/95084 ipfw [ipfw] [patch] IPFW2 ignores "recv/xmit/via any" (IPFW o kern/97504 ipfw [ipfw] IPFW Rules bug o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/103454 ipfw [ipfw] [patch] add a facility to modify DF bit of the o kern/106534 ipfw [ipfw] [panic] ipfw + dummynet o kern/112708 ipfw ipfw is seems to be broken to limit number of connecti o kern/117234 ipfw [ipfw] [patch] ipfw send_pkt() and ipfw_tick() don't s 14 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau o kern/46159 ipfw [ipfw] [patch] ipfw dynamic rules lifetime feature o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o bin/50749 ipfw [ipfw] [patch] ipfw2 incorrectly parses ports and port o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/73276 ipfw [ipfw] [patch] ipfw2 vulnerability (parser error) o bin/78785 ipfw [ipfw] [patch] ipfw verbosity locks machine if /etc/rc o kern/80642 ipfw [ipfw] [patch] ipfw small patch - new RULE OPTION o kern/82724 ipfw [ipfw] [patch] Add setnexthop and defaultroute feature o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/103328 ipfw [ipfw] sugestions about ipfw table o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o kern/107305 ipfw [ipfw] ipfw fwd doesn't seem to work o kern/111713 ipfw [dummynet] Too few dummynet queue slots o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets p kern/113388 ipfw [ipfw][patch] Addition actions with rules within speci o bin/113803 ipfw [patch] bin/ipfw.8 - don't get bitten by the fwd rule o bin/115172 ipfw [patch] ipfw(8) list show some rules with a wrong form p kern/115755 ipfw [ipfw][patch] unify message and add a rule number wher o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from 28 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 16:01:08 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8927B16A46D for ; Mon, 5 Nov 2007 16:01:08 +0000 (UTC) (envelope-from gbell72@rogers.com) Received: from web88002.mail.re2.yahoo.com (web88002.mail.re2.yahoo.com [206.190.37.189]) by mx1.freebsd.org (Postfix) with SMTP id 2315413C48E for ; Mon, 5 Nov 2007 16:01:07 +0000 (UTC) (envelope-from gbell72@rogers.com) Received: (qmail 58681 invoked by uid 60001); 5 Nov 2007 16:01:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=mwo2huXh3rbwQySBvqYRhraHsg2nhgavRrOFVcKFtHlJXiBUhuf8l3sRPOMW6DCQVC0H19iU3weftlNC85xxtccwc4pyxGv51KKHayf8oaweFI/BSkdV0l9/OUCg+2vTXoN223pCkGndXiuNuyQoPFsQzieShjssEL5yhRChABE=; X-YMail-OSG: rLsQxDYVM1nrAiGQV6Ia3OywHoauUJGreEiWux9_LqRwn9aTRUtWghO5c0zScUBhwTYT_LygiuGpsDn_1bDexkkKmiSULBNGtw92enRO170SHeE41O7s3XNhB4HpyIR6PPM4T.TagZDmKv4- Received: from [99.233.189.147] by web88002.mail.re2.yahoo.com via HTTP; Mon, 05 Nov 2007 11:01:00 EST Date: Mon, 5 Nov 2007 11:01:00 -0500 (EST) From: Gardner Bell To: Russell Fulton , john.w.court@nokia.com In-Reply-To: <472E5A58.5090707@auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <658878.58430.qm@web88002.mail.re2.yahoo.com> Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 16:01:08 -0000 --- Russell Fulton wrote: > > > john.w.court@nokia.com wrote: > > Hmm, I may well be missing something very obvious but rule 01000 > seems > > to be doing exactly what it says it will. Are you sure you meant > "deny" > > rather than "allow" on rule 01000 ? > > Note that it is immediately after the check state rule. What the > Gardner intended was to drop established tcp traffic that was not > part > of a session for which there was already state. In fact this rule is > redundant since (assuming I've read the rule set correctly) such > traffic > will get caught by the final deny rule. > > What is odd about this problem is that it appears to be a timeout > problem and thus probably not related to the firewall at all. To me > it > seems that the initial SYN packet is getting lost and the retry gets > through, hence the delay. > > I suggested to Gardner that he log all dropped packets so he can see > if > it really is the firewall which is causing the problem. > > Russell > Removing rule 01000 seems to have fixed the timeout issues. Thank you. Gardner From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 16:06:19 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1D0716A420 for ; Mon, 5 Nov 2007 16:06:18 +0000 (UTC) (envelope-from gbell72@rogers.com) Received: from web88015.mail.re2.yahoo.com (web88015.mail.re2.yahoo.com [206.190.39.220]) by mx1.freebsd.org (Postfix) with SMTP id 9D2F113C4A6 for ; Mon, 5 Nov 2007 16:06:18 +0000 (UTC) (envelope-from gbell72@rogers.com) Received: (qmail 53802 invoked by uid 60001); 5 Nov 2007 16:05:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=X-YMail-OSG:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=hB4WHDr7A77eyWurwrhGEV/E9yrvkJ5wUPqDW8uF7PjeXDijCfIBqN47yxkLJm126mKS+rGmqu7J+vPNzJ7hF+7UvUZo6pZwhpsOspnpZklQw7VJkWuAQM9Jv7qpYaWrAhyVrOkOgLIZ6G29JMIR80BOKrxHsHovJx7q7eIb+Lg=; X-YMail-OSG: ufboG2AVM1ly_POcr4pXu2PmrkFr2rTTX9Tf7Nsv Received: from [99.233.189.147] by web88015.mail.re2.yahoo.com via HTTP; Mon, 05 Nov 2007 11:05:34 EST Date: Mon, 5 Nov 2007 11:05:34 -0500 (EST) From: Gardner Bell To: Julian Elischer In-Reply-To: <472E96BE.4050504@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <324579.51265.qm@web88015.mail.re2.yahoo.com> Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 16:06:19 -0000 --- Julian Elischer wrote: > Gardner Bell wrote: > > I'm hoping some of you can help me out with the problem that I'm > having > > as I'm not very good when it comes to networking.. > > > > I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my > > LAN's firewall/router. After I initially access certain http > sites, > > particularly google groups and yahoo web mail I'm noticing > subsequent > > attempts take > 2mins to resolve the next link that I am interested > in > > reading. > > > > This appears to be caused by rule 01000 as the counter increases > each > > time I access one of the above mentioned sites. > > > > Short of removing this rule, is there any other way that I can fix > this > > issue? Below is a listing of my present ruleset and a tcpdump of a > > Windows XP machine trying to access a link on google groups. > > > > regards, > > > > Gardner > > > > mx1# ipfw show > > 00100 76 11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 > > 00200 0 0 deny log logamount 10 ip from 127.0.0.1 to any > > 00300 0 0 deny log logamount 10 ip from any to 127.0.0.1 > > 00400 0 0 deny log logamount 10 ip from any to any not > > verrevpath in > > 00500 0 0 deny log logamount 10 ip from any to any > ipoptions > > ssrr,lsrr,rr,ts in > > 00600 0 0 deny ip from any to any frag > > 00700 0 0 allow icmp from any to any icmptypes 0,3,11,12 > > 00800 1081 452405 divert 8668 ip from any to any via bge0 > > 00900 0 0 check-state > > 01000 36 17682 deny tcp from any to any established > > 01100 2704 853904 allow ip from any to any via bge1 keep-state > > 01200 262 57586 allow tcp from any to any dst-port 80 keep-state > > 01300 0 0 allow tcp from any to any dst-port 443 keep-state > > 01400 102 7752 allow udp from me to any dst-port 123 keep-state > > 01500 0 0 allow tcp from me to any dst-port 53 setup > keep-state > > 01600 169 30563 allow udp from me to any dst-port 53 keep-state > > 01700 0 0 allow tcp from any to any dst-port 1863 setup > > keep-state > > 01800 0 0 allow log logamount 10 udp from any to > > 255.255.255.255 dst-port 68 in via bge0 > > 01900 0 0 allow tcp from x.x.x.x to x.x.x.x dst-port 22 > > keep-state > > 02000 0 0 deny log logamount 10 ip > > After many years fo doing ipfw rules at work I've cone to the > conclusion that > one needs to be more explicit about what is going on that most ipfw > rulesets are: > > > for example: > Assuming bge0 is on the outside, and bge1 is on the inside... > > #split to incoming and outgoing (from this system) packets. > ipfw add 1 skipto 1000 ip from any to any in > > ############ Output interface sorting ############# > # now do output processing. Split up according to interface: > ipfw add 100 allow ip from any to any via lo0 > ipfw add 110 skipto 3400 ip from any to any out xmit bge0 > ipfw add 120 skipto 2400 ip from any to any out xmit bge1 > # what is left? should never happen. > ipfw add 130 drop log ip from any to any > > ########### Input interface sorting ###########\ > # split up according to source interface. > # do checking for lo0 an dloopback addr. > ipfw add 1000 accept ip from any to any via lo0 > ipfw add 1010 drop log ip from any to 127.0.0.1/8 > > ipfw add 1020 skipto 2300 ip from any to any recv bge0 > ipfw add 1030 skipto 3300 ip from any to any recv bge1 > > # should never happen so log it: > ipfw add 1040 drop log ip from any to any > > ##################################################### > ####### Per interface - per-direction filters ####### > ##################################################### > > ######################################## > #### Inside Interface input filters #### > # trust the inside. > ipfw add 2300 accept ip from any to any > > > #### Inside interface output filters ### > # things to do for packets leaving towards the inside. > ipfw add 2400 allow ip from any to any > > > ################################# > #### Outside interface input #### > # process packets coming in from the Internet. > # do special processing for packets not of interest to NATD. > ipfw add 3300 skipto 1260 ip from any to not me > # If they are aimed at our inside address, pass them to NATD. > # it should pass on packets that are just to us if set up right. > ipfw add 3310 divert 8668 ip from any to me > # packets diverted and reinjected come here > ipfw add 3320 accept ip from any to any > > # for now no special processing.. > ipfw add 3360 drop log ip from any to any > > #### Outside Interface output#### > # things we need to do for packets leaving via bge0 to the Internet. > # Nat packets that are suitable. Don't wast time NATing other > packets. > ipfw add 3400 divert 8668 ip from not me to any recv bge1 > #nat'd packets will turn up here when re-injected. > ipfw add 3410 allow ip from any to any. > > > > now you can put in rules that are specific to exactly certain traffic > and know what the h*ck is going on. > I believe with IPFW not having one set structure to go by has indeed confused me as a beginner. This template will definitely help out with any further rules I need to add to my configuration. Thank you. Gardner From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 5 17:22:32 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2410C16A41B for ; Mon, 5 Nov 2007 17:22:32 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (outE.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id EF22213C480 for ; Mon, 5 Nov 2007 17:22:31 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Mon, 05 Nov 2007 09:22:22 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 983661268FA; Mon, 5 Nov 2007 09:22:21 -0800 (PST) Message-ID: <472F5171.2060709@elischer.org> Date: Mon, 05 Nov 2007 09:22:57 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Gardner Bell References: <324579.51265.qm@web88015.mail.re2.yahoo.com> In-Reply-To: <324579.51265.qm@web88015.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: IPFW Problem X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2007 17:22:32 -0000 Gardner Bell wrote: > --- Julian Elischer wrote: > >> Gardner Bell wrote: >>> I'm hoping some of you can help me out with the problem that I'm >> having >>> as I'm not very good when it comes to networking.. >>> >>> I've recently configured 6.3-PRERELEASE with IPFW/NATD to act as my >>> LAN's firewall/router. After I initially access certain http >> sites, >>> particularly google groups and yahoo web mail I'm noticing >> subsequent >>> attempts take > 2mins to resolve the next link that I am interested >> in >>> reading. >>> >>> This appears to be caused by rule 01000 as the counter increases >> each >>> time I access one of the above mentioned sites. >>> >>> Short of removing this rule, is there any other way that I can fix >> this >>> issue? Below is a listing of my present ruleset and a tcpdump of a >>> Windows XP machine trying to access a link on google groups. >>> >>> regards, >>> >>> Gardner >>> >>> mx1# ipfw show >>> 00100 76 11134 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 >>> 00200 0 0 deny log logamount 10 ip from 127.0.0.1 to any >>> 00300 0 0 deny log logamount 10 ip from any to 127.0.0.1 >>> 00400 0 0 deny log logamount 10 ip from any to any not >>> verrevpath in >>> 00500 0 0 deny log logamount 10 ip from any to any >> ipoptions >>> ssrr,lsrr,rr,ts in >>> 00600 0 0 deny ip from any to any frag >>> 00700 0 0 allow icmp from any to any icmptypes 0,3,11,12 >>> 00800 1081 452405 divert 8668 ip from any to any via bge0 >>> 00900 0 0 check-state >>> 01000 36 17682 deny tcp from any to any established >>> 01100 2704 853904 allow ip from any to any via bge1 keep-state >>> 01200 262 57586 allow tcp from any to any dst-port 80 keep-state >>> 01300 0 0 allow tcp from any to any dst-port 443 keep-state >>> 01400 102 7752 allow udp from me to any dst-port 123 keep-state >>> 01500 0 0 allow tcp from me to any dst-port 53 setup >> keep-state >>> 01600 169 30563 allow udp from me to any dst-port 53 keep-state >>> 01700 0 0 allow tcp from any to any dst-port 1863 setup >>> keep-state >>> 01800 0 0 allow log logamount 10 udp from any to >>> 255.255.255.255 dst-port 68 in via bge0 >>> 01900 0 0 allow tcp from x.x.x.x to x.x.x.x dst-port 22 >>> keep-state >>> 02000 0 0 deny log logamount 10 ip >> After many years fo doing ipfw rules at work I've cone to the >> conclusion that >> one needs to be more explicit about what is going on that most ipfw >> rulesets are: >> >> >> for example: >> Assuming bge0 is on the outside, and bge1 is on the inside... >> >> #split to incoming and outgoing (from this system) packets. >> ipfw add 1 skipto 1000 ip from any to any in >> >> ############ Output interface sorting ############# >> # now do output processing. Split up according to interface: >> ipfw add 100 allow ip from any to any via lo0 >> ipfw add 110 skipto 3400 ip from any to any out xmit bge0 >> ipfw add 120 skipto 2400 ip from any to any out xmit bge1 >> # what is left? should never happen. >> ipfw add 130 drop log ip from any to any >> >> ########### Input interface sorting ###########\ >> # split up according to source interface. >> # do checking for lo0 an dloopback addr. >> ipfw add 1000 accept ip from any to any via lo0 >> ipfw add 1010 drop log ip from any to 127.0.0.1/8 >> >> ipfw add 1020 skipto 2300 ip from any to any recv bge0 >> ipfw add 1030 skipto 3300 ip from any to any recv bge1 >> >> # should never happen so log it: >> ipfw add 1040 drop log ip from any to any >> >> ##################################################### >> ####### Per interface - per-direction filters ####### >> ##################################################### >> >> ######################################## >> #### Inside Interface input filters #### >> # trust the inside. >> ipfw add 2300 accept ip from any to any >> >> >> #### Inside interface output filters ### >> # things to do for packets leaving towards the inside. >> ipfw add 2400 allow ip from any to any >> >> >> ################################# >> #### Outside interface input #### >> # process packets coming in from the Internet. >> # do special processing for packets not of interest to NATD. >> ipfw add 3300 skipto 1260 ip from any to not me ^^^^^^^^ should be 3360 >> # If they are aimed at our inside address, pass them to NATD. >> # it should pass on packets that are just to us if set up right. >> ipfw add 3310 divert 8668 ip from any to me >> # packets diverted and reinjected come here >> ipfw add 3320 accept ip from any to any >> >> # for now no special processing.. >> ipfw add 3360 drop log ip from any to any >> >> #### Outside Interface output#### >> # things we need to do for packets leaving via bge0 to the Internet. >> # Nat packets that are suitable. Don't wast time NATing other >> packets. >> ipfw add 3400 divert 8668 ip from not me to any recv bge1 >> #nat'd packets will turn up here when re-injected. >> ipfw add 3410 allow ip from any to any. >> >> >> >> now you can put in rules that are specific to exactly certain traffic >> and know what the h*ck is going on. >> > > I believe with IPFW not having one set structure to go by has indeed > confused me as a beginner. This template will definitely help out with > any further rules I need to add to my configuration. Thank you. > > Gardner > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu Nov 8 08:03:58 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5616416A418 for ; Thu, 8 Nov 2007 08:03:58 +0000 (UTC) (envelope-from igorpopov@newmail.ru) Received: from mx1.mail.wbt.ru (mx1.mail.wbt.ru [80.250.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id EBDDC13C4A3 for ; Thu, 8 Nov 2007 08:03:57 +0000 (UTC) (envelope-from igorpopov@newmail.ru) Received: from moon.wbt.ru ([80.250.66.38] helo=moon) by mx1.mail.wbt.ru (Exim) with esmtp sent from for id 1Iq1kQ-0002Hz-2B; Thu, 08 Nov 2007 09:24:18 +0200 From: Igor Popov Organization: Home Date: Thu, 8 Nov 2007 09:24:18 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: Multipart/Mixed; boundary="Boundary-00=_kmrMHEWMtp5qEky" Message-Id: <200711080924.20804.igorpopov@newmail.ru> X-ACL-Warn: X-AV 1 1194506658 X-ACL-Warn: X-AV 2 1194506658 X-ACL-Warn: X-AV 3 1194506658 X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-SpamTest-Info: Not protected Subject: FreeBSD 7.0beta2 and spamd-setup X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2007 08:03:58 -0000 --Boundary-00=_kmrMHEWMtp5qEky Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, all. I run FreeBSD 7.0beta2 on HP DL 360 and spamd in blacklisted mode, freebsd is compiled for amd64 and spamd is built from ports. When spamd-setup -b is executed periodically by cron, I always recieve mail message: /usr/local/sbin/spamd-setup -b pfctl: Cannot allocate memory. And table is empty. -- The difference between the right word and the almost right word is the difference between lightning and the lightning bug. -- Mark Twain --Boundary-00=_kmrMHEWMtp5qEky Content-Type: text/plain; name="Cron /usr/local/sbin/spamd-setup -b" Content-Transfer-Encoding: 7bit pfctl: Cannot allocate memory. --Boundary-00=_kmrMHEWMtp5qEky-- From owner-freebsd-ipfw@FreeBSD.ORG Thu Nov 8 19:15:07 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9723E16A418 for ; Thu, 8 Nov 2007 19:15:07 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id DDA1613C49D for ; Thu, 8 Nov 2007 19:15:06 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: (qmail invoked by alias); 08 Nov 2007 18:48:12 -0000 Received: from u18-124.dsl.vianetworks.de (EHLO [172.20.1.30]) [194.231.39.124] by mail.gmx.net (mp048) with SMTP; 08 Nov 2007 19:48:12 +0100 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX1+YbL1suwuYnHQOnrHdE4f3TDUW+X7MEMQkicg1c9 eVE1ptrkbXJZSM Message-ID: <473359E8.1060704@gmx.de> Date: Thu, 08 Nov 2007 19:48:08 +0100 From: Olli Hauer User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Igor Popov References: <200711080924.20804.igorpopov@newmail.ru> In-Reply-To: <200711080924.20804.igorpopov@newmail.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-ipfw@freebsd.org Subject: Re: FreeBSD 7.0beta2 and spamd-setup X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2007 19:15:07 -0000 Igor Popov wrote: > Hi, all. > I run FreeBSD 7.0beta2 on HP DL 360 and spamd in blacklisted mode, freebsd is > compiled for amd64 and spamd is built from ports. When spamd-setup -b is > executed periodically by cron, I always recieve mail message: > > /usr/local/sbin/spamd-setup -b > > pfctl: Cannot allocate memory. > > And table is empty. > It seems you run spamd with ipfw so the correct parameters are /usr/local/sbin/spamd-setup -m ipfw and if the spamd table is not the defaut table 2 then /usr/local/sbin/spamd-setup -m ipfw -t see man spamd(8) / spamd-setup(8) olli From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 9 04:22:36 2007 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3166016A419 for ; Fri, 9 Nov 2007 04:22:36 +0000 (UTC) (envelope-from wwwrun@server101.rhs-it.de) Received: from server101.rhs-it.de (server101.rhs-it.de [195.78.76.101]) by mx1.freebsd.org (Postfix) with ESMTP id E9DD913C4AA for ; Fri, 9 Nov 2007 04:22:35 +0000 (UTC) (envelope-from wwwrun@server101.rhs-it.de) Received: from localhost (localhost [127.0.0.1]) by server101.rhs-it.de (Postfix) with ESMTP id 959203F661C for ; Fri, 9 Nov 2007 03:55:51 +0100 (CET) Received: from server101.rhs-it.de ([127.0.0.1]) by localhost (server101 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00657-03 for ; Fri, 9 Nov 2007 03:55:51 +0100 (CET) Received: by server101.rhs-it.de (Postfix, from userid 30) id 438253F5F81; Fri, 9 Nov 2007 03:54:03 +0100 (CET) To: ipfw@freebsd.org From: ipfw@freebsd.org Message-Id: <20071109025403.438253F5F81@server101.rhs-it.de> Date: Fri, 9 Nov 2007 03:54:03 +0100 (CET) X-Virus-Scanned: by amavisd-new at rhs-it.de Cc: Subject: We have gathered a lot of information X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 04:22:36 -0000 RCWars.NET - http://www.rcwars.net Technologies around RC Models and thus RC Warbirds have greatly evolved in the past years. While we still share the excitement of constructing, flying and tuning RC Warbirds, we have also looked beyond this and found something very, very exciting! A new product called RC:Gun has revolutionalized our hobby. It allows us to actually engage in real Air2Air combat By shooting our opponents down. But no worry - the wonderful Warbirds take no real harm. The trick is an ultrasound technology that allows combat without any physical interaction. More in http://www.rcwars.net From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 9 04:38:19 2007 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8EDD16A421 for ; Fri, 9 Nov 2007 04:38:19 +0000 (UTC) (envelope-from wwwrun@server101.rhs-it.de) Received: from server101.rhs-it.de (server101.rhs-it.de [195.78.76.101]) by mx1.freebsd.org (Postfix) with ESMTP id 6F97C13C480 for ; Fri, 9 Nov 2007 04:38:19 +0000 (UTC) (envelope-from wwwrun@server101.rhs-it.de) Received: from localhost (localhost [127.0.0.1]) by server101.rhs-it.de (Postfix) with ESMTP id 3EAC73F48E6 for ; Fri, 9 Nov 2007 05:38:13 +0100 (CET) Received: from server101.rhs-it.de ([127.0.0.1]) by localhost (server101 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04517-07 for ; Fri, 9 Nov 2007 05:38:13 +0100 (CET) Received: by server101.rhs-it.de (Postfix, from userid 30) id 8C1FE3F5BE3; Fri, 9 Nov 2007 05:38:04 +0100 (CET) To: ipfw@freebsd.org From: ipfw@freebsd.org Message-Id: <20071109043804.8C1FE3F5BE3@server101.rhs-it.de> Date: Fri, 9 Nov 2007 05:38:04 +0100 (CET) X-Virus-Scanned: by amavisd-new at rhs-it.de Cc: Subject: We have gathered a lot of information X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 04:38:19 -0000 RCWars.NET - http://www.rcwars.net Technologies around RC Models and thus RC Warbirds have greatly evolved in the past years. While we still share the excitement of constructing, flying and tuning RC Warbirds, we have also looked beyond this and found something very, very exciting! A new product called RC:Gun has revolutionalized our hobby. It allows us to actually engage in real Air2Air combat By shooting our opponents down. But no worry - the wonderful Warbirds take no real harm. The trick is an ultrasound technology that allows combat without any physical interaction. More in http://www.rcwars.net From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 9 07:22:08 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2500516A419 for ; Fri, 9 Nov 2007 07:22:08 +0000 (UTC) (envelope-from igorpopov@newmail.ru) Received: from mx1.mail.wbt.ru (mx1.mail.wbt.ru [80.250.64.6]) by mx1.freebsd.org (Postfix) with ESMTP id C47D813C4AC for ; Fri, 9 Nov 2007 07:22:07 +0000 (UTC) (envelope-from igorpopov@newmail.ru) Received: from moon.wbt.ru ([80.250.66.38] helo=moon) by mx1.mail.wbt.ru (Exim) with esmtp sent from id 1IqOBi-0006Nx-99; Fri, 09 Nov 2007 09:21:58 +0200 From: Igor Popov Organization: Home To: Olli Hauer Date: Fri, 9 Nov 2007 09:22:03 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <200711080924.20804.igorpopov@newmail.ru> <473359E8.1060704@gmx.de> In-Reply-To: <473359E8.1060704@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711090922.06790.igorpopov@newmail.ru> X-ACL-Warn: X-AV 1 1194592918 X-ACL-Warn: X-AV 2 1194592918 X-ACL-Warn: X-AV 3 1194592918 X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-SpamTest-Info: Not protected Cc: freebsd-ipfw@freebsd.org Subject: Re: FreeBSD 7.0beta2 and spamd-setup X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 07:22:08 -0000 Hi, all. > > I run FreeBSD 7.0beta2 on HP DL 360 and spamd in blacklisted mode, > > freebsd is compiled for amd64 and spamd is built from ports. When > > spamd-setup -b is executed periodically by cron, I always recieve mail > > message: > > > > /usr/local/sbin/spamd-setup -b > > > > pfctl: Cannot allocate memory. > > > > And table is empty. > > It seems you run spamd with ipfw so the correct parameters are > > /usr/local/sbin/spamd-setup -m ipfw > > and if the spamd table is not the defaut table 2 then > > /usr/local/sbin/spamd-setup -m ipfw -t > > see man spamd(8) / spamd-setup(8) > > olli Really I use pf. -- Your object is to save the world, while still leading a pleasant life. From owner-freebsd-ipfw@FreeBSD.ORG Fri Nov 9 09:04:16 2007 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D5BD16A41B for ; Fri, 9 Nov 2007 09:04:16 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id CE3D913C4B3 for ; Fri, 9 Nov 2007 09:04:15 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: (qmail 24467 invoked by uid 0); 9 Nov 2007 09:04:06 -0000 Received: from 213.61.170.34 by www060.gmx.net with HTTP; Fri, 09 Nov 2007 10:04:05 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Fri, 09 Nov 2007 10:04:05 +0100 From: "Olli Hauer" In-Reply-To: <200711090922.06790.igorpopov@newmail.ru> Message-ID: <20071109090405.181170@gmx.net> MIME-Version: 1.0 References: <200711080924.20804.igorpopov@newmail.ru> <473359E8.1060704@gmx.de> <200711090922.06790.igorpopov@newmail.ru> To: Igor Popov X-Authenticated: #1956535 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18rs1w56Dsro1wXjhaFqqoCNJ4d+G8SszfkHtL38L XsPivRYN/Msnif7e8vVaQExJSmlPKFY1pwzw== Content-Transfer-Encoding: 7bit X-GMX-UID: shoCdvd1YmYBcoHteHc3iDxCWkZTQVTr Cc: freebsd-ipfw@freebsd.org, freebsd-ip@freebsd.org Subject: Re: FreeBSD 7.0beta2 and spamd-setup X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2007 09:04:16 -0000 > > > I run FreeBSD 7.0beta2 on HP DL 360 and spamd in blacklisted mode, > > > freebsd is compiled for amd64 and spamd is built from ports. When > > > spamd-setup -b is executed periodically by cron, I always recieve mail > > > message: > > > > > > /usr/local/sbin/spamd-setup -b > > > > > > pfctl: Cannot allocate memory. > > > > > > And table is empty. > > > > It seems you run spamd with ipfw so the correct parameters are > > > > /usr/local/sbin/spamd-setup -m ipfw > > > > and if the spamd table is not the defaut table 2 then > > > > /usr/local/sbin/spamd-setup -m ipfw -t > > > > see man spamd(8) / spamd-setup(8) > > > > olli > > Really I use pf. > Ok, so lets change the mailing list to freebsd-pf. Since I have no amd64 system at the moment aviable can you provide the following output. # pfctl -sn # pfctl -sr # pfctl -si for i in `pfctl -sT`; do echo $i; pfctl -t $i -Ts | wc -l; done Please do a test with the following command: # pfctl -t spamd -T replace -f /path/to/blacklist/file olli -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail