From owner-freebsd-ipfw@FreeBSD.ORG Sun Nov 26 20:44:09 2006 Return-Path: X-Original-To: freebsd-ipfw@hub.freebsd.org Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0B35B16A4FB; Sun, 26 Nov 2006 20:44:09 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC40443E45; Sun, 26 Nov 2006 20:27:06 +0000 (GMT) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (remko@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kAQKRksv099811; Sun, 26 Nov 2006 20:27:46 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kAQKRkuq099807; Sun, 26 Nov 2006 20:27:46 GMT (envelope-from remko) Date: Sun, 26 Nov 2006 20:27:46 GMT From: Remko Lodder Message-Id: <200611262027.kAQKRkuq099807@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-ipfw@FreeBSD.org, remko@FreeBSD.org Cc: Subject: Re: kern/51341: [ipfw] [patch] ipfw rule 'deny icmp from any to any icmptype 5' matches fragmented icmp packets 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, 26 Nov 2006 20:44:09 -0000 Synopsis: [ipfw] [patch] ipfw rule 'deny icmp from any to any icmptype 5' matches fragmented icmp packets Responsible-Changed-From-To: freebsd-ipfw->remko Responsible-Changed-By: remko Responsible-Changed-When: Sun Nov 26 20:27:46 UTC 2006 Responsible-Changed-Why: grab this; had this ever been fixed? http://www.freebsd.org/cgi/query-pr.cgi?pr=51341 From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 27 08:44:55 2006 Return-Path: X-Original-To: ipfw@freebsd.org Delivered-To: freebsd-ipfw@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6CE2516A412 for ; Mon, 27 Nov 2006 08:44:55 +0000 (UTC) (envelope-from ejibyidl@mail.pacifier.com) Received: from mail.pacifier.com (59-115-211-41.dynamic.hinet.net [59.115.211.41]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D50843D5E for ; Mon, 27 Nov 2006 08:43:55 +0000 (GMT) (envelope-from ejibyidl@mail.pacifier.com) Message-ID: <01001c70037$3cfb26f0$5409a8e0@bheraclitusf> From: " s" To: Date: Mon, 27 Nov 2006 16:44:53 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Stocks in Play h X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: s List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2006 08:44:55 -0000 OF INTEREST PAY ATTENTION VITAL This advisory is based on exclusive insiders/agents information. (AVLN.OB) Avalon Energy Corporation has an undivided 85% working interest in the Shotgun Draw Prospect in the prolific natural gas producing Uinta Basin , located in the US Rockies, Utah . The lease comprises 13,189 acres with a potential 4 TCF recoverable gas and is overpressured by a 0.55 . 0.85 gradient. ON MONDAY NOV 6th: at 11 cents its a STEAL - Volume: 389,001 - Volume: + 50% - Price: +5.77% The key to any tade is buying low and selling high, WELL the energy market has bottomed out and time to get in is now. We specialise in calling market bottom and when it comes to energy THIS IS THE BOTTOM, SO GET IN FOLKS WIN WIN WIN WITH THIS COMPANY WIN WIN WIN WITH THIS COMPANY Mourners honored the firefighters killed by the California arson fire as the first of five funerals began Friday, and praised authorities for charging the man accused of starting that fire with murder. "Nine days ago, one of the worst tragedies in the 100-year history of the Forest Service took the lives of five heroes," U.S. Forest Service Chaplain Steve Seltzner said as the service began. "It has shaken this agency and the men and women of the San Benardino National Forest to its very core and shocked the entire world." Three firefighters died when the flames swept over their truck, and a fourth died soon after at a hospital. A fifth was taken off life support and died this week. The last time so many firefighters were killed battling a wildfire was July 1994, when 14 were killed near Glenwood Springs, Colorado, according to the National Interagency Fire Center. Funeral services were also scheduled over the next several days for firefighters Jess McLean, 27, of Beaumont; Daniel Hoover-Najera, 20, of San Jacinto; Mark Loutzenhiser, 43, of Idyllwild; and Pablo Cerda, 23, of Fountain Valley. A public memorial service for all five men was planned for Sunday. From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 27 11:09:19 2006 Return-Path: X-Original-To: freebsd-ipfw@FreeBSD.org Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32F2316A513 for ; Mon, 27 Nov 2006 11:09:19 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04B1843D9C for ; Mon, 27 Nov 2006 11:07:29 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kARB8SHI091985 for ; Mon, 27 Nov 2006 11:08:28 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kARB8Rpm091981 for freebsd-ipfw@FreeBSD.org; Mon, 27 Nov 2006 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 27 Nov 2006 11:08:27 GMT Message-Id: <200611271108.kARB8Rpm091981@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 27 Nov 2006 11:09:19 -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 conf/78762 ipfw [ipfw] [patch] /etc/rc.d/ipfw should excecute $firewal o bin/80913 ipfw [patch] /sbin/ipfw2 silently discards MAC addr arg wit o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/93300 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 13 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 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 20 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 27 16:52:43 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0ADA16A73C for ; Mon, 27 Nov 2006 16:52:43 +0000 (UTC) (envelope-from fra@abcochesco.com) Received: from abcochesco.com (d01m-213-44-214-53.d4.club-internet.fr [213.44.214.53]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D1DC43D78 for ; Mon, 27 Nov 2006 16:49:34 +0000 (GMT) (envelope-from fra@abcochesco.com) Message-ID: <000001c71243$bfa4dcf0$c951a8c0@qbkhct> From: "Isbel Washer" To: freebsd-ipfw@freebsd.org Date: Mon, 27 Nov 2006 08:47:39 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: nystagmu X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Isbel Washer List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2006 16:52:44 -0000 Hi, =20 VjAGRA_yl_$1,78 CjALiS_qt_$3,00 LEVjTRA_sp_$3,33 =20 www [dot] rx44 [dot] info _____ =20 now. From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 27 20:35:45 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A69EF16A509 for ; Mon, 27 Nov 2006 20:35:45 +0000 (UTC) (envelope-from donald.teed@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id E74D444887 for ; Mon, 27 Nov 2006 20:02:19 +0000 (GMT) (envelope-from donald.teed@gmail.com) Received: by nz-out-0102.google.com with SMTP id i11so712546nzh for ; Mon, 27 Nov 2006 12:03:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=URSRhfgpeUsSyIDJWGP99BsRdNR797zj019Vqbw3B66MnpjdB/69sBoCrUX0XszUEIJ/D2DhBnJBq6jWohJmTQBtuwstdAQQq+KrSFshNdPSeQEz1GAc3Zfa+jHYU4rQHSsZ0eZpk3jzXGVCA32Qih7ZhteCqZb7ESXEakuznRA= Received: by 10.78.138.6 with SMTP id l6mr13584544hud.1164657401064; Mon, 27 Nov 2006 11:56:41 -0800 (PST) Received: by 10.78.159.6 with HTTP; Mon, 27 Nov 2006 11:56:41 -0800 (PST) Message-ID: Date: Mon, 27 Nov 2006 15:56:41 -0400 From: "D G Teed" To: freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: how to go about diagnosing cause of packet loss 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, 27 Nov 2006 20:35:45 -0000 Howdy, Lately we have been seeing increased packet loss on our firewall. Running a ping plotter outside of the firewall shows the hops are running clean. >From on or behind the firewall, we have 20 to 50% packet loss to each hop, reaching several popular test destinations. e.g.: $ mtr -c 100 -r www.cnn.com HOST: Loss% Snt Last Avg Best Wrst StDev 1. vlan-136.acadiau.ca 0.0% 100 0.4 6.1 0.4 179.9 26.5 2. silverhorde.acadiau.ca 4.0% 100 0.6 0.9 0.3 7.8 1.0 3. wfvlnsauh05-fe-0-0.aliant.ne 17.0% 100 3.4 6.3 2.6 55.0 8.8 4. hlfxns01h29-ge-4-0.aliant.ne 27.0% 100 3.6 3.8 2.5 12.4 1.4 5. rtp629049rts 15.0% 100 4.2 4.0 2.6 9.1 1.2 6. core1-halifax_POS5-0.net.bel 22.0% 100 6.2 3.7 2.6 6.2 0.9 7. core3-montrealak_pos1-1.net. 4.0% 100 24.2 26.8 20.3 126.2 19.2 8. core1-newyork83_pos_5_0_0.ne 19.0% 100 26.1 26.9 26.0 34.1 1.2 9. bx4-newyork83_pos_2_0_0.net. 31.0% 100 27.7 28.1 27.1 30.1 0.8 10. pop1-nye-P8-1.atdn.net 9.0% 100 26.2 45.2 26.2 227.4 48.0 11. bb2-nye-P0-0.atdn.net 16.0% 100 29.0 31.1 26.3 178.2 19.4 12. bb2-vie-P12-0.atdn.net 14.0% 100 33.0 46.3 32.3 206.4 37.6 13. bb2-atm-P3-0.atdn.net 18.0% 100 42.9 44.9 42.5 106.6 9.7 14. ??? 100.0 100 0.0 0.0 0.0 0.0 0.0 We suspect something in FreeBSD or ipfw has a flaw, but cannot find it. Running mtr from the firewall itself produces slightly different packet loss points than one hop behind the firewall running mtr. A reboot initially cleared up the problem, but 10 minutes later we saw the packet loss again, so I wonder if we are seeing some sort of saturation. Does anyone have suggestions no how to troubleshoot/resolve this problem? --Donald From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 27 21:23:41 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44C6716A5F2 for ; Mon, 27 Nov 2006 21:23:41 +0000 (UTC) (envelope-from asstec@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9696B443D7 for ; Mon, 27 Nov 2006 21:05:18 +0000 (GMT) (envelope-from asstec@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id kARL6I67090671 for ; Mon, 27 Nov 2006 18:06:19 -0300 (BRT) (envelope-from asstec@matik.com.br) From: AT Matik Organization: Infomatik To: freebsd-ipfw@freebsd.org Date: Mon, 27 Nov 2006 18:06:50 -0300 User-Agent: KMail/1.9.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200611271806.50641.asstec@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Subject: Re: how to go about diagnosing cause of packet loss 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, 27 Nov 2006 21:23:41 -0000 On Monday 27 November 2006 16:56, D G Teed wrote: > We suspect something in FreeBSD or ipfw has a flaw, > but cannot find it. how are the results when your server has its FW open? Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-ipfw@FreeBSD.ORG Mon Nov 27 23:55:20 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 294A616A415 for ; Mon, 27 Nov 2006 23:55:20 +0000 (UTC) (envelope-from donald.teed@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68FF244231 for ; Mon, 27 Nov 2006 22:47:37 +0000 (GMT) (envelope-from donald.teed@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so298048wra for ; Mon, 27 Nov 2006 14:48:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=ZhpBUDkXghR+10Xq7h8RmTeP1qBSzFa2ys62IuZXqFvTFqYEbMdJf34xPibsc98f+4fyVcA6YdUPfjthOudx4J3Jb7Iw4qOsfZ5dgRVg2PEG3ScXrKuLzlEE58GtrM5YhrEkTSEtCnUCWXuVUJ76BmCTPSvqFdYniAtgHgaloN4= Received: by 10.78.166.7 with SMTP id o7mr180451hue.1164667712143; Mon, 27 Nov 2006 14:48:32 -0800 (PST) Received: by 10.78.159.6 with HTTP; Mon, 27 Nov 2006 14:48:32 -0800 (PST) Message-ID: Date: Mon, 27 Nov 2006 18:48:32 -0400 From: "D G Teed" To: "AT Matik" In-Reply-To: <200611271806.50641.asstec@matik.com.br> MIME-Version: 1.0 References: <200611271806.50641.asstec@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org Subject: Re: how to go about diagnosing cause of packet loss 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, 27 Nov 2006 23:55:20 -0000 Sorry, I think I see what we need now: ipfw disable firewall I'm just more familiar with Linux... On 11/27/06, AT Matik wrote: > > On Monday 27 November 2006 16:56, D G Teed wrote: > > We suspect something in FreeBSD or ipfw has a flaw, > > but cannot find it. > > how are the results when your server has its FW open? > > Jo=E3o > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > 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 Tue Nov 28 16:57:23 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB5DB16A4B3 for ; Tue, 28 Nov 2006 16:57:23 +0000 (UTC) (envelope-from donald.teed@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF33E43CE9 for ; Tue, 28 Nov 2006 16:56:59 +0000 (GMT) (envelope-from donald.teed@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so454186wra for ; Tue, 28 Nov 2006 08:56:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=oUN19SsoDfWKBOLXNC+BG23hw/RAvkxSBPMxnWSOVWDAa4EDPE8ENK8lYlqOacnbqTddeaXkXNx2hNZdy3o0pAXe5BUZjB1/JCHp/T4yi2dd4LMPYxYZmfqD41yuVASC6U70DizhVy+nWERbqofEQhUxggqEqdLB2Ater8Vq/O8= Received: by 10.78.134.12 with SMTP id h12mr1140403hud.1164733015330; Tue, 28 Nov 2006 08:56:55 -0800 (PST) Received: by 10.78.159.6 with HTTP; Tue, 28 Nov 2006 08:56:55 -0800 (PST) Message-ID: Date: Tue, 28 Nov 2006 12:56:55 -0400 From: "D G Teed" To: "AT Matik" In-Reply-To: <200611271806.50641.asstec@matik.com.br> MIME-Version: 1.0 References: <200611271806.50641.asstec@matik.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org Subject: Re: how to go about diagnosing cause of packet loss 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: Tue, 28 Nov 2006 16:57:23 -0000 Hi, OK, I think you've helped us prove that ipfw isn't the issue. The packet loss remained with rule 01 of allow ip from any to any. We'll need to measure our bandwidth processed on the box. Thanks for the help. --Donald Teed On 11/27/06, AT Matik wrote: > > On Monday 27 November 2006 16:56, D G Teed wrote: > > We suspect something in FreeBSD or ipfw has a flaw, > > but cannot find it. > > how are the results when your server has its FW open? > > Jo=E3o > > > > > > > > A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada > segura. > Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br > _______________________________________________ > 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 Wed Nov 29 07:55:42 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 36DBC16A415 for ; Wed, 29 Nov 2006 07:55:42 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31FB643CAD for ; Wed, 29 Nov 2006 07:55:40 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GpKI6-0005bW-MT; Wed, 29 Nov 2006 09:55:38 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GpKI0-0000mr-Vn; Wed, 29 Nov 2006 09:55:33 +0200 To: "D G Teed" From: Ian FREISLICH In-Reply-To: Message from "D G Teed" of "Tue, 28 Nov 2006 12:56:55 -0400." X-Attribution: BOFH Date: Wed, 29 Nov 2006 09:55:32 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2257/Wed Nov 29 05:12:04 2006) Cc: freebsd-ipfw@freebsd.org, AT Matik Subject: Re: how to go about diagnosing cause of packet loss 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: Wed, 29 Nov 2006 07:55:42 -0000 "D G Teed" wrote: > Hi, > > OK, I think you've helped us prove that ipfw isn't the issue. > The packet loss remained with rule 01 of allow ip from any > to any. We'll need to measure our bandwidth > processed on the box. Thanks for the help. What version of FreeBSD are you running. I've been experiencing wierd packet loss recently, which I suspect is a result of arp wierdness or routing table largness. It's a CURRENT box, ~1000 hosts behind it, ~1900 routes - not large by any stretch of the imagination. Packet loss doesn't seem related to bandwidth. Ian -- Ian Freislich From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 29 16:37:42 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5687016A403 for ; Wed, 29 Nov 2006 16:37:42 +0000 (UTC) (envelope-from donald.teed@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD7143CCC for ; Wed, 29 Nov 2006 16:36:49 +0000 (GMT) (envelope-from donald.teed@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1674288uge for ; Wed, 29 Nov 2006 08:36:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=B6mOOE0hpavt268ofiE3R7PbWj7mzWnyp1PkC5y2JwlD192JH8MNNdR3J/wVNbwB8B5F3A0GSEhQ+3JvLkgQ7y7HlecqRLJ0WK+QAj+vgopMG8fKUFyy2ZuMNhnWjyrHExOkKRkz8wtGLglOntkQRN6ZFDX1k/nMaXi9dlfTRy8= Received: by 10.78.180.18 with SMTP id c18mr2435146huf.1164818205399; Wed, 29 Nov 2006 08:36:45 -0800 (PST) Received: by 10.78.161.15 with HTTP; Wed, 29 Nov 2006 08:36:45 -0800 (PST) Message-ID: Date: Wed, 29 Nov 2006 12:36:45 -0400 From: "D G Teed" To: "Ian FREISLICH" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org, AT Matik Subject: Re: how to go about diagnosing cause of packet loss 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: Wed, 29 Nov 2006 16:37:42 -0000 Hi, With some further experimentation, I've concluded that the real problem is ipaudit. It cannot keep up with the bandwidth we have. When it is off, there is next to no packet loss. Thanks for the reply... --Donald On 11/29/06, Ian FREISLICH wrote: > > "D G Teed" wrote: > > Hi, > > > > OK, I think you've helped us prove that ipfw isn't the issue. > > The packet loss remained with rule 01 of allow ip from any > > to any. We'll need to measure our bandwidth > > processed on the box. Thanks for the help. > > What version of FreeBSD are you running. I've been experiencing > wierd packet loss recently, which I suspect is a result of arp > wierdness or routing table largness. It's a CURRENT box, ~1000 > hosts behind it, ~1900 routes - not large by any stretch of the > imagination. Packet loss doesn't seem related to bandwidth. > > Ian > > -- > Ian Freislich > From owner-freebsd-ipfw@FreeBSD.ORG Thu Nov 30 04:37:05 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 83E3916A407 for ; Thu, 30 Nov 2006 04:37:05 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1923743CA3 for ; Thu, 30 Nov 2006 04:36:58 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GpdfM-0006l5-Hf; Thu, 30 Nov 2006 06:36:56 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GpdfK-0008CC-S3; Thu, 30 Nov 2006 06:36:54 +0200 To: "D G Teed" From: Ian FREISLICH In-Reply-To: Message from "D G Teed" of "Wed, 29 Nov 2006 12:36:45 -0400." X-Attribution: BOFH Date: Thu, 30 Nov 2006 06:36:54 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2261/Thu Nov 30 05:57:45 2006) Cc: freebsd-ipfw@freebsd.org, AT Matik Subject: Re: how to go about diagnosing cause of packet loss 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, 30 Nov 2006 04:37:05 -0000 "D G Teed" wrote: > With some further experimentation, I've concluded > that the real problem is ipaudit. It cannot keep up > with the bandwidth we have. When it is off, there > is next to no packet loss. Thanks for the reply... Interesting. I use ipacct to collect accounting data, maybe you want some different data. It uses a divert socket that ipfw writes to with the tee action. It has no problem keeping up at 70Mbit/s. Maybe you're seeing traffic higher than that? Ian -- Ian Freislich From owner-freebsd-ipfw@FreeBSD.ORG Fri Dec 1 00:44:58 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C8D416A407 for ; Fri, 1 Dec 2006 00:44:58 +0000 (UTC) (envelope-from donald.teed@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id D650043CA2 for ; Fri, 1 Dec 2006 00:44:46 +0000 (GMT) (envelope-from donald.teed@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so2067540uge for ; Thu, 30 Nov 2006 16:44:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=lCY+CcqgfdE1axT+7BMCS6SjhNLdsi5bDL3v8J5lzjS0clfszfzCucW2RyUPfYt4Ak+VJn+cOvgKs1NeML7wb9zrDWQBRCpUwDnGDyAQp9+6faDReBOLqYycOaCn6oK6jylWD0G2sOyjgHMUb2NevDrdPxT60UuHK72Cs2kT4XM= Received: by 10.78.127.3 with SMTP id z3mr4251947huc.1164933896210; Thu, 30 Nov 2006 16:44:56 -0800 (PST) Received: by 10.78.161.15 with HTTP; Thu, 30 Nov 2006 16:44:56 -0800 (PST) Message-ID: Date: Thu, 30 Nov 2006 20:44:56 -0400 From: "D G Teed" To: "Ian FREISLICH" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-ipfw@freebsd.org, AT Matik Subject: RESOLVED: how to go about diagnosing cause of packet loss 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, 01 Dec 2006 00:44:58 -0000 OK, today we resolved the problems with the freebsd firewall. First there was more packet loss than normal. I killed the running ipaudit which usually helped. Packet loss continued. Watching the bandwidth with nload comparing the in of em0 (70 Mbps) with the out of em1 (28Mbps), it was clear there were packets not getting processed. Then I did a 'ipfw disable firewall', and the bandwidth outbound doubled in nload. It exceeded our Internet pipe by 2x. For the first time packet loss was also noticed by the outside of the firewall. Then the network guys put a packet sniffer on our internal traffic and found one notebook which was shooting out the majority of our traffic - mostly mangled packets which did not even register in the bandwidth noted by ipaudit. Only about .5 Gbytes per 30 minutes on udp port 7000 was showing up in ipaudit from this notebook as legit traffic. We blocked that notebook in the router, and ran ipfw and ipaudit as normal. Bandwidth returned to normal levels, input on internal equalled output on external and packet loss went to .5% from 40 to 50%. The fire is out. Thanks for the help here... Regards, --Donald On 11/29/06, D G Teed wrote: > > Hi, > > With some further experimentation, I've concluded > that the real problem is ipaudit. It cannot keep up > with the bandwidth we have. When it is off, there > is next to no packet loss. Thanks for the reply... > > --Donald > > On 11/29/06, Ian FREISLICH wrote: > > > > "D G Teed" wrote: > > > Hi, > > > > > > OK, I think you've helped us prove that ipfw isn't the issue. > > > The packet loss remained with rule 01 of allow ip from any > > > to any. We'll need to measure our bandwidth > > > processed on the box. Thanks for the help. > > > > What version of FreeBSD are you running. I've been experiencing > > wierd packet loss recently, which I suspect is a result of arp > > wierdness or routing table largness. It's a CURRENT box, ~1000 > > hosts behind it, ~1900 routes - not large by any stretch of the > > imagination. Packet loss doesn't seem related to bandwidth. > > > > Ian > > > > -- > > Ian Freislich > > > > From owner-freebsd-ipfw@FreeBSD.ORG Sat Dec 2 05:43:54 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0EA2A16A403 for ; Sat, 2 Dec 2006 05:43:54 +0000 (UTC) (envelope-from jhalstead@fsisys.com) Received: from hub.fsisys.com (hub.fsisys.com [65.73.42.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 517C743CA2 for ; Sat, 2 Dec 2006 05:43:35 +0000 (GMT) (envelope-from jhalstead@fsisys.com) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id EB08236781; Sat, 2 Dec 2006 00:43:52 -0500 (EST) Received: from [127.0.0.1] (gateway.fsisys.com [192.168.1.1]) by hub.fsisys.com (Postfix) with ESMTP id 20FE0366B9; Sat, 2 Dec 2006 00:43:51 -0500 (EST) Message-ID: <45711296.8010709@fsisys.com> Date: Fri, 01 Dec 2006 23:43:50 -0600 From: James Halstead User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Mysterious packets with stateful ipfw+nat 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: Sat, 02 Dec 2006 05:43:55 -0000 Ok, this has been driving me nuts for a while. I recently noticed that my 5.4-RELEASE firewall was having a problem with packet "leakage". I am seeing the occasional packet on the outside interface with an internal src ip. I put a hub between my firewall and cable modem and verified that the packets are indeed on the wire. Now I am in the process of setting up a new 6.1-RELEASE box and the same issue was happening on my test network. So far I don't get it. I must be missing something obvious. At least everything still works in general. The test setup is a clean install of 6.1-RELEASE, using GENERIC with the ipfw.ko and ipdivert.ko modules loaded. After searching around I was basing the configuration off of: http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182.html The test box has two Ethernet interfaces, renamed to be isp0 and net0. isp0 is using DHCP, and receives the address 10.42.0.220/24. net0 is running a DHCP server, and sits on 192.168.1.1/24. There is one single piece of hardware on net0 which is always assigned 192.168.1.230. The gateway to the actual Internet sits on 10.42.0.254. A pretty simple setup. The internal machine is just constantly connecting to an external web server to generate traffic. I see the same basic type of thing happen for other usage as well on my main network (ssh sessions, https/http sessions, etc). When looking at tcpdump I am occasionally seeing (on isp0): 19:35:27.591761 aa:aa:aa:5b:db:99 > bb:bb:bb:1f:33:da, 192.168.1.230.2542 > xx.xx.53.84.80: ., cksum 0xfade (correct), 2295591733:2295591733(0) ack 167570634 win 0 If this packet was truly supposed to be going out on the external interface, it should have gone through NAT and show a src ip of 10.42.0.220. To make it more frustrating, even if I enable ifpfw at layer 2, I am unable to capture these rogue packets. If I watch tcpdump on net0 at the same time, I see the following: 19:35:27.591767 aa:aa:aa:5b:db:98 > cc:cc:cc:10:04:ce, xx.xx.53.84.80 > 192.168.1.230.2542: ., cksum 0xfade (correct), 913:913(0) ack 1256 win 0 The only other thing that I have noticed, is that the packets seem to show up on the external interface at about the same time as the dynamic rules expire. The dynamic rule would look like: 192.168.1.230 2542 <-> xx.xx.53.84 80 Which is pretty much what I would expect. The same setup with a non-stateful ipfw ruleset (using established keyword) doesn't seem to have this problem. Any ideas? configuration follows. **** natd.conf **** unregistered_only yes dynamic yes #deny_incoming yes log_denied yes log_ipfw_denied yes (deny_incoming was set, turned it off to see if it helped but it works the same). ***** ipfw.rules **** # Test stateful firewall + natd script cmd="/sbin/ipfw add" natout="skipto 1000" oif="isp0" iif="net0" inet="192.168.1.0/24" NOROUTE="( 172.16.0.0/12 or 192.168.0.0/16 or \ 0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or 240.0.0.0/4 )" #### # Start with a clean ruleset /sbin/ipfw -q -f flush #### # Allow all traffic on the loopback and internal network, to keep this simple. $cmd 2 allow all from any to any via lo0 $cmd 5 allow all from any to any in via $iif $cmd 6 allow all from any to any out xmit $iif # Translate incoming traffic here $cmd 200 divert natd ip from any to any in via $oif $cmd 205 check-state # Outbound # Use stateful inspection to allow any connection from the internal network. $cmd 300 $natout tcp from any to any out via $oif setup keep-state $cmd 305 $natout udp from any to any out via $oif keep-state $cmd 310 $natout icmp from any to any out via $oif keep-state # Inbound # Prevent non-routable networks on the external interface. $cmd 400 deny all from $NOROUTE to any in via $oif # Allow incoming DHCP for external network address assignment. $cmd 450 allow udp from any to any 68 in via $oif keep-state # Allow incoming SSH to this machine $cmd 455 allow tcp from any to me 22 in via $oif setup keep-state # Allow incoming ICMP $cmd 460 allow icmp from any to any icmptypes 0,3,11,12 in via $oif $cmd 999 deny log ip from any to any # NAT rule for outgoing traffic. $cmd 1000 divert natd ip from any to any out via $oif $cmd 1005 allow ip from any to any Thanks for any insight, -James From owner-freebsd-ipfw@FreeBSD.ORG Sat Dec 2 18:00:40 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1AB5016A407 for ; Sat, 2 Dec 2006 18:00:40 +0000 (UTC) (envelope-from jhalstead@fsisys.com) Received: from hub.fsisys.com (hub.fsisys.com [65.73.42.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FB0F43CA6 for ; Sat, 2 Dec 2006 18:00:18 +0000 (GMT) (envelope-from jhalstead@fsisys.com) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id F1F7336630; Sat, 2 Dec 2006 13:00:38 -0500 (EST) Received: from [127.0.0.1] (gateway.fsisys.com [192.168.1.1]) by hub.fsisys.com (Postfix) with ESMTP id 370103662F; Sat, 2 Dec 2006 13:00:38 -0500 (EST) Message-ID: <4571BF45.3010608@fsisys.com> Date: Sat, 02 Dec 2006 12:00:37 -0600 From: James Halstead User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <45711296.8010709@fsisys.com> In-Reply-To: <45711296.8010709@fsisys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Mysterious packets with stateful ipfw+nat 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: Sat, 02 Dec 2006 18:00:40 -0000 Ok, the "obvious" part that I think I was missing while it was late, was that these must be keep-alive packets generated by the firewall as the dynamic rules are about to expire. That being the case however, shouldn't these keep-alive packets take the same action as the original rule (skipto 1000 and be diverted through NAT for processing)? James Halstead wrote: > Ok, this has been driving me nuts for a while. I recently noticed that > my 5.4-RELEASE firewall was having a problem with packet "leakage". I am > seeing the occasional packet on the outside interface with an internal > src ip. I put a hub between my firewall and cable modem and verified > that the packets are indeed on the wire. Now I am in the process of > setting up a new 6.1-RELEASE box and the same issue was happening on my > test network. > > So far I don't get it. I must be missing something obvious. At least > everything still works in general. > > The test setup is a clean install of 6.1-RELEASE, using GENERIC with the > ipfw.ko and ipdivert.ko modules loaded. After searching around I was > basing the configuration off of: > > http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182.html > > The test box has two Ethernet interfaces, renamed to be isp0 and net0. > isp0 is using DHCP, and receives the address 10.42.0.220/24. net0 is > running a DHCP server, and sits on 192.168.1.1/24. There is one single > piece of hardware on net0 which is always assigned 192.168.1.230. The > gateway to the actual Internet sits on 10.42.0.254. A pretty simple setup. > > The internal machine is just constantly connecting to an external web > server to generate traffic. I see the same basic type of thing happen > for other usage as well on my main network (ssh sessions, https/http > sessions, etc). When looking at tcpdump I am occasionally seeing (on isp0): > > 19:35:27.591761 aa:aa:aa:5b:db:99 > bb:bb:bb:1f:33:da, > 192.168.1.230.2542 > xx.xx.53.84.80: ., cksum 0xfade (correct), > 2295591733:2295591733(0) ack 167570634 win 0 > > If this packet was truly supposed to be going out on the external > interface, it should have gone through NAT and show a src ip of > 10.42.0.220. To make it more frustrating, even if I enable ifpfw at > layer 2, I am unable to capture these rogue packets. If I watch tcpdump > on net0 at the same time, I see the following: > > 19:35:27.591767 aa:aa:aa:5b:db:98 > cc:cc:cc:10:04:ce, > xx.xx.53.84.80 > 192.168.1.230.2542: ., cksum 0xfade (correct), > 913:913(0) ack 1256 win 0 > > The only other thing that I have noticed, is that the packets seem to > show up on the external interface at about the same time as the dynamic > rules expire. The dynamic rule would look like: > > 192.168.1.230 2542 <-> xx.xx.53.84 80 > > Which is pretty much what I would expect. The same setup with a > non-stateful ipfw ruleset (using established keyword) doesn't seem to > have this problem. Any ideas? configuration follows. > > > **** natd.conf **** > unregistered_only yes > dynamic yes > #deny_incoming yes > log_denied yes > log_ipfw_denied yes > > (deny_incoming was set, turned it off to see if it helped but it works > the same). > > ***** ipfw.rules **** > # Test stateful firewall + natd script > cmd="/sbin/ipfw add" > natout="skipto 1000" > oif="isp0" > iif="net0" > inet="192.168.1.0/24" > > NOROUTE="( 172.16.0.0/12 or 192.168.0.0/16 or \ > 0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or > 240.0.0.0/4 )" > > #### > # Start with a clean ruleset > /sbin/ipfw -q -f flush > > #### > # Allow all traffic on the loopback and internal network, to keep this > simple. > $cmd 2 allow all from any to any via lo0 > $cmd 5 allow all from any to any in via $iif > $cmd 6 allow all from any to any out xmit $iif > > # Translate incoming traffic here > $cmd 200 divert natd ip from any to any in via $oif > $cmd 205 check-state > > # Outbound > # Use stateful inspection to allow any connection from the internal > network. > $cmd 300 $natout tcp from any to any out via $oif setup keep-state > $cmd 305 $natout udp from any to any out via $oif keep-state > $cmd 310 $natout icmp from any to any out via $oif keep-state > > # Inbound > # Prevent non-routable networks on the external interface. > $cmd 400 deny all from $NOROUTE to any in via $oif > > # Allow incoming DHCP for external network address assignment. > $cmd 450 allow udp from any to any 68 in via $oif keep-state > > # Allow incoming SSH to this machine > $cmd 455 allow tcp from any to me 22 in via $oif setup keep-state > > # Allow incoming ICMP > $cmd 460 allow icmp from any to any icmptypes 0,3,11,12 in via $oif > > $cmd 999 deny log ip from any to any > > # NAT rule for outgoing traffic. > $cmd 1000 divert natd ip from any to any out via $oif > $cmd 1005 allow ip from any to any > > Thanks for any insight, > > -James From owner-freebsd-ipfw@FreeBSD.ORG Sat Dec 2 20:00:40 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CAD316A403 for ; Sat, 2 Dec 2006 20:00:40 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F5E343C9D for ; Sat, 2 Dec 2006 20:00:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.187.77] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Gqb291btA-0005T9; Sat, 02 Dec 2006 21:00:25 +0100 From: Max Laier Organization: FreeBSD To: freebsd-ipfw@freebsd.org Date: Sat, 2 Dec 2006 21:00:13 +0100 User-Agent: KMail/1.9.4 References: <45711296.8010709@fsisys.com> <4571BF45.3010608@fsisys.com> In-Reply-To: <4571BF45.3010608@fsisys.com> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1955192.6qAS8VG7f4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612022100.24704.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: James Halstead Subject: Re: Mysterious packets with stateful ipfw+nat 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: Sat, 02 Dec 2006 20:00:40 -0000 --nextPart1955192.6qAS8VG7f4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 02 December 2006 19:00, James Halstead wrote: > Ok, the "obvious" part that I think I was missing while it was late, > was that these must be keep-alive packets generated by the firewall as > the dynamic rules are about to expire. That being the case however, > shouldn't these keep-alive packets take the same action as the original > rule (skipto 1000 and be diverted through NAT for processing)? keep-alive packets are marked with M_SKIP_FIREWALL in=20 netinet/ip_fw2.c::send_pkt You could try to remove that, rebuild and see=20 if it helps. I'm not sure what the reasoning behind this setting was and=20 have no idea what implications it has to change it. If it helps your=20 setup we might want to consider a sysctl to change that behavior. > James Halstead wrote: > > Ok, this has been driving me nuts for a while. I recently noticed > > that my 5.4-RELEASE firewall was having a problem with packet > > "leakage". I am seeing the occasional packet on the outside interface > > with an internal src ip. I put a hub between my firewall and cable > > modem and verified that the packets are indeed on the wire. Now I am > > in the process of setting up a new 6.1-RELEASE box and the same issue > > was happening on my test network. > > > > So far I don't get it. I must be missing something obvious. At least > > everything still works in general. > > > > The test setup is a clean install of 6.1-RELEASE, using GENERIC with > > the ipfw.ko and ipdivert.ko modules loaded. After searching around I > > was basing the configuration off of: > > > > http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182. > >html > > > > The test box has two Ethernet interfaces, renamed to be isp0 and > > net0. isp0 is using DHCP, and receives the address 10.42.0.220/24. > > net0 is running a DHCP server, and sits on 192.168.1.1/24. There is > > one single piece of hardware on net0 which is always assigned > > 192.168.1.230. The gateway to the actual Internet sits on > > 10.42.0.254. A pretty simple setup. > > > > The internal machine is just constantly connecting to an external web > > server to generate traffic. I see the same basic type of thing happen > > for other usage as well on my main network (ssh sessions, https/http > > sessions, etc). When looking at tcpdump I am occasionally seeing (on > > isp0): > > > > 19:35:27.591761 aa:aa:aa:5b:db:99 > bb:bb:bb:1f:33:da, > > 192.168.1.230.2542 > xx.xx.53.84.80: ., cksum 0xfade (correct), > > 2295591733:2295591733(0) ack 167570634 win 0 > > > > If this packet was truly supposed to be going out on the external > > interface, it should have gone through NAT and show a src ip of > > 10.42.0.220. To make it more frustrating, even if I enable ifpfw at > > layer 2, I am unable to capture these rogue packets. If I watch > > tcpdump on net0 at the same time, I see the following: > > > > 19:35:27.591767 aa:aa:aa:5b:db:98 > cc:cc:cc:10:04:ce, > > xx.xx.53.84.80 > 192.168.1.230.2542: ., cksum 0xfade (correct), > > 913:913(0) ack 1256 win 0 > > > > The only other thing that I have noticed, is that the packets seem to > > show up on the external interface at about the same time as the > > dynamic rules expire. The dynamic rule would look like: > > > > 192.168.1.230 2542 <-> xx.xx.53.84 80 > > > > Which is pretty much what I would expect. The same setup with a > > non-stateful ipfw ruleset (using established keyword) doesn't seem to > > have this problem. Any ideas? configuration follows. > > > > > > **** natd.conf **** > > unregistered_only yes > > dynamic yes > > #deny_incoming yes > > log_denied yes > > log_ipfw_denied yes > > > > (deny_incoming was set, turned it off to see if it helped but it > > works the same). > > > > ***** ipfw.rules **** > > # Test stateful firewall + natd script > > cmd=3D"/sbin/ipfw add" > > natout=3D"skipto 1000" > > oif=3D"isp0" > > iif=3D"net0" > > inet=3D"192.168.1.0/24" > > > > NOROUTE=3D"( 172.16.0.0/12 or 192.168.0.0/16 or \ > > 0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or > > 240.0.0.0/4 )" > > > > #### > > # Start with a clean ruleset > > /sbin/ipfw -q -f flush > > > > #### > > # Allow all traffic on the loopback and internal network, to keep > > this simple. > > $cmd 2 allow all from any to any via lo0 > > $cmd 5 allow all from any to any in via $iif > > $cmd 6 allow all from any to any out xmit $iif > > > > # Translate incoming traffic here > > $cmd 200 divert natd ip from any to any in via $oif > > $cmd 205 check-state > > > > # Outbound > > # Use stateful inspection to allow any connection from the internal > > network. > > $cmd 300 $natout tcp from any to any out via $oif setup keep-state > > $cmd 305 $natout udp from any to any out via $oif keep-state > > $cmd 310 $natout icmp from any to any out via $oif keep-state > > > > # Inbound > > # Prevent non-routable networks on the external interface. > > $cmd 400 deny all from $NOROUTE to any in via $oif > > > > # Allow incoming DHCP for external network address assignment. > > $cmd 450 allow udp from any to any 68 in via $oif keep-state > > > > # Allow incoming SSH to this machine > > $cmd 455 allow tcp from any to me 22 in via $oif setup keep-state > > > > # Allow incoming ICMP > > $cmd 460 allow icmp from any to any icmptypes 0,3,11,12 in via $oif > > > > $cmd 999 deny log ip from any to any > > > > # NAT rule for outgoing traffic. > > $cmd 1000 divert natd ip from any to any out via $oif > > $cmd 1005 allow ip from any to any > > > > Thanks for any insight, > > > > -James > > _______________________________________________ > 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" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1955192.6qAS8VG7f4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFcdtYXyyEoT62BG0RAgrZAJ0WTowT43+Kl7v8+gVQ4BWjihILjgCcCima bmdWcoFheTXLLdRamx7lLTU= =Oyo2 -----END PGP SIGNATURE----- --nextPart1955192.6qAS8VG7f4-- From owner-freebsd-ipfw@FreeBSD.ORG Sat Dec 2 20:21:21 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2D1016A509 for ; Sat, 2 Dec 2006 20:21:21 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 593DE43CA2 for ; Sat, 2 Dec 2006 20:20:59 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id kB2KLLXX003411; Sat, 2 Dec 2006 12:21:21 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id kB2KLLTT003410; Sat, 2 Dec 2006 12:21:21 -0800 (PST) (envelope-from rizzo) Date: Sat, 2 Dec 2006 12:21:21 -0800 From: Luigi Rizzo To: Max Laier Message-ID: <20061202122121.A3343@xorpc.icir.org> References: <45711296.8010709@fsisys.com> <4571BF45.3010608@fsisys.com> <200612022100.24704.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200612022100.24704.max@love2party.net>; from max@love2party.net on Sat, Dec 02, 2006 at 09:00:13PM +0100 Cc: freebsd-ipfw@freebsd.org, James Halstead Subject: Re: Mysterious packets with stateful ipfw+nat 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: Sat, 02 Dec 2006 20:21:21 -0000 On Sat, Dec 02, 2006 at 09:00:13PM +0100, Max Laier wrote: > On Saturday 02 December 2006 19:00, James Halstead wrote: > > Ok, the "obvious" part that I think I was missing while it was late, > > was that these must be keep-alive packets generated by the firewall as > > the dynamic rules are about to expire. That being the case however, > > shouldn't these keep-alive packets take the same action as the original > > rule (skipto 1000 and be diverted through NAT for processing)? > > keep-alive packets are marked with M_SKIP_FIREWALL in > netinet/ip_fw2.c::send_pkt You could try to remove that, rebuild and see > if it helps. I'm not sure what the reasoning behind this setting was and > have no idea what implications it has to change it. If it helps your > setup we might want to consider a sysctl to change that behavior. if i remember well, the M_SKIP_FIREWALL is because otherwise they would reset the timer for the session as if a reply had come from the other side. i understand that this makes the interaction with nat a bit problematic. On te other hand, i don't have a better solution. cheers luigi > > James Halstead wrote: > > > Ok, this has been driving me nuts for a while. I recently noticed > > > that my 5.4-RELEASE firewall was having a problem with packet > > > "leakage". I am seeing the occasional packet on the outside interface > > > with an internal src ip. I put a hub between my firewall and cable > > > modem and verified that the packets are indeed on the wire. Now I am > > > in the process of setting up a new 6.1-RELEASE box and the same issue > > > was happening on my test network. > > > > > > So far I don't get it. I must be missing something obvious. At least > > > everything still works in general. > > > > > > The test setup is a clean install of 6.1-RELEASE, using GENERIC with > > > the ipfw.ko and ipdivert.ko modules loaded. After searching around I > > > was basing the configuration off of: > > > > > > http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-June/001182. > > >html > > > > > > The test box has two Ethernet interfaces, renamed to be isp0 and > > > net0. isp0 is using DHCP, and receives the address 10.42.0.220/24. > > > net0 is running a DHCP server, and sits on 192.168.1.1/24. There is > > > one single piece of hardware on net0 which is always assigned > > > 192.168.1.230. The gateway to the actual Internet sits on > > > 10.42.0.254. A pretty simple setup. > > > > > > The internal machine is just constantly connecting to an external web > > > server to generate traffic. I see the same basic type of thing happen > > > for other usage as well on my main network (ssh sessions, https/http > > > sessions, etc). When looking at tcpdump I am occasionally seeing (on > > > isp0): > > > > > > 19:35:27.591761 aa:aa:aa:5b:db:99 > bb:bb:bb:1f:33:da, > > > 192.168.1.230.2542 > xx.xx.53.84.80: ., cksum 0xfade (correct), > > > 2295591733:2295591733(0) ack 167570634 win 0 > > > > > > If this packet was truly supposed to be going out on the external > > > interface, it should have gone through NAT and show a src ip of > > > 10.42.0.220. To make it more frustrating, even if I enable ifpfw at > > > layer 2, I am unable to capture these rogue packets. If I watch > > > tcpdump on net0 at the same time, I see the following: > > > > > > 19:35:27.591767 aa:aa:aa:5b:db:98 > cc:cc:cc:10:04:ce, > > > xx.xx.53.84.80 > 192.168.1.230.2542: ., cksum 0xfade (correct), > > > 913:913(0) ack 1256 win 0 > > > > > > The only other thing that I have noticed, is that the packets seem to > > > show up on the external interface at about the same time as the > > > dynamic rules expire. The dynamic rule would look like: > > > > > > 192.168.1.230 2542 <-> xx.xx.53.84 80 > > > > > > Which is pretty much what I would expect. The same setup with a > > > non-stateful ipfw ruleset (using established keyword) doesn't seem to > > > have this problem. Any ideas? configuration follows. > > > > > > > > > **** natd.conf **** > > > unregistered_only yes > > > dynamic yes > > > #deny_incoming yes > > > log_denied yes > > > log_ipfw_denied yes > > > > > > (deny_incoming was set, turned it off to see if it helped but it > > > works the same). > > > > > > ***** ipfw.rules **** > > > # Test stateful firewall + natd script > > > cmd="/sbin/ipfw add" > > > natout="skipto 1000" > > > oif="isp0" > > > iif="net0" > > > inet="192.168.1.0/24" > > > > > > NOROUTE="( 172.16.0.0/12 or 192.168.0.0/16 or \ > > > 0.0.0.0/8 or 169.254.0.0/16 or 192.0.2.0/24 or 224.0.0.0/4 or > > > 240.0.0.0/4 )" > > > > > > #### > > > # Start with a clean ruleset > > > /sbin/ipfw -q -f flush > > > > > > #### > > > # Allow all traffic on the loopback and internal network, to keep > > > this simple. > > > $cmd 2 allow all from any to any via lo0 > > > $cmd 5 allow all from any to any in via $iif > > > $cmd 6 allow all from any to any out xmit $iif > > > > > > # Translate incoming traffic here > > > $cmd 200 divert natd ip from any to any in via $oif > > > $cmd 205 check-state > > > > > > # Outbound > > > # Use stateful inspection to allow any connection from the internal > > > network. > > > $cmd 300 $natout tcp from any to any out via $oif setup keep-state > > > $cmd 305 $natout udp from any to any out via $oif keep-state > > > $cmd 310 $natout icmp from any to any out via $oif keep-state > > > > > > # Inbound > > > # Prevent non-routable networks on the external interface. > > > $cmd 400 deny all from $NOROUTE to any in via $oif > > > > > > # Allow incoming DHCP for external network address assignment. > > > $cmd 450 allow udp from any to any 68 in via $oif keep-state > > > > > > # Allow incoming SSH to this machine > > > $cmd 455 allow tcp from any to me 22 in via $oif setup keep-state > > > > > > # Allow incoming ICMP > > > $cmd 460 allow icmp from any to any icmptypes 0,3,11,12 in via $oif > > > > > > $cmd 999 deny log ip from any to any > > > > > > # NAT rule for outgoing traffic. > > > $cmd 1000 divert natd ip from any to any out via $oif > > > $cmd 1005 allow ip from any to any > > > > > > Thanks for any insight, > > > > > > -James > > > > _______________________________________________ > > 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" > > -- > /"\ Best regards, | mlaier@freebsd.org > \ / Max Laier | ICQ #67774661 > X http://pf4freebsd.love2party.net/ | mlaier@EFnet > / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-ipfw@FreeBSD.ORG Sat Dec 2 21:44:43 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FBC116A403 for ; Sat, 2 Dec 2006 21:44:43 +0000 (UTC) (envelope-from jhalstead@fsisys.com) Received: from hub.fsisys.com (hub.fsisys.com [65.73.42.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9FD643CA5 for ; Sat, 2 Dec 2006 21:44:19 +0000 (GMT) (envelope-from jhalstead@fsisys.com) Received: from 127.0.0.1 (localhost [127.0.0.1]) by dummy.domain.name (Postfix) with SMTP id 09C7A3677C; Sat, 2 Dec 2006 16:44:42 -0500 (EST) Received: from [127.0.0.1] (gateway.fsisys.com [192.168.1.1]) by hub.fsisys.com (Postfix) with ESMTP id 62115366B9; Sat, 2 Dec 2006 16:44:41 -0500 (EST) Message-ID: <4571F3C9.7060302@fsisys.com> Date: Sat, 02 Dec 2006 15:44:41 -0600 From: James Halstead User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Luigi Rizzo References: <45711296.8010709@fsisys.com> <4571BF45.3010608@fsisys.com> <200612022100.24704.max@love2party.net> <20061202122121.A3343@xorpc.icir.org> In-Reply-To: <20061202122121.A3343@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org Subject: Re: Mysterious packets with stateful ipfw+nat 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: Sat, 02 Dec 2006 21:44:43 -0000 Luigi Rizzo wrote: > On Sat, Dec 02, 2006 at 09:00:13PM +0100, Max Laier wrote: >> On Saturday 02 December 2006 19:00, James Halstead wrote: >>> Ok, the "obvious" part that I think I was missing while it was late, >>> was that these must be keep-alive packets generated by the firewall as >>> the dynamic rules are about to expire. That being the case however, >>> shouldn't these keep-alive packets take the same action as the original >>> rule (skipto 1000 and be diverted through NAT for processing)? >> keep-alive packets are marked with M_SKIP_FIREWALL in >> netinet/ip_fw2.c::send_pkt You could try to remove that, rebuild and see >> if it helps. I'm not sure what the reasoning behind this setting was and >> have no idea what implications it has to change it. If it helps your >> setup we might want to consider a sysctl to change that behavior. > > if i remember well, the M_SKIP_FIREWALL is because otherwise they > would reset the timer for the session as if a reply had come from > the other side. > i understand that this makes the interaction with nat a bit problematic. > On te other hand, i don't have a better solution. Makes sense. What about having the keep-alive packets take the action of the parent rule? I don't know if that is possible but it seems like it would solve the problem. A note should be added to ipfw(8) to document this behavior, as knowing keep-alive skips the firewall would have saved me a lot of headache. Looks like ip_fw2.c comments are the only place that mention this. Thanks, -James > > cheers > luigi > [snip]