From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 10 11:07:04 2011 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 E0D94106566C for ; Mon, 10 Jan 2011 11:07:04 +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 C60268FC08 for ; Mon, 10 Jan 2011 11:07:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0AB74vB001791 for ; Mon, 10 Jan 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0AB74t7001789 for freebsd-ipfw@FreeBSD.org; Mon, 10 Jan 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 Jan 2011 11:07:04 GMT Message-Id: <201101101107.p0AB74t7001789@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, 10 Jan 2011 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/153415 ipfw [ipfw] [patch] Port numbers always zero in dynamic IPF o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o kern/152887 ipfw [ipfw] Can not set more then 1024 buckets with buckets o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/150798 ipfw [ipfw] ipfw2 fwd rule matches packets but does not do o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148157 ipfw [ipfw] IPFW in kernel nat BUG found in FreeBSD 8.1-PRE o conf/148144 ipfw [patch] add ipfw_nat support for rc.firewall simple ty o conf/148137 ipfw [ipfw] call order of natd and ipfw startup scripts o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. o kern/147720 ipfw [ipfw] ipfw dynamic rules and fwd o kern/145733 ipfw [ipfw] [patch] ipfw flaws with ipv6 fragments o kern/145305 ipfw [ipfw] ipfw problems, panics, data corruption, ipv6 so o kern/144269 ipfw [ipfw] problem with ipfw tables o kern/144187 ipfw [ipfw] deadlock using multiple ipfw nat and multiple l o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143653 ipfw [ipfw] [patch] ipfw nat redirect_port "buf is too smal o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result o kern/143474 ipfw [ipfw] ipfw table contains the same address f kern/142951 ipfw [dummynet] using pipes&queues gives OUCH! pipe should o kern/139581 ipfw [ipfw] "ipfw pipe" not limiting bandwidth o kern/139226 ipfw [ipfw] install_state: entry already present, done o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/136695 ipfw [ipfw] [patch] fwd reached after skipto in dynamic rul o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o o bin/134975 ipfw [patch] ipfw(8) can't work with set in rule file. o kern/131817 ipfw [ipfw] blocks layer2 packets that should not be blocke o kern/131601 ipfw [ipfw] [panic] 7-STABLE panic in nat_finalise (tcp=0) o kern/131558 ipfw [ipfw] Inconsistent "via" ipfw behavior o bin/130132 ipfw [patch] ipfw(8): no way to get mask from ipfw pipe sho o kern/129103 ipfw [ipfw] IPFW check state does not work =( o kern/129093 ipfw [ipfw] ipfw nat must not drop packets o kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n o kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l o kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o bin/125370 ipfw [ipfw] [patch] increase a line buffer limit o conf/123119 ipfw [patch] rc script for ipfw does not handle IPv6 o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip o kern/122109 ipfw [ipfw] ipfw nat traceroute problem s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121382 ipfw [dummynet] 6.3-RELEASE-p1 page fault in dummynet (corr o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/118993 ipfw [ipfw] page fault - probably it's a locking problem o bin/117214 ipfw ipfw(8) fwd with IPv6 treats input as IPv4 o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o docs/113803 ipfw [patch] ipfw(8) - don't get bitten by the fwd rule o kern/112561 ipfw [ipfw] ipfw fwd does not work with some TCP packets o kern/105330 ipfw [ipfw] [patch] ipfw (dummynet) does not allow to set q o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/98831 ipfw [ipfw] ipfw has UDP hickups o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v o kern/93300 ipfw [ipfw] ipfw pipe lost packets o kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/88659 ipfw [modules] ipfw and ip6fw do not work properly as modul o kern/87032 ipfw [ipfw] [patch] ipfw ioctl interface implementation o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/74104 ipfw [ipfw] ipfw2/1 conflict not detected or reported, manp o kern/73910 ipfw [ipfw] serious bug on forwarding of packets after NAT o kern/72987 ipfw [ipfw] ipfw/dummynet pipe/queue 'queue [BYTES]KBytes ( o kern/71366 ipfw [ipfw] "ipfw fwd" sometimes rewrites destination mac a o kern/69963 ipfw [ipfw] install_state warning about already existing en o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes o kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/51274 ipfw [ipfw] [patch] ipfw2 create dynamic rules with parent o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 80 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 10 20:07:29 2011 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 DD200106566B for ; Mon, 10 Jan 2011 20:07:28 +0000 (UTC) (envelope-from jay@experts-exchange.com) Received: from mail.experts-exchange.com (mail.experts-exchange.com [72.29.183.251]) by mx1.freebsd.org (Postfix) with ESMTP id B9D3A8FC14 for ; Mon, 10 Jan 2011 20:07:28 +0000 (UTC) Received: from mail.experts-exchange.com (localhost [127.0.0.1]) by mail.experts-exchange.com (Postfix) with ESMTP id C7068CA8F01 for ; Mon, 10 Jan 2011 11:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= experts-exchange.com; h=content-transfer-encoding:content-type :content-type:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=ee; t=1294688855; x= 1296503255; bh=+BTDAp9TCz4egr3dX1M3i8kjew6zP31cIN9xa7JkjOI=; b=l vGtJRuuGzxlI9GqjyY+e34C975Tb8nQHAgAqqoBNwjoq/dYyl70YInAHn75J4N86 4+MpUfgTJbUUCfHXjb5m8lfnAGkCUUlsZA4AK1aR3mIgzAbZWF4/HsVRL/lcgSxG 0LWvR3E3eyCSPxhIGwseDhq8q5OFGFXQXUXnkTyGPw= X-Virus-Scanned: amavisd-new at experts-exchange.com Received: from mail.experts-exchange.com ([127.0.0.1]) by mail.experts-exchange.com (mail.experts-exchange.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9eJVXmMHfRF for ; Mon, 10 Jan 2011 11:47:35 -0800 (PST) Received: from [192.168.103.94] (unknown [192.168.103.94]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jay) by mail.experts-exchange.com (Postfix) with ESMTPSA id 5BCDCCA8F0C for ; Mon, 10 Jan 2011 11:47:35 -0800 (PST) Message-ID: <4D2B625B.1030403@experts-exchange.com> Date: Mon, 10 Jan 2011 11:47:39 -0800 From: Jay Corrales User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Fwd: stunnel transparent proxy 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, 10 Jan 2011 20:07:29 -0000 Folks, In brief, I am trying to determine if this is possible with ipfw rules. Please see below. Thank you. -------- Original Message -------- Date: Fri, 7 Jan 2011 11:45:14 -0800 To: freebsd-hackers@freebsd.org Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org Subject: stunnel transparent proxy Folks, Would it be possible to devise an ipfw 'fwd' rule to pass along a socket connection with IP_BINDANY set via stunnel that forwards it to another process? The problem I'm having is the vnc service on the other side cannot reply back to the IP address because the routing does not redirect back through stunnel. I am testing configurations using apache (port 80 and 443) for convenience. Request : ext ip -> stunnel -> vnc svc Response : vnc svc X->ext ip instead of : vnc svc -> stunnel -> ext ip With stunnel's transparent set option traffic looks like : 19:31:34.162337 IP 192.168.103.69.52671> 127.0.0.1.80: Flags [S], seq 2050938762, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 7437993 ecr 0], length 0 19:31:37.153079 IP 192.168.103.69.52671> 127.0.0.1.80: Flags [S],.. 19:31:40.351804 IP 192.168.103.69.52671> 127.0.0.1.80: Flags [S], .. 19:31:43.550543 IP 192.168.103.69.52671> 127.0.0.1.80: Flags [S], seq 2050938762, win 65535, options [mss 16344,sackOK,eol], length 0 Without transparent, traffic flows fine, and looks like : 19:32:55.883404 IP 127.0.0.1.30326> 127.0.0.1.80: Flags [S], seq 2147354729, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 7446169 ecr 0], length 0 19:32:55.883575 IP 127.0.0.1.80> 127.0.0.1.30326: Flags [S.], seq 2770470513, ack 2147354730, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1229815108 ecr 7446169], length 0 19:32:55.883589 IP 127.0.0.1.30326> 127.0.0.1.80: Flags [.], ack 1, win 8960, options [nop,nop,TS val 7446169 ecr 1229815108], length 0 ... I did try and devise pf rules to redirect or rdr and nat, but neither worked. I am only vaguely familiar with ipfw, and from some of my research led me to believe it may be possible. Thanks P.S. I did post the same question earlier on freebsd-pf list as well. http://lists.freebsd.org/pipermail/freebsd-pf/2011-January/005914.html From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 14 15:15:04 2011 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 202C1106564A for ; Fri, 14 Jan 2011 15:15:04 +0000 (UTC) (envelope-from drinking.coffee@gmail.com) Received: from c3p0.reverse.net (smtp-1.out.reverse.net [69.162.163.8]) by mx1.freebsd.org (Postfix) with ESMTP id EBD8D8FC14 for ; Fri, 14 Jan 2011 15:15:03 +0000 (UTC) Received: from [192.168.2.175] (localhost.reverse.net [127.0.0.1]) by c3p0.reverse.net (Postfix) with ESMTP id 8C0601D7800 for ; Fri, 14 Jan 2011 08:55:27 -0600 (CST) Message-ID: <4D3063DF.9060001@gmail.com> Date: Fri, 14 Jan 2011 08:55:27 -0600 From: Matthew Walker User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org References: <4D2B625B.1030403@experts-exchange.com> In-Reply-To: <4D2B625B.1030403@experts-exchange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Fwd: stunnel transparent proxy 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, 14 Jan 2011 15:15:04 -0000 Perhaps you should ask one of your readers. Isn't that what 'experts-exchange.com' is for? Why should we help you? Jay Corrales wrote: > From: Jay Corrales > Folks, > > In brief, I am trying to determine if this is possible with ipfw > rules. Please see below. > > Thank you. > > -------- Original Message -------- > Date: Fri, 7 Jan 2011 11:45:14 -0800 > To: freebsd-hackers@freebsd.org > Cc: freebsd-stable@freebsd.org, freebsd-ports@freebsd.org > Subject: stunnel transparent proxy > > Folks, > > Would it be possible to devise an ipfw 'fwd' rule to pass along a socket > connection with IP_BINDANY set via stunnel that forwards it to another > process? The problem I'm having is the vnc service on the other side > cannot reply back to the IP address because the routing does not redirect > From owner-freebsd-ipfw@FreeBSD.ORG Fri Jan 14 17:50:47 2011 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 49BC5106566C for ; Fri, 14 Jan 2011 17:50:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from out-0.mx.aerioconnect.net (out-0-0.mx.aerioconnect.net [216.240.47.60]) by mx1.freebsd.org (Postfix) with ESMTP id 2C65F8FC13 for ; Fri, 14 Jan 2011 17:50:46 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id p0EHojku016781; Fri, 14 Jan 2011 09:50:45 -0800 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id CB2752D6013; Fri, 14 Jan 2011 09:50:44 -0800 (PST) Message-ID: <4D308D16.8020103@freebsd.org> Date: Fri, 14 Jan 2011 09:51:18 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Jay Corrales References: <4D2B625B.1030403@experts-exchange.com> In-Reply-To: <4D2B625B.1030403@experts-exchange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: freebsd-ipfw@freebsd.org Subject: Re: Fwd: stunnel transparent proxy 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, 14 Jan 2011 17:50:47 -0000 On 1/10/11 11:47 AM, Jay Corrales wrote: > > Folks, > > Would it be possible to devise an ipfw 'fwd' rule to pass along a > socket > connection with IP_BINDANY set via stunnel that forwards it to another > process? The problem I'm having is the vnc service on the other side > cannot reply back to the IP address because the routing does not > redirect > back through stunnel. I am testing configurations using apache (port 80 > and 443) for convenience. > > Request : > > ext ip -> stunnel -> vnc svc > > Response : > > vnc svc X->ext ip > > instead of : > > vnc svc -> stunnel -> ext ip so you want the tunnel to be used in only one direction? (not sure what stunnel actually is) > > With stunnel's transparent set option traffic looks like : > > 19:31:34.162337 IP 192.168.103.69.52671> 127.0.0.1.80: Flags [S], seq > 2050938762, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val > 7437993 ecr 0], length 0 > 19:31:37.153079 IP 192.168.103.69.52671> 127.0.0.1.80: Flags > [S],.. > 19:31:40.351804 IP 192.168.103.69.52671> 127.0.0.1.80: Flags > [S], .. > 19:31:43.550543 IP 192.168.103.69.52671> 127.0.0.1.80: Flags [S], seq > 2050938762, win 65535, options [mss 16344,sackOK,eol], length 0 well there can be a thousand reasons that there is no response.. where it the trace taken? on the server?, client? > > Without transparent, traffic flows fine, and looks like : > > 19:32:55.883404 IP 127.0.0.1.30326> 127.0.0.1.80: Flags [S], seq > 2147354729, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val > 7446169 ecr 0], length 0 > 19:32:55.883575 IP 127.0.0.1.80> 127.0.0.1.30326: Flags [S.], seq > 2770470513, ack 2147354730, win 65535, options [mss 16344,nop,wscale > 3,sackOK,TS val 1229815108 ecr 7446169], length 0 > 19:32:55.883589 IP 127.0.0.1.30326> 127.0.0.1.80: Flags [.], ack 1, > win > 8960, options [nop,nop,TS val 7446169 ecr 1229815108], length 0 127.0.0.1 <--> 127.0.0.1 is of limited usefulness :-) > > ... > > I did try and devise pf rules to redirect or rdr and nat, but neither > worked. I am only vaguely familiar with ipfw, and from some of my > research > led me to believe it may be possible. > > Thanks > > P.S. I did post the same question earlier on freebsd-pf list as well. > http://lists.freebsd.org/pipermail/freebsd-pf/2011-January/005914.html I don't really understand what you want to do with stunnel and what you hope to achieve. > > _______________________________________________ > 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 Sat Jan 15 16:12:53 2011 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 DDB9D106566B; Sat, 15 Jan 2011 16:12:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 385768FC12; Sat, 15 Jan 2011 16:12:52 +0000 (UTC) Received: from alph.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=128) by mail.allbsd.org (8.14.4/8.14.4) with ESMTP id p0FGCBpf022915; Sun, 16 Jan 2011 01:12:21 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p0FGC9R0034055; Sun, 16 Jan 2011 01:12:10 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 16 Jan 2011 01:12:06 +0900 (JST) Message-Id: <20110116.011206.258445491489571055.hrs@allbsd.org> To: smithi@nimnet.asn.au From: Hiroki Sato In-Reply-To: <20110108220300.Q15397@sola.nimnet.asn.au> References: <20110108141111.A15397@sola.nimnet.asn.au> <20110108220300.Q15397@sola.nimnet.asn.au> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jan_16_01_12_06_2011_533)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Sun, 16 Jan 2011 01:12:36 +0900 (JST) X-Spam-Status: No, score=-100.4 required=13.0 tests=AWL, CONTENT_TYPE_PRESENT, NO_RELAYS, USER_IN_WHITELIST, X_MAILER_PRESENT autolearn=unavailable version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: jamesbrandongooch@gmail.com, freebsd-ipfw@FreeBSD.org, hrs@FreeBSD.org, naylor.b.david@gmail.com, freebsduser@paradisegreen.co.uk Subject: Re: Request for policy decision: kernel nat vs/and/or natd 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, 15 Jan 2011 16:12:53 -0000 ----Security_Multipart(Sun_Jan_16_01_12_06_2011_533)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Smith wrote in <20110108220300.Q15397@sola.nimnet.asn.au>: sm> On Sat, 8 Jan 2011 15:02:29 +1100, Ian Smith wrote: sm> > On Fri, 7 Jan 2011, Brandon Gooch wrote: sm> > > On Thu, Dec 23, 2010 at 8:58 AM, Ian Smith wrote: sm> [..] sm> > > > We could: sm> > > > sm> > > > 1) Preference kernel nat over natd when both are enabled. sm> > > sm> > > I vote for #1. sm> > sm> > Thanks. So far, that makes an overwhelming majority of 2 / NIL :) sm> > sm> > I see that hrs@freebsd.org has just grabbed two related PRs: sm> > sm> > kern/148928: [ipfw] Problem with loading of ipfw NAT rules during system startup sm> > conf/153155: [PATCH] [8.2-BETA1] ipfw rules fail to load cleanly on start if nat enabled sm> > sm> > so this seems a good time to work up patches to that effect for review sm> > (/etc/rc.d/ipfw, maybe natd, /etc/rc.firewall) later tonight my time. sm> sm> Ok, the attached patches are against HEAD, which is currently identical sm> to 8-STABLE for these files. rc.d_ipfw.patch also applies to 7-STABLE sm> with an offset but rc.firewall.patch needs more work for 7. I've no box sm> on which to actually run-test tonight, and will be away for a few days. sm> sm> /etc/rc.d/ipfw: sm> . prefer kernel nat (loading ipfw_nat) to natd when both are enabled sm> . add ipdivert to required_modules - when only natd is enabled - as sm> proposed by Thomas Sandford in conf/153155 and also re kern/148928 sm> also fixing the related issue in conf/148137 (and possibly others) sm> . prefix /etc/rc.d/natd to firewall_coscripts when only natd is enabled sm> sm> /etc/rc.d/natd: sm> . seems nothing is needed; has KEYWORD nostart and so should only be sm> started now by ipfw when natd - but not firewall_nat - is enabled sm> sm> /etc/rc.firewall: sm> . move firewall_nat and natd code into a function, setup_nat() sm> preferring kernel firewall_nat to natd if both are enabled sm> . couldn't resist tidying up that code to within 80 columns sm> . call setup_nat also in 'simple' ruleset, with same intent as sm> proposed in conf/148144 by David Naylor sm> . couldn't resist fixing unnecessarily long line in 'workstation' The patches look good to me, but one thing I am wondering is rc.d/natd invocation in rc.d/ipfw. When natd_enable="YES", rc.d/natd invokes the daemon after the rc.d/ipfw script eventually even if firewall_nat_enable="YES". What do you think about adding natd to REQUIRE: line of rc.d/ipfw? Although I did not test it extensively, rc.d/natd can run safely before rc.d/ipfw and using REQUIRE is reasonable instead of using $firewall_coscripts from a viewpoint of the rc.d framework. -- Hiroki ----Security_Multipart(Sun_Jan_16_01_12_06_2011_533)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk0xx1YACgkQTyzT2CeTzy0ZAgCgkg3/wWx+O4zMnrmGz0cJQZxW pecAoMTJiaGS6PSA2hZXsjqLFGug3Jtc =eoX5 -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jan_16_01_12_06_2011_533)---- From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 15 16:15:40 2011 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 04898106564A; Sat, 15 Jan 2011 16:15:40 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CF0FB8FC1A; Sat, 15 Jan 2011 16:15:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0FGFdRe029428; Sat, 15 Jan 2011 16:15:39 GMT (envelope-from hrs@freefall.freebsd.org) Received: (from hrs@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0FGFdbL029424; Sat, 15 Jan 2011 16:15:39 GMT (envelope-from hrs) Date: Sat, 15 Jan 2011 16:15:39 GMT Message-Id: <201101151615.p0FGFdbL029424@freefall.freebsd.org> To: hrs@FreeBSD.org, freebsd-ipfw@FreeBSD.org, hrs@FreeBSD.org From: hrs@FreeBSD.org Cc: Subject: Re: conf/148137: [ipfw] call order of natd and ipfw startup scripts 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, 15 Jan 2011 16:15:40 -0000 Synopsis: [ipfw] call order of natd and ipfw startup scripts Responsible-Changed-From-To: freebsd-ipfw->hrs Responsible-Changed-By: hrs Responsible-Changed-When: Sat Jan 15 16:15:20 UTC 2011 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=148137 From owner-freebsd-ipfw@FreeBSD.ORG Sat Jan 15 16:16:31 2011 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 C72201065672; Sat, 15 Jan 2011 16:16:31 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9D94B8FC25; Sat, 15 Jan 2011 16:16:31 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p0FGGVeV029587; Sat, 15 Jan 2011 16:16:31 GMT (envelope-from hrs@freefall.freebsd.org) Received: (from hrs@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p0FGGVfS029583; Sat, 15 Jan 2011 16:16:31 GMT (envelope-from hrs) Date: Sat, 15 Jan 2011 16:16:31 GMT Message-Id: <201101151616.p0FGGVfS029583@freefall.freebsd.org> To: hrs@FreeBSD.org, freebsd-ipfw@FreeBSD.org, hrs@FreeBSD.org From: hrs@FreeBSD.org Cc: Subject: Re: conf/148144: [patch] add ipfw_nat support for rc.firewall simple type 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, 15 Jan 2011 16:16:31 -0000 Synopsis: [patch] add ipfw_nat support for rc.firewall simple type Responsible-Changed-From-To: freebsd-ipfw->hrs Responsible-Changed-By: hrs Responsible-Changed-When: Sat Jan 15 16:15:57 UTC 2011 Responsible-Changed-Why: I'll take this. http://www.freebsd.org/cgi/query-pr.cgi?pr=148144