From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 14 23:02:36 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1569716A4CE; Sun, 14 Mar 2004 23:02:36 -0800 (PST) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BD9143D45; Sun, 14 Mar 2004 23:02:35 -0800 (PST) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1B2m7G-000OSq-00; Mon, 15 Mar 2004 09:02:26 +0200 From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Wed, 10 Mar 2004 13:26:46 +0200." Date: Mon, 15 Mar 2004 09:02:26 +0200 Sender: ianf@hetzner.co.za Message-Id: cc: Max Laier cc: ipfw@freebsd.org cc: current@freebsd.org Subject: Re: PATCH: ip_input.c, ip_output.c, ipfw.8 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 07:02:36 -0000 > I'll have to figure out what the problem is and send a patch that > works for current. I'm pretty sure this patch is on the right track > though. Ok, here's the corrected patch for 5-CURRENT: http://www.freebsd.org/cgi/query-pr.cgi?pr=64240 If someone could look it over and commit it if all is well. Thanks, Ian -- Ian Freislich From owner-freebsd-ipfw@FreeBSD.ORG Sun Mar 14 23:14:36 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3785916A4CE for ; Sun, 14 Mar 2004 23:14:36 -0800 (PST) Received: from hetzner.co.za (lfw.hetzner.co.za [196.7.18.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A840C43D1F for ; Sun, 14 Mar 2004 23:14:35 -0800 (PST) (envelope-from ianf@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 3.36 #1) id 1B2mIq-000OVR-00; Mon, 15 Mar 2004 09:14:24 +0200 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Sergey Mikhalych From: Ian FREISLICH X-Attribution: BOFH Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_10775020400" Date: Mon, 15 Mar 2004 09:14:24 +0200 Sender: ianf@hetzner.co.za Message-Id: X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: ipfw@FreeBSD.org Subject: bin/49959 (ipfw tee port rule skips parsing next rules) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 07:14:36 -0000 This is a multipart MIME message. --==_Exmh_10775020400 Content-Type: text/plain; charset=us-ascii Hi ipfw@FreeBSD.org copied as responsible person for this PR. I don't know if this was ever resolved for you. I encountered the same problem last week. Here's a patch which fixes this problem for me. It's against 4.9-STABLE. save the two patch files. cd /usr/src/sys/netinet patch Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9F9B16A4CE for ; Mon, 15 Mar 2004 08:08:48 -0800 (PST) Received: from mail1.firstlink.com (mail1.firstlink.com [66.37.141.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 710A643D45 for ; Mon, 15 Mar 2004 08:08:48 -0800 (PST) (envelope-from dvm@firstlink.com) Received: from jackstraw (66-37-143-139.corp.firstlink.com [66.37.143.139]) by mail1.firstlink.com (Postfix) with ESMTP id 9D47CEBE0C for ; Mon, 15 Mar 2004 09:08:46 -0700 (MST) From: Dan Vande More To: freebsd-ipfw@freebsd.org In-Reply-To: <1079114684.1240.22.camel@dvmgentoo> References: <1079113870.1238.8.camel@dvmgentoo> <1079114684.1240.22.camel@dvmgentoo> Content-Type: text/plain Message-Id: <1079366908.1274.5.camel@dvmgentoo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 15 Mar 2004 09:08:28 -0700 Content-Transfer-Encoding: 7bit Subject: Re: transparent squid bridge X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dvm@firstlink.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 16:08:48 -0000 /*Repost, does anyone have an answer?*/ Ok, to show I did try here's my diff on the manual patching. I've triple checked my work, and everything appears to be the way it is supposed to be. I don't see the expected behavior, if anyone sees anything wrong, I would appreciate some input. Although the counter increases on rule 400 when a client requests a webpage on the other side of the bridge, a 'tcpdump port 80' on {proxy_server_ip_address} sees no packets whatsoever. A tcpdump on the bridge server (tcpdump -n port 80) shows the packets from the client going straight to the requested host, instead of being hijacked and sent to the proxy server. ************************************* bash-2.05b# egrep -v "^#" /etc/sysctl.conf sysctl net.link.ether.bridge_cfg='xl0 dc0' sysctl net.link.ether.bridge_ipfw=1 sysctl net.link.ether.bridge=1 sysctl net.inet.ip.forwarding=1 ************************************* ************************************** bash-2.05b# ipfw show 00100 56 2920 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 21 1078 fwd {proxy_server_ip_address} tcp from any to any dst-port 80 65000 19137 2942276 allow ip from any to any 65535 0 0 deny ip from any to any ************************************** The diff of the pre and post manual patched files ************************************** bash-2.05b# diff -u ip_fw2.c.default ip_fw2.c --- ip_fw2.c.working Fri Mar 12 12:26:51 2004 +++ ip_fw2.c Fri Mar 12 12:31:18 2004 @@ -2061,12 +2061,33 @@ goto done; case O_FORWARD_IP: + #if 0 if (args->eh) /* not valid on layer2 pkts */ break; + #endif if (!q || dyn_dir == MATCH_FORWARD) args->next_hop = &((ipfw_insn_sa *)cmd)->sa; retval = 0; + if (args->eh) { + struct m_hdr tag; + + if (hlen == 0) /* non IP */ + break; + /* + * tag with PACKET_TAG_IPFORWARD + * call ip_input() (need ip_forwarding=1 + * if this has to go out) + * mark packet as comsumed by the firewall + */ + tag.mh_type = MT_TAG; + tag.mh_flags = PACKET_TAG_IPFORWARD; + tag.mh_data = (caddr_t)args->next_hop; + tag.mh_next = m; + args->m = NULL; + retval = IP_FW_PORT_DENY_FLAG; + ip_input((struct mbuf *)&tag); + } goto done; default: ************************************** ip_input: ************************************** bash-2.05b# diff -u ip_input.c.working ip_input.c --- ip_input.c.working Fri Mar 12 12:31:30 2004 +++ ip_input.c Fri Mar 12 12:32:38 2004 @@ -509,7 +509,7 @@ * skip the firewall a second time */ if (args.next_hop) - goto ours; + goto pass; /* XXX was 'ours' */; args.m = m; i = ip_fw_chk_ptr(&args); ************************************** uname -a ************************************** FreeBSD squid.mydomain.com 5.2.1-RELEASE FreeBSD 5.2.1-RELEASE #2: Fri Mar 12 14:54:27 MST 2004 root@squid.mydomain.com:/usr/src/sys/i386/compile/squid i386 ************************************** Thanks again! Dan Vande More On Fri, 2004-03-12 at 11:04, Dan Vande More wrote: > I did try it manually, several times. My question in that scenario, is: > > Will it still work with: > > src/sys/netinet/ip_fw2.c,v 1.51.2.1 2003/12/23 12:25:56 maxim > > and > > src/sys/netinet/ip_input.c,v 1.259 2003/11/26 20:31:13 andre > > When I did apply it manually, it *seemed* like it didn't work. I admit > it could have easily been user error. > > Thanks! > > Dan > > On Fri, 2004-03-12 at 11:00, Luigi Rizzo wrote: > > On Fri, Mar 12, 2004 at 10:51:10AM -0700, Dan Vande More wrote: > > > Hey all > > > > how about applying the patch manually ? It is so trivial > > it would have taken less than posting this message... > > > > cheers > > luigi > > From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 11:01:33 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7654016A4F8 for ; Mon, 15 Mar 2004 11:01:31 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58A9343D2D for ; Mon, 15 Mar 2004 11:01:31 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i2FJ1Vbv055895 for ; Mon, 15 Mar 2004 11:01:31 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2FJ1UWE055889 for freebsd-ipfw@freebsd.org; Mon, 15 Mar 2004 11:01:30 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 15 Mar 2004 11:01:30 -0800 (PST) Message-Id: <200403151901.i2FJ1UWE055889@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 19:01:33 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2004/03/03] misc/63724 ipfw IPFW2 Queues dont t work 1 problem total. Non-critical problems From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 11:01:51 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1921C16A530 for ; Mon, 15 Mar 2004 11:01:51 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12BA443D2F for ; Mon, 15 Mar 2004 11:01:51 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i2FJ1obv056279 for ; Mon, 15 Mar 2004 11:01:50 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2FJ1oB7056273 for ipfw@freebsd.org; Mon, 15 Mar 2004 11:01:50 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 15 Mar 2004 11:01:50 -0800 (PST) Message-Id: <200403151901.i2FJ1oB7056273@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 19:01:51 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu f [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/08/25] kern/55984 ipfw [patch] time based firewalling support fo o [2003/12/29] kern/60719 ipfw ipfw: Headerless fragments generate cryp 10 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 11:20:09 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC87C16A4CF for ; Mon, 15 Mar 2004 11:20:09 -0800 (PST) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CEEE43D2D for ; Mon, 15 Mar 2004 11:20:09 -0800 (PST) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 6C8BA1FFDC1 for ; Mon, 15 Mar 2004 20:20:08 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 7EC7E1FFDBC; Mon, 15 Mar 2004 20:20:06 +0100 (CET) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 9613A154FC; Mon, 15 Mar 2004 19:14:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 8BFA2154F7 for ; Mon, 15 Mar 2004 19:14:34 +0000 (UTC) Date: Mon, 15 Mar 2004 19:14:34 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: freebsd-ipfw@FreeBSD.org In-Reply-To: <200403151901.i2FJ1UWE055889@freefall.freebsd.org> Message-ID: References: <200403151901.i2FJ1UWE055889@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Subject: Re: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 19:20:09 -0000 On Mon, 15 Mar 2004, FreeBSD bugmaster wrote: > Current FreeBSD problem reports > Critical problems > Serious problems > > S Submitted Tracker Resp. Description > ------------------------------------------------------------------------------- > o [2004/03/03] misc/63724 ipfw IPFW2 Queues dont t work > > 1 problem total. can someone please re-assign this to ipfw@ so that there will only be one mail. Thanks. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 11:25:05 2004 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61A4416A4CE; Mon, 15 Mar 2004 11:25:05 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4282B43D1F; Mon, 15 Mar 2004 11:25:05 -0800 (PST) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) i2FJP5bv062475; Mon, 15 Mar 2004 11:25:05 -0800 (PST) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2FJP50Q062470; Mon, 15 Mar 2004 11:25:05 -0800 (PST) (envelope-from simon) Date: Mon, 15 Mar 2004 11:25:05 -0800 (PST) From: "Simon L. Nielsen" Message-Id: <200403151925.i2FJP50Q062470@freefall.freebsd.org> To: simon@FreeBSD.org, freebsd-ipfw@FreeBSD.org, ipfw@FreeBSD.org Subject: Re: misc/63724: IPFW2 Queues dont t work X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 19:25:05 -0000 Synopsis: IPFW2 Queues dont t work Responsible-Changed-From-To: freebsd-ipfw->ipfw Responsible-Changed-By: simon Responsible-Changed-When: Mon Mar 15 11:23:54 PST 2004 Responsible-Changed-Why: Reassign to ipfw so the list only gets one GNATS reminder. Suggested by: Bjoern A. Zeeb http://www.freebsd.org/cgi/query-pr.cgi?pr=63724 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 11:25:05 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61A4416A4CE; Mon, 15 Mar 2004 11:25:05 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4282B43D1F; Mon, 15 Mar 2004 11:25:05 -0800 (PST) (envelope-from simon@FreeBSD.org) Received: from freefall.freebsd.org (simon@localhost [127.0.0.1]) i2FJP5bv062475; Mon, 15 Mar 2004 11:25:05 -0800 (PST) (envelope-from simon@freefall.freebsd.org) Received: (from simon@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2FJP50Q062470; Mon, 15 Mar 2004 11:25:05 -0800 (PST) (envelope-from simon) Date: Mon, 15 Mar 2004 11:25:05 -0800 (PST) From: "Simon L. Nielsen" Message-Id: <200403151925.i2FJP50Q062470@freefall.freebsd.org> To: simon@FreeBSD.org, freebsd-ipfw@FreeBSD.org, ipfw@FreeBSD.org Subject: Re: misc/63724: IPFW2 Queues dont t work X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 19:25:05 -0000 Synopsis: IPFW2 Queues dont t work Responsible-Changed-From-To: freebsd-ipfw->ipfw Responsible-Changed-By: simon Responsible-Changed-When: Mon Mar 15 11:23:54 PST 2004 Responsible-Changed-Why: Reassign to ipfw so the list only gets one GNATS reminder. Suggested by: Bjoern A. Zeeb http://www.freebsd.org/cgi/query-pr.cgi?pr=63724 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 16:33:43 2004 Return-Path: Delivered-To: freebsd-ipfw@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D75A016A4CE; Mon, 15 Mar 2004 16:33:43 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C8543D45; Mon, 15 Mar 2004 16:33:43 -0800 (PST) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) i2G0Xhbv005488; Mon, 15 Mar 2004 16:33:43 -0800 (PST) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2G0XhNf005484; Mon, 15 Mar 2004 16:33:43 -0800 (PST) (envelope-from kris) Date: Mon, 15 Mar 2004 16:33:43 -0800 (PST) From: Kris Kennaway Message-Id: <200403160033.i2G0XhNf005484@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-ipfw@FreeBSD.org Subject: Re: kern/63961: ipfw2 uid matching doesn't work correctly X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 00:33:44 -0000 Synopsis: ipfw2 uid matching doesn't work correctly Responsible-Changed-From-To: freebsd-bugs->freebsd-ipfw Responsible-Changed-By: kris Responsible-Changed-When: Mon Mar 15 16:33:36 PST 2004 Responsible-Changed-Why: Assign to ipfw mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=63961 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 16:34:17 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 434E116A4CF; Mon, 15 Mar 2004 16:34:17 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 243C343D1F; Mon, 15 Mar 2004 16:34:17 -0800 (PST) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) i2G0YHbv005550; Mon, 15 Mar 2004 16:34:17 -0800 (PST) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2G0YH0a005546; Mon, 15 Mar 2004 16:34:17 -0800 (PST) (envelope-from kris) Date: Mon, 15 Mar 2004 16:34:17 -0800 (PST) From: Kris Kennaway Message-Id: <200403160034.i2G0YH0a005546@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, ipfw@FreeBSD.org Subject: Re: kern/61259: [patch] make "ipfw tee" work as intended under freebsd-5 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 00:34:17 -0000 Synopsis: [patch] make "ipfw tee" work as intended under freebsd-5 Responsible-Changed-From-To: freebsd-bugs->ipfw Responsible-Changed-By: kris Responsible-Changed-When: Mon Mar 15 16:34:07 PST 2004 Responsible-Changed-Why: Assign to ipfw mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=61259 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 16:35:10 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BBC916A4CE; Mon, 15 Mar 2004 16:35:09 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D204643D1D; Mon, 15 Mar 2004 16:35:09 -0800 (PST) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) i2G0Z9bv005608; Mon, 15 Mar 2004 16:35:09 -0800 (PST) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2G0Z9c2005604; Mon, 15 Mar 2004 16:35:09 -0800 (PST) (envelope-from kris) Date: Mon, 15 Mar 2004 16:35:09 -0800 (PST) From: Kris Kennaway Message-Id: <200403160035.i2G0Z9c2005604@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, ipfw@FreeBSD.org Subject: Re: kern/62598: no logging on ipfw loadable module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 00:35:10 -0000 Synopsis: no logging on ipfw loadable module Responsible-Changed-From-To: freebsd-bugs->ipfw Responsible-Changed-By: kris Responsible-Changed-When: Mon Mar 15 16:34:48 PST 2004 Responsible-Changed-Why: Assign to ipfw mailing list for analysis of suggestion http://www.freebsd.org/cgi/query-pr.cgi?pr=62598 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 16:35:28 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B84E16A4CE; Mon, 15 Mar 2004 16:35:28 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DF0343D3F; Mon, 15 Mar 2004 16:35:28 -0800 (PST) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) i2G0ZSbv005682; Mon, 15 Mar 2004 16:35:28 -0800 (PST) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2G0ZSVe005678; Mon, 15 Mar 2004 16:35:28 -0800 (PST) (envelope-from kris) Date: Mon, 15 Mar 2004 16:35:28 -0800 (PST) From: Kris Kennaway Message-Id: <200403160035.i2G0ZSVe005678@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, ipfw@FreeBSD.org Subject: Re: kern/64240: IPFW tee terminates rule processing X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 00:35:28 -0000 Synopsis: IPFW tee terminates rule processing Responsible-Changed-From-To: freebsd-bugs->ipfw Responsible-Changed-By: kris Responsible-Changed-When: Mon Mar 15 16:35:19 PST 2004 Responsible-Changed-Why: Assign to ipfw mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=64240 From owner-freebsd-ipfw@FreeBSD.ORG Mon Mar 15 18:40:13 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EF9A16A4CE for ; Mon, 15 Mar 2004 18:40:13 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5627343D46 for ; Mon, 15 Mar 2004 18:40:13 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i2G2eDbv018922 for ; Mon, 15 Mar 2004 18:40:13 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2G2eDWl018921; Mon, 15 Mar 2004 18:40:13 -0800 (PST) (envelope-from gnats) Date: Mon, 15 Mar 2004 18:40:13 -0800 (PST) Message-Id: <200403160240.i2G2eDWl018921@freefall.freebsd.org> To: ipfw@FreeBSD.org From: "JJB" Subject: Re: kern/62598: no logging on ipfw loadable module X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: JJB List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 02:40:13 -0000 The following reply was made to PR kern/62598; it has been noted by GNATS. From: "JJB" To: , "JJB" Cc: Subject: Re: kern/62598: no logging on ipfw loadable module Date: Mon, 15 Mar 2004 21:37:09 -0500 Shortly after this PR was submitted, it was determined that the problem report was based on this message ["IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled"] which is issued by the load of the ipfw loadable module when not compiled into the kernel. Upon ignoring intended meaning of said message, testing verified ipfw loadable module, does include logging code which only needs rc.conf statements to activate and enable. Conclusion: Message issued when ipfw loadable module is enabled is worded inaccurately. Message should be reworded to more clearly state status. Message that states that options are disabled imply those options where not compiled into the ipfw loadable module, which testing has proven to not be true. From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 16 04:39:01 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B18E16A4CE for ; Tue, 16 Mar 2004 04:39:01 -0800 (PST) Received: from mail017.syd.optusnet.com.au (mail017.syd.optusnet.com.au [211.29.132.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FAAA43D39 for ; Tue, 16 Mar 2004 04:38:59 -0800 (PST) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-241-126.eburwd5.vic.optusnet.com.au [211.28.241.126])i2GCcmA16340; Tue, 16 Mar 2004 23:38:49 +1100 Received: by marvin.home.local (Postfix, from userid 1001) id 949721FB81; Tue, 16 Mar 2004 23:38:48 +1100 (EST) Date: Tue, 16 Mar 2004 23:38:48 +1100 From: Tony Frank To: Dan Vande More Message-ID: <20040316123848.GA89792@marvin.home.local> References: <1079113870.1238.8.camel@dvmgentoo> <1079114684.1240.22.camel@dvmgentoo> <1079366908.1274.5.camel@dvmgentoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079366908.1274.5.camel@dvmgentoo> User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw@freebsd.org Subject: Re: transparent squid bridge X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 12:39:01 -0000 Hi there, On Mon, Mar 15, 2004 at 09:08:28AM -0700, Dan Vande More wrote: > /*Repost, does anyone have an answer?*/ Maybe, see below. > Ok, to show I did try here's my diff on the manual patching. I've triple > checked my work, and everything appears to be the way it is supposed to > be. Your diff looks ok, though I only took a cursury look at it. Are you running with 'options BRIDGE' in your kernel or loading bridge module? Are you using ipfw2 or ipfw1 ? > I don't see the expected behavior, if anyone sees anything wrong, I > would appreciate some input. I wonder if you are expecting something other than the behaviour this gives? > Although the counter increases on rule 400 when a client requests a > webpage on the other side of the bridge, a 'tcpdump port 80' on > {proxy_server_ip_address} sees no packets whatsoever. > A tcpdump on the bridge server (tcpdump -n port 80) shows the packets > from the client going straight to the requested host, instead of being > hijacked and sent to the proxy server. Is your proxy and your bridge on the same system? If it is, perhaps try building the setup with two separate servers to make things a bit clearer. Either setup seemed to work for me. Note: The traffic that is 'captured' will not be rewritten to have a new destination IP address. Rather that traffic is instead sent to the new destination directly. It is up to the destination to 'recognise' this traffic and treat it appropriately. If the hosts are on separate servers you should see 'uncaptured' traffic being sent on to the default gateway (check ethernet link headers with -E option to tcpdump) and 'captured' traffic being sent to the proxy server. This is where it helps to have separate box for each function to clearly see the ethernet headers being different. >From luigi's original post: >on bridge: >sysctl net.link.ether.bridge_cfg="rl0 rl1" >sysctl net.link.ether.bridge_ipfw=1 >sysctl net.link.ether.bridge=1 >sysctl net.inet.ip.forwarding=1 >ipfw add forward proxy proto tcp from any to any 80 > >on proxy: >ipfw add forward localhost,8080 tcp from not me to any 80 Note this second ipfw line on the proxy itself. It needs to be configured to redirect the traffic to the proxy software port otherwise the server might well forward the traffic someplace else (like to a default next-hop) This setup works for me in that the tcp connection to port 80 is intercepted and sent to the local bridge/squid system, however my squid currently returns an error due to 'invalid URL' or similar. Basically it seems the URL hostname is not seen by squid. I'm running 2.4.STABLE7 and did not configure anything new in squid. That aside, the point is the redirecting of traffic from a bridge is working with these patches and FreeBSD 4.9-STABLE cvsupped today. If I have the fwd line in ipfw I get a squid error page on by client browser. If I stop squid I get a browser error due to TCP reset being received as nothing is listening on the proxy for the traffic. > ************************************* > bash-2.05b# egrep -v "^#" /etc/sysctl.conf > sysctl net.link.ether.bridge_cfg='xl0 dc0' > sysctl net.link.ether.bridge_ipfw=1 > sysctl net.link.ether.bridge=1 > sysctl net.inet.ip.forwarding=1 > ************************************* Umm, is this really what you're using? Perhaps check that all these options applied by running sysctl manually? My sysctl.conf looks like this: %%% net.link.ether.bridge_cfg="fxp0 fxp2" net.link.ether.bridge_ipfw=1 net.link.ether.bridge=1 %%% And if I run sysctl manually I get: midway [298] [11:30pm] [/var/log/squid]# sysctl net.link.ether net.link.ether.inet.prune_intvl: 300 net.link.ether.inet.max_age: 1200 net.link.ether.inet.host_down_time: 20 net.link.ether.inet.maxtries: 5 net.link.ether.inet.useloopback: 1 net.link.ether.inet.proxyall: 0 net.link.ether.inet.log_arp_wrong_iface: 1 net.link.ether.inet.log_arp_movements: 1 net.link.ether.bridge_cfg: fxp0 fxp2 net.link.ether.bridge: 1 net.link.ether.bridge_ipfw: 1 net.link.ether.bridge_ipf: 0 net.link.ether.bridge_ipfw_drop: 0 net.link.ether.bridge_ipfw_collisions: 0 net.link.ether.verbose: 0 net.link.ether.bdg_split_pkts: 0 net.link.ether.bdg_thru: 11580 net.link.ether.bdg_copied: 0 net.link.ether.bdg_copy: 0 net.link.ether.bdg_predict: 11351 net.link.ether.bdg_fw_avg: 0 net.link.ether.bdg_fw_ticks: 0 net.link.ether.bdg_fw_count: 0 net.link.ether.ipfw: 0 > > ************************************** > bash-2.05b# ipfw show > 00100 56 2920 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 21 1078 fwd {proxy_server_ip_address} tcp from any to any > dst-port 80 > 65000 19137 2942276 allow ip from any to any > 65535 0 0 deny ip from any to any > ************************************** Looks ok,but check the fwd rule - here's my setup: midway [297] [11:29pm] [/var/log/squid]# ipfw show 00010 46 3439 skipto 20000 ip from any to any layer2 00100 12 2122 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 01000 16 2202 allow ip from any to any 20000 46 3439 count log ip from any to any 20010 5 497 fwd 127.0.0.1,3128 tcp from any to any dst-port 80 20011 41 2942 count log ip from any to any 20012 41 2942 allow ip from any to any 65000 0 0 deny log ip from any to any 65535 0 0 deny ip from any to any I have squid listening on 127.0.0.1 port 3128. I also got it working using a second server, albeit with the error listed above (which is squid configuration, not ipfw) Hope it helps, Regards, Tony From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 16 05:30:47 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA6FB16A4D2 for ; Tue, 16 Mar 2004 05:30:47 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0C2043D2D for ; Tue, 16 Mar 2004 05:30:47 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.10/8.12.10) with ESMTP id i2GDUlbv001796 for ; Tue, 16 Mar 2004 05:30:47 -0800 (PST) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2GDUlo6001792; Tue, 16 Mar 2004 05:30:47 -0800 (PST) (envelope-from gnats) Date: Tue, 16 Mar 2004 05:30:47 -0800 (PST) Message-Id: <200403161330.i2GDUlo6001792@freefall.freebsd.org> To: ipfw@FreeBSD.org From: Ian FREISLICH Subject: Re: kern/64240: IPFW tee terminates rule processing X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ian FREISLICH List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 13:30:48 -0000 The following reply was made to PR kern/64240; it has been noted by GNATS. From: Ian FREISLICH To: freebsd-gnats-submit@FreeBSD.org Cc: Subject: Re: kern/64240: IPFW tee terminates rule processing Date: Tue, 16 Mar 2004 15:29:55 +0200 The patch in this PR is not quite right. The packet is cloned in the wrong place for reinsertion into the firewall which results in packets being silently dropped. Here is a corrected patch. -- Ian Freislich Index: sbin/ipfw/ipfw.8 =================================================================== RCS file: /home/ncvs/src/sbin/ipfw/ipfw.8,v retrieving revision 1.139 diff -u -d -r1.139 ipfw.8 --- sbin/ipfw/ipfw.8 23 Jan 2004 06:37:19 -0000 1.139 +++ sbin/ipfw/ipfw.8 10 Mar 2004 09:03:06 -0000 @@ -658,10 +658,7 @@ .Xr divert 4 socket bound to port .Ar port . -The search terminates and the original packet is accepted -(but see Section -.Sx BUGS -below). +The search continues at the next rule. .It Cm unreach Ar code Discard packets that match this rule, and try to send an ICMP unreachable notice with code @@ -2169,12 +2166,6 @@ are reassembled before delivery to the socket. The action used on those packet is the one from the rule which matches the first fragment of the packet. -.Pp -Packets that match a -.Cm tee -rule should not be immediately accepted, but should continue -going through the rule list. -This may be fixed in a later version. .Pp Packets diverted to userland, and then reinserted by a userland process may lose various packet attributes. Index: sys/netinet/ip_fastfwd.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fastfwd.c,v retrieving revision 1.8 diff -u -d -r1.8 ip_fastfwd.c --- sys/netinet/ip_fastfwd.c 25 Feb 2004 19:55:28 -0000 1.8 +++ sys/netinet/ip_fastfwd.c 16 Mar 2004 13:23:21 -0000 @@ -337,11 +337,20 @@ bzero(&args, sizeof(args)); args.m = m; +#ifdef IPDIVERT +tee_again: +#endif ipfw = ip_fw_chk_ptr(&args); m = args.m; M_ASSERTVALID(m); M_ASSERTPKTHDR(m); +#ifdef IPDIVERT + if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) + clone = divert_clone(m); + else + clone = m; +#endif /* * Packet denied, drop it @@ -368,10 +377,6 @@ /* * Tee packet */ - if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) - clone = divert_clone(m); - else - clone = m; if (clone == NULL) goto passin; @@ -395,11 +400,12 @@ /* * If this was not tee, we are done */ - m = clone; if ((ipfw & IP_FW_PORT_TEE_FLAG) == 0) return 1; /* Continue if it was tee */ - goto passin; + args.m = clone; + args.tee_continue = 1; + goto tee_again; } #endif if (ipfw == 0 && args.next_hop != NULL) { @@ -512,11 +518,20 @@ args.m = m; args.oif = ifp; +#ifdef IPDIVERT +tee_again2: +#endif ipfw = ip_fw_chk_ptr(&args); m = args.m; M_ASSERTVALID(m); M_ASSERTPKTHDR(m); +#ifdef IPDIVERT + if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) + clone = divert_clone(m); + else + clone = m; +#endif if ((ipfw & IP_FW_PORT_DENY_FLAG) || m == NULL) { RTFREE(ro.ro_rt); @@ -544,10 +559,6 @@ /* * Tee packet */ - if ((ipfw & IP_FW_PORT_TEE_FLAG) != 0) - clone = divert_clone(m); - else - clone = m; if (clone == NULL) goto passout; @@ -571,13 +582,14 @@ /* * If this was not tee, we are done */ - m = clone; if ((ipfw & IP_FW_PORT_TEE_FLAG) == 0) { RTFREE(ro.ro_rt); return 1; } /* Continue if it was tee */ - goto passout; + args.m =clone; + args.tee_continue = 1; + goto tee_again2; } #endif if (ipfw == 0 && args.next_hop != NULL) { Index: sys/netinet/ip_fw.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.h,v retrieving revision 1.83 diff -u -d -r1.83 ip_fw.h --- sys/netinet/ip_fw.h 25 Feb 2004 19:55:28 -0000 1.83 +++ sys/netinet/ip_fw.h 15 Mar 2004 11:33:07 -0000 @@ -400,6 +400,7 @@ int flags; /* for dummynet */ struct ipfw_flow_id f_id; /* grabbed from IP header */ + int tee_continue; /* continue after packet tee */ u_int32_t retval; }; Index: sys/netinet/ip_fw2.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw2.c,v retrieving revision 1.56 diff -u -d -r1.56 ip_fw2.c --- sys/netinet/ip_fw2.c 25 Feb 2004 19:55:28 -0000 1.56 +++ sys/netinet/ip_fw2.c 16 Mar 2004 12:47:24 -0000 @@ -1361,10 +1361,6 @@ * args->eh (in) Mac header if present, or NULL for layer3 packet. * args->oif Outgoing interface, or NULL if packet is incoming. * The incoming interface is in the mbuf. (in) - * args->divert_rule (in/out) - * Skip up to the first rule past this rule number; - * upon return, non-zero port number for divert or tee. - * * args->rule Pointer to the last matching rule (in/out) * args->next_hop Socket we are forwarding to (out). * args->f_id Addresses grabbed from the packet (out) @@ -1554,13 +1550,18 @@ * to restart processing. * * If fw_one_pass != 0 then just accept it. - * XXX should not happen here, but optimized out in - * the caller. + * XXX should not happen here unless the packet was tee'd, + * but optimized out in the caller. */ - if (fw_one_pass) { + if (fw_one_pass && !args->tee_continue) { IPFW_UNLOCK(chain); /* XXX optimize */ return 0; } + /* + * Reset this so that fw_one_pass is obeyed if we + * land up here again for reasons other than tee_continue + */ + args->tee_continue = 0; f = args->rule->next_rule; if (f == NULL) @@ -2044,6 +2045,7 @@ cmd->arg1 | IP_FW_PORT_TEE_FLAG; m_tag_prepend(m, mtag); retval = dt->info; + args->rule = f; /* report matching rule */ goto done; } Index: sys/netinet/ip_input.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v retrieving revision 1.266 diff -u -d -r1.266 ip_input.c --- sys/netinet/ip_input.c 1 Mar 2004 22:37:01 -0000 1.266 +++ sys/netinet/ip_input.c 16 Mar 2004 10:48:36 -0000 @@ -304,6 +304,7 @@ struct in_addr pkt_dst; #ifdef IPDIVERT u_int32_t divert_info; /* packet divert/tee info */ + struct mbuf *clone = NULL; /* saved mbuf for tee */ #endif struct ip_fw_args args; int dchg = 0; /* dest changed after fw */ @@ -474,8 +475,17 @@ goto ours; args.m = m; +#ifdef IPDIVERT +tee_again: +#endif i = ip_fw_chk_ptr(&args); m = args.m; +#ifdef IPDIVERT + if ((i & IP_FW_PORT_TEE_FLAG) != 0) + clone = divert_clone(m); + else + clone = NULL; +#endif if ( (i & IP_FW_PORT_DENY_FLAG) || m == NULL) { /* drop */ if (m) @@ -837,14 +847,6 @@ */ divert_info = divert_find_info(m); if (divert_info != 0) { - struct mbuf *clone; - - /* Clone packet if we're doing a 'tee' */ - if ((divert_info & IP_FW_PORT_TEE_FLAG) != 0) - clone = divert_clone(m); - else - clone = NULL; - /* Restore packet header fields to original values */ ip->ip_len += hlen; ip->ip_len = htons(ip->ip_len); @@ -854,12 +856,10 @@ divert_packet(m, 1); ipstat.ips_delivered++; - /* If 'tee', continue with original packet */ + /* If 'tee', continue processing firewall rules + * with the original packet */ if (clone == NULL) return; - m = clone; - ip = mtod(m, struct ip *); - ip->ip_len += hlen; /* * Jump backwards to complete processing of the * packet. We do not need to clear args.next_hop @@ -867,7 +867,9 @@ * doesn't contain a divert packet tag so we won't * re-entry this block. */ - goto pass; + args.m = clone; + args.tee_continue = 1; + goto tee_again; } #endif Index: sys/netinet/ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.211 diff -u -d -r1.211 ip_output.c --- sys/netinet/ip_output.c 2 Mar 2004 14:37:23 -0000 1.211 +++ sys/netinet/ip_output.c 16 Mar 2004 13:25:22 -0000 @@ -730,14 +730,27 @@ */ if (fw_enable && IPFW_LOADED && !args.next_hop) { struct sockaddr_in *old = dst; +#ifdef IPDIVERT + struct mbuf *clone = NULL; +#endif args.m = m; args.next_hop = dst; args.oif = ifp; +#ifdef IPDIVERT +tee_again: +#endif off = ip_fw_chk_ptr(&args); m = args.m; dst = args.next_hop; +#ifdef IPDIVERT + /* Clone packet if we're doing a 'tee' */ + if ((off & IP_FW_PORT_TEE_FLAG) != 0) + clone = divert_clone(m); + else + clone = NULL; +#endif /* * On return we must do the following: * m == NULL -> drop the pkt (old interface, deprecated) @@ -782,14 +795,6 @@ } #ifdef IPDIVERT if (off != 0 && (off & IP_FW_PORT_DYNT_FLAG) == 0) { - struct mbuf *clone; - - /* Clone packet if we're doing a 'tee' */ - if ((off & IP_FW_PORT_TEE_FLAG) != 0) - clone = divert_clone(m); - else - clone = NULL; - /* * XXX * delayed checksums are not currently compatible @@ -807,11 +812,14 @@ /* Deliver packet to divert input routine */ divert_packet(m, 0); - /* If 'tee', continue with original packet */ + /* + * If 'tee', continue processing firewall + * rules with the original packet + */ if (clone != NULL) { - m = clone; - ip = mtod(m, struct ip *); - goto pass; + args.m = clone; + args.tee_continue = 1; + goto tee_again; } goto done; } From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 16 10:17:44 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFF7916A4CF for ; Tue, 16 Mar 2004 10:17:43 -0800 (PST) Received: from mail3.firstlink.com (mail3.firstlink.com [66.37.141.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDA1543D2D for ; Tue, 16 Mar 2004 10:17:43 -0800 (PST) (envelope-from dvm@firstlink.com) Received: from jackstraw (66-37-143-139.corp.firstlink.com [66.37.143.139]) by mail3.firstlink.com (Postfix) with ESMTP id C041AE1695; Tue, 16 Mar 2004 11:17:42 -0700 (MST) From: Dan Vande More To: Tony Frank In-Reply-To: <20040316123848.GA89792@marvin.home.local> References: <1079113870.1238.8.camel@dvmgentoo> <1079366908.1274.5.camel@dvmgentoo> <20040316123848.GA89792@marvin.home.local> Content-Type: text/plain Message-Id: <1079461045.1240.315.camel@dvmgentoo> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Tue, 16 Mar 2004 11:17:25 -0700 Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@freebsd.org Subject: Re: transparent squid bridge X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dvm@firstlink.com List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2004 18:17:44 -0000 On Tue, 2004-03-16 at 05:38, Tony Frank wrote: > Hi there, > > On Mon, Mar 15, 2004 at 09:08:28AM -0700, Dan Vande More wrote: > > /*Repost, does anyone have an answer?*/ > > Maybe, see below. > > > Ok, to show I did try here's my diff on the manual patching. I've triple > > checked my work, and everything appears to be the way it is supposed to > > be. > > Your diff looks ok, though I only took a cursury look at it. > Are you running with 'options BRIDGE' in your kernel or loading bridge module? > Are you using ipfw2 or ipfw1 ? Options bridge is on, I am using ipfw2 / 5.2.1 Well ok, here comes the dumb part. If I'm using 5.2.1, it's using ipfw2 by default right? I don't need to do anything special to use it, is what I read. (And ipfw2 is not a kernel option like it is in 4.x) I've googled six ways from sunday and don't see how to check with version I'm using. ipfw -v/ipfw --version/strings /sbin/ipfw doesn't work/reveal anything. > > > I don't see the expected behavior, if anyone sees anything wrong, I > > would appreciate some input. > > I wonder if you are expecting something other than the behaviour this > gives? Yeah, it says it diverted the packet, but it doesn't show up at the machine it was diverted to. > > > Although the counter increases on rule 400 when a client requests a > > webpage on the other side of the bridge, a 'tcpdump port 80' on > > {proxy_server_ip_address} sees no packets whatsoever. > > > A tcpdump on the bridge server (tcpdump -n port 80) shows the packets > > from the client going straight to the requested host, instead of being > > hijacked and sent to the proxy server. > > Is your proxy and your bridge on the same system? > If it is, perhaps try building the setup with two separate servers to > make things a bit clearer. > Either setup seemed to work for me. Yeah, they are different servers, for the sake of simplicity. Once I get this working, I intend to experiment with keeping them on the same server. By saying either worked for your, are you saying that you have this working? > > Note: > The traffic that is 'captured' will not be rewritten to have a new destination > IP address. > Rather that traffic is instead sent to the new destination directly. > It is up to the destination to 'recognise' this traffic and treat it > appropriately. > If the hosts are on separate servers you should see 'uncaptured' traffic > being sent on to the default gateway (check ethernet link headers with -E option > to tcpdump) and 'captured' traffic being sent to the proxy server. > This is where it helps to have separate box for each function to clearly > see the ethernet headers being different. > It doesn't look like you have it enabled but should I have net.inet.ip.check_interface=0 on? I know I need it when I run dsr on my load balanced mail servers, because they need to accept packets destined for another ip. > >From luigi's original post: > > >on bridge: > >sysctl net.link.ether.bridge_cfg="rl0 rl1" > >sysctl net.link.ether.bridge_ipfw=1 > >sysctl net.link.ether.bridge=1 > >sysctl net.inet.ip.forwarding=1 > >ipfw add forward proxy proto tcp from any to any 80 > > > >on proxy: > >ipfw add forward localhost,8080 tcp from not me to any 80 > > Note this second ipfw line on the proxy itself. > It needs to be configured to redirect the traffic to the proxy software > port otherwise the server might well forward the traffic someplace > else (like to a default next-hop) > > This setup works for me in that the tcp connection to port 80 is > intercepted and sent to the local bridge/squid system, however my > squid currently returns an error due to 'invalid URL' or similar. > > Basically it seems the URL hostname is not seen by squid. > I'm running 2.4.STABLE7 and did not configure anything new in squid. > That aside, the point is the redirecting of traffic from a bridge is working > with these patches and FreeBSD 4.9-STABLE cvsupped today. > > If I have the fwd line in ipfw I get a squid error page on by client > browser. > If I stop squid I get a browser error due to TCP reset being received > as nothing is listening on the proxy for the traffic. So you got past the ipfw stuff, and now you can't get squid working? Did you try --enable-ipf-transparent in the configure? How about httpd_accel_uses_host_header on in the conf? I have that setup working on openbsd, works perfect. But openbsd doesn't:( (Can't handle the load) > > > > ************************************* > > bash-2.05b# egrep -v "^#" /etc/sysctl.conf > > sysctl net.link.ether.bridge_cfg='xl0 dc0' > > sysctl net.link.ether.bridge_ipfw=1 > > sysctl net.link.ether.bridge=1 > > sysctl net.inet.ip.forwarding=1 > > ************************************* > > Umm, is this really what you're using? > Yeah but the 3rd one is wrong, with 5.2 it appears it's: sysctl net.link.ether.bridge.enable=1 (Which is what I used, I just forgot to include it above.) > Perhaps check that all these options applied by running sysctl manually? > > My sysctl.conf looks like this: > %%% > net.link.ether.bridge_cfg="fxp0 fxp2" > net.link.ether.bridge_ipfw=1 > net.link.ether.bridge=1 > %%% > > And if I run sysctl manually I get: > > midway [298] [11:30pm] [/var/log/squid]# sysctl net.link.ether > net.link.ether.inet.prune_intvl: 300 > net.link.ether.inet.max_age: 1200 > net.link.ether.inet.host_down_time: 20 > net.link.ether.inet.maxtries: 5 > net.link.ether.inet.useloopback: 1 > net.link.ether.inet.proxyall: 0 > net.link.ether.inet.log_arp_wrong_iface: 1 > net.link.ether.inet.log_arp_movements: 1 > net.link.ether.bridge_cfg: fxp0 fxp2 > net.link.ether.bridge: 1 > net.link.ether.bridge_ipfw: 1 > net.link.ether.bridge_ipf: 0 > net.link.ether.bridge_ipfw_drop: 0 > net.link.ether.bridge_ipfw_collisions: 0 > net.link.ether.verbose: 0 > net.link.ether.bdg_split_pkts: 0 > net.link.ether.bdg_thru: 11580 > net.link.ether.bdg_copied: 0 > net.link.ether.bdg_copy: 0 > net.link.ether.bdg_predict: 11351 > net.link.ether.bdg_fw_avg: 0 > net.link.ether.bdg_fw_ticks: 0 > net.link.ether.bdg_fw_count: 0 > net.link.ether.ipfw: 0 > Everything looks exactly the same minus the number of "net.link.ether.bdg_predict", but I assume that's related to packets going in and out. Mines 180. > > > > ************************************** > > bash-2.05b# ipfw show > > 00100 56 2920 allow ip from any to any via lo0 > > 00200 0 0 deny ip from any to 127.0.0.0/8 > > 00300 0 0 deny ip from 127.0.0.0/8 to any > > 00400 21 1078 fwd {proxy_server_ip_address} tcp from any to any > > dst-port 80 > > 65000 19137 2942276 allow ip from any to any > > 65535 0 0 deny ip from any to any > > ************************************** > > Looks ok,but check the fwd rule - here's my setup: > > midway [297] [11:29pm] [/var/log/squid]# ipfw show > 00010 46 3439 skipto 20000 ip from any to any layer2 > 00100 12 2122 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 01000 16 2202 allow ip from any to any > 20000 46 3439 count log ip from any to any > 20010 5 497 fwd 127.0.0.1,3128 tcp from any to any dst-port 80 > 20011 41 2942 count log ip from any to any > 20012 41 2942 allow ip from any to any > 65000 0 0 deny log ip from any to any > 65535 0 0 deny ip from any to any > What do you mean check the fwd rule, it looks the same, minus your rule 10. (which I'm gonna try) > I have squid listening on 127.0.0.1 port 3128. > I also got it working using a second server, albeit with the error > listed above (which is squid configuration, not ipfw) > > Hope it helps, > > Regards, > > Tony Thank you Tony, you've been a big help, considering I still didn't even know if this had been done by anybody but Mr. Rizzo. In your opinion, is it better for me to try this on 4.9? Thanks! Dan Vande More From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 16 18:19:22 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 502D316A4CE for ; Tue, 16 Mar 2004 18:19:22 -0800 (PST) Received: from mx01.bos.ma.towardex.com (a65-124-16-8.svc.towardex.com [65.124.16.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAB6A43D39 for ; Tue, 16 Mar 2004 18:19:21 -0800 (PST) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id 1104C2F906; Tue, 16 Mar 2004 21:19:29 -0500 (EST) Date: Tue, 16 Mar 2004 21:19:29 -0500 From: James To: Nicolas DEFFAYET Message-ID: <20040317021928.GA26065@scylla.towardex.com> References: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com> User-Agent: Mutt/1.4.1i cc: freebsd-ipfw@freebsd.org Subject: Re: Latency problem with traffic shaping X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 02:19:22 -0000 ohhh... you are concerned about simple 1ms difference due to granuality (sp) in 35 meg pipe, right? this is a simple problem to fix: ipfw add 1 allow icmp from any to any icmptypes 11,0,8 ipfw add 1 allow udp from any to any 33434-33534 < then insert your pipe rules > and also, you realize that you are putting people on vlan3 to a half duplex pipe right? -J On Sat, Mar 06, 2004 at 07:29:05PM +0100, Nicolas DEFFAYET wrote: > Hello, > > I have latency problem when i do traffic shaping with ipfw: > > $ ping -c 10 xxx.xxx.xx1.2 > PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes > 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=1.037 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=1.951 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=1.924 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=1.852 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=2.779 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=1.982 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=1.778 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=1.866 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=1.777 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=1.876 ms > > --- xxx.xxx.xx1.2 ping statistics --- > 10 packets transmitted, 10 packets received, 0% packet loss > round-trip min/avg/max/stddev = 1.037/1.882/2.779/0.395 ms > > Current maximum traffic is 6 Mbit/s, shapping is at 35 Mbit/s. > > > I use a vlan interface but i have same problem with a physical > interface: > > $ ifconfig vlan3 > vlan3: flags=8843 mtu 1500 > inet xxx.xxx.xx1.1 netmask 0xfffffffc broadcast xxx.xxx.xx1.3 > > > > I use very simple rules: > > # ipfw sh > 03000 195958827 88359539155 pipe 1 ip from any to any out via vlan3 > 03000 145717180 37638278479 pipe 1 ip from any to any in via vlan3 > 65535 7732545351 2700054229295 allow ip from any to any > > # ipfw pipe sh > 00001: 35.000 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail > mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000 > BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes > Pkt/Byte Drp > 0 igmp xxx.xxx.xx1.1/0 224.0.0.5/0 341678025 > 125998357178 0 0 295 > > > If the rule 3000 of ipfw is deleted, latency is good and normal; but i > don't have shaping: > > $ ping -c 10 xxx.xxx.xx1.2 > PING xxx.xxx.xx1.2 (xxx.xxx.xx1.2): 56 data bytes > 64 bytes from xxx.xxx.xx1.2: icmp_seq=0 ttl=64 time=0.375 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=1 ttl=64 time=0.219 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=2 ttl=64 time=0.251 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=3 ttl=64 time=0.281 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=4 ttl=64 time=0.290 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=5 ttl=64 time=0.308 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=6 ttl=64 time=0.380 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=7 ttl=64 time=0.254 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=8 ttl=64 time=0.227 ms > 64 bytes from xxx.xxx.xx1.2: icmp_seq=9 ttl=64 time=0.227 ms > > --- xxx.xxx.xx1.2 ping statistics --- > 10 packets transmitted, 10 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.219/0.281/0.380/0.055 ms > > > I don't have the problem with FreeBSD 5.0-RELEASE. > I have the problem with FreeBSD 5.1-RELEASE, FreeBSD 5.2-RELEASE, > FreeBSD 5.2.1-RELEASE. > > I use a custom kernel with: > > options IPFIREWALL #firewall > options IPFIREWALL_VERBOSE #enable logging to syslogd(8) > options IPFIREWALL_FORWARD #enable transparent proxy > support > options IPFIREWALL_VERBOSE_LIMIT=100 #limit verbosity > options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by > default > options IPV6FIREWALL #firewall for IPv6 > options IPV6FIREWALL_VERBOSE > options IPV6FIREWALL_VERBOSE_LIMIT=100 > options IPV6FIREWALL_DEFAULT_TO_ACCEPT > options IPDIVERT #divert sockets > options DUMMYNET > options BRIDGE > > > How fix this latency problem ? > > > Thanks > > Best regards, > > -- > Nicolas DEFFAYET, NDSoftware > NDSoftware IP Network: http://www.ip.ndsoftware.net/ > FNIX6 (French National Internet Exchange IPv6): http://www.fnix6.net/ > > _______________________________________________ > 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" -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net From owner-freebsd-ipfw@FreeBSD.ORG Tue Mar 16 21:58:09 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0010E16A4CE for ; Tue, 16 Mar 2004 21:58:08 -0800 (PST) Received: from bsd1.hostthecoast.org (dsl-230-142.ipns.com [209.210.230.142]) by mx1.FreeBSD.org (Postfix) with SMTP id 5A23043D41 for ; Tue, 16 Mar 2004 21:58:08 -0800 (PST) (envelope-from jtd@hostthecoast.org) Received: (qmail 60244 invoked from network); 17 Mar 2004 05:59:21 -0000 Received: from unknown (HELO host1) (10.2.1.51) by bsd1.hostthecoast.org with SMTP; 17 Mar 2004 05:59:21 -0000 Message-ID: <002701c40be5$43298f70$3301020a@hostthecaost.org> From: "J.T. Davies" To: References: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com> <20040317021928.GA26065@scylla.towardex.com> Date: Tue, 16 Mar 2004 22:01:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Internal routing to different gateway X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 05:58:09 -0000 Hello everyone (again), I've come up with a brainstorm. My situation is this: I have an internal mail server running qmail on FreeBSD (ip of 10.2.1.52). I have two gateway/routers:: Internal IP's of 10.2.1.1 and 10.2.1.2, each has their own external IP's. The mail server (10.2.1.52) has a default_router set as 10.2.1.1. However, traffic coming in from 10.2.1.2 is answered via 10.2.1.1 (and not going back out the original route of 10.2.1.2). Of course this doesn't work because the NAT tables don't sync up between the two, so 10.2.1.1 doesn't know where to route the reply traffic. Incoming traffic on 10.2.1.1 works very well. Here's my potential solution...please tell me if there's a better way (through another port) or if I'm on a good track. ========== I create an IP alias on the mail server (10.2.1.53) and create routes in natd on 10.2.1.2 to route SMTP and POP3 traffic to the new alias IP. I enable IPFW on the mail server (defaults to allow connections because it's internal). I'll add two rules: ipfw add fwd 10.2.1.2 from 10.2.1.53 to any out via vr0 ipfw add fwd 10.2.1.1 from 10.2.1.52 to any out via vr0 (I think the syntax of the rules are right...if not, I'll experiment to perfect them) ========== Thoughts? J.T. From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 17 04:55:52 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE4D416A4CF for ; Wed, 17 Mar 2004 04:55:52 -0800 (PST) Received: from mail014.syd.optusnet.com.au (mail014.syd.optusnet.com.au [211.29.132.160]) by mx1.FreeBSD.org (Postfix) with ESMTP id B825443D31 for ; Wed, 17 Mar 2004 04:55:51 -0800 (PST) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-241-126.eburwd5.vic.optusnet.com.au [211.28.241.126])i2HCtjF16842; Wed, 17 Mar 2004 23:55:46 +1100 Received: by marvin.home.local (Postfix, from userid 1001) id D0DE51FB81; Wed, 17 Mar 2004 23:55:44 +1100 (EST) Date: Wed, 17 Mar 2004 23:55:44 +1100 From: Tony Frank To: Dan Vande More Message-ID: <20040317125544.GA30730@marvin.home.local> References: <1079113870.1238.8.camel@dvmgentoo> <1079114684.1240.22.camel@dvmgentoo> <1079366908.1274.5.camel@dvmgentoo> <20040316123848.GA89792@marvin.home.local> <1079461045.1240.315.camel@dvmgentoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079461045.1240.315.camel@dvmgentoo> User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw@freebsd.org Subject: Re: transparent squid bridge X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 12:55:52 -0000 Hi, On Tue, Mar 16, 2004 at 11:17:25AM -0700, Dan Vande More wrote: > On Tue, 2004-03-16 at 05:38, Tony Frank wrote: > > On Mon, Mar 15, 2004 at 09:08:28AM -0700, Dan Vande More wrote: > > > Ok, to show I did try here's my diff on the manual patching. I've triple > > > checked my work, and everything appears to be the way it is supposed to > > > be. > > > > Your diff looks ok, though I only took a cursury look at it. > > Are you running with 'options BRIDGE' in your kernel or loading bridge module? > > Are you using ipfw2 or ipfw1 ? > > Options bridge is on, I am using ipfw2 / 5.2.1 > > Well ok, here comes the dumb part. > > If I'm using 5.2.1, it's using ipfw2 by default right? I don't need to > do anything special to use it, is what I read. (And ipfw2 is not a > kernel option like it is in 4.x) > I've googled six ways from sunday and don't see how to check with > version I'm using. > ipfw -v/ipfw --version/strings /sbin/ipfw doesn't work/reveal anything. > For me, I get the following at bootup (refer dmesg.boot): DUMMYNET initialized (011031) bpf: lo0 attached ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to deny, logging unlimited IPsec: Initialized Security Association Processing. > > > Although the counter increases on rule 400 when a client requests a > > > webpage on the other side of the bridge, a 'tcpdump port 80' on > > > {proxy_server_ip_address} sees no packets whatsoever. > > > > > A tcpdump on the bridge server (tcpdump -n port 80) shows the packets > > > from the client going straight to the requested host, instead of being > > > hijacked and sent to the proxy server. > > > > Is your proxy and your bridge on the same system? > > If it is, perhaps try building the setup with two separate servers to > > make things a bit clearer. > > Either setup seemed to work for me. > > Yeah, they are different servers, for the sake of simplicity. Once I get > this working, I intend to experiment with keeping them on the same > server. > By saying either worked for your, are you saying that you have this > working? Well, the divert parts seemed to work - as already mentioned the squid part did not do so well, but that was not my immediate goal. > > Note: > > The traffic that is 'captured' will not be rewritten to have a new destination > > IP address. > > Rather that traffic is instead sent to the new destination directly. > > It is up to the destination to 'recognise' this traffic and treat it > > appropriately. > > If the hosts are on separate servers you should see 'uncaptured' traffic > > being sent on to the default gateway (check ethernet link headers with -E option > > to tcpdump) and 'captured' traffic being sent to the proxy server. > > This is where it helps to have separate box for each function to clearly > > see the ethernet headers being different. > > > > It doesn't look like you have it enabled but should I have > > net.inet.ip.check_interface=0 > > on? I know I need it when I run dsr on my load balanced mail servers, > because they need to accept packets destined for another ip. Based on my understanding, this has no effect in this scenario, comment from ip_input.c regarding this check: * Enable a consistency check between the destination address * and the arrival interface for a unicast packet (the RFC 1122 * strong ES model) if IP forwarding is disabled and the packet * is not locally generated and the packet is not subject to * 'ipfw fwd'. In my case ip forwarding is enabled, hence I believe this check is bypassed. > > >From luigi's original post: > > > > >on bridge: > > >sysctl net.link.ether.bridge_cfg="rl0 rl1" > > >sysctl net.link.ether.bridge_ipfw=1 > > >sysctl net.link.ether.bridge=1 > > >sysctl net.inet.ip.forwarding=1 > > >ipfw add forward proxy proto tcp from any to any 80 > > > > > >on proxy: > > >ipfw add forward localhost,8080 tcp from not me to any 80 > > > > Note this second ipfw line on the proxy itself. > > It needs to be configured to redirect the traffic to the proxy software > > port otherwise the server might well forward the traffic someplace > > else (like to a default next-hop) > > > > This setup works for me in that the tcp connection to port 80 is > > intercepted and sent to the local bridge/squid system, however my > > squid currently returns an error due to 'invalid URL' or similar. > > > > Basically it seems the URL hostname is not seen by squid. > > I'm running 2.4.STABLE7 and did not configure anything new in squid. > > That aside, the point is the redirecting of traffic from a bridge is working > > with these patches and FreeBSD 4.9-STABLE cvsupped today. > > > > If I have the fwd line in ipfw I get a squid error page on by client > > browser. > > If I stop squid I get a browser error due to TCP reset being received > > as nothing is listening on the proxy for the traffic. > > So you got past the ipfw stuff, and now you can't get squid working? > > Did you try --enable-ipf-transparent in the configure? No > How about httpd_accel_uses_host_header on in the conf? I did try this option but it did not appear to have an impact. > I have that setup working on openbsd, works perfect. But openbsd > doesn't:( (Can't handle the load) A quick read of http://www.squid-cache.org/Doc/FAQ/FAQ-17.html sorted me out. I didn't need the --enable-ipf-transparent just the httpd_accel lines. ie: http_port localhost:3128 httpd_accel_port 80 httpd_accel_host virtual httpd_accel_with_proxy on httpd_accel_uses_host_header on My version: Starting Squid Cache version 2.4.STABLE7 for i386-portbld-freebsd4.6. Not sure if it was built with any transparent options. (whatever was in the ports makefile at the time) I've also updated my squid to: Squid Cache: Version 2.5.STABLE4 configure options: --bindir=/usr/local/sbin --sysconfdir=/usr/local/etc/squid --datadir=/usr/local/etc/squid --libexecdir=/usr/local/libexec/squid --localstatedir=/usr/local/squid '--enable-storeio=ufs diskd null' '--enable-removal-policies=lru heap' '--enable-auth=basic ntlm digest' '--enable-basic-auth-helpers=NCSA PAM YP MSNT winbind' --enable-digest-auth-helpers=password '--enable-external-acl-helpers=ip_user unix_group wbinfo_group winbind_group' '--enable-ntlm-auth-helpers=SMB winbind' --enable-delay-pools --enable-snmp --disable-wccp --enable-underscores --enable-useragent-log --enable-arp-acl '--enable-err-languages=Bulgarian Catalan Czech Danish Dutch English Estonian Finnish French German Hebrew Hungarian Italian Japanese Korean Lithuanian Polish Portuguese Romanian Russian-1251 Russian-koi8-r Serbian Simplify_Chinese Slovak Spanish Swedish Traditional_Chinese Turkish' --enable-default-err-language=English --prefix=/usr/local i386-portbld-freebsd4.9 > > > ************************************* > > > bash-2.05b# egrep -v "^#" /etc/sysctl.conf > > > sysctl net.link.ether.bridge_cfg='xl0 dc0' > > > sysctl net.link.ether.bridge_ipfw=1 > > > sysctl net.link.ether.bridge=1 > > > sysctl net.inet.ip.forwarding=1 > > > ************************************* > > > > Umm, is this really what you're using? > > > Yeah but the 3rd one is wrong, with 5.2 it appears it's: > > sysctl net.link.ether.bridge.enable=1 > > (Which is what I used, I just forgot to include it above.) Some things have obviously changed 4.9 <-> 5.2 > > I have squid listening on 127.0.0.1 port 3128. > > I also got it working using a second server, albeit with the error > > listed above (which is squid configuration, not ipfw) > Thank you Tony, you've been a big help, considering I still didn't even > know if this had been done by anybody but Mr. Rizzo. I dont have a present need for this in bridging environment, just thought I'd have a crack at it since I have the bits all together at the moment. > In your opinion, is it better for me to try this on 4.9? > :) Works for me on 4.9-STABLE (plus patches) I might try 5.2.1 as well, will advise what happens. Regards, Tony From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 17 07:33:26 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D56B616A4CE for ; Wed, 17 Mar 2004 07:33:26 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4EDD043D39 for ; Wed, 17 Mar 2004 07:33:26 -0800 (PST) (envelope-from turbo23@gmx.net) Received: (qmail 10963 invoked by uid 65534); 17 Mar 2004 15:33:24 -0000 Received: from 253.catv107.lgt01.lan.ch (EHLO gmx.net) (62.204.107.253) by mail.gmx.net (mp010) with SMTP; 17 Mar 2004 16:33:24 +0100 X-Authenticated: #627573 Message-ID: <4058710F.4060608@gmx.net> Date: Wed, 17 Mar 2004 16:38:55 +0100 From: Thomas Vogt User-Agent: Mozilla Thunderbird 0.5b (Windows/20040215) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: layer7 filter? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 15:33:26 -0000 Hi Any plans to implement a OSI layer7 filter into ipfw? Or is there already a project for fbsd? I only know http://l7-filter.sourceforge.net/ but it's linux only. cheers, thomas vogt From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 17 09:23:43 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1029616A4CF for ; Wed, 17 Mar 2004 09:23:43 -0800 (PST) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3ECE43D45 for ; Wed, 17 Mar 2004 09:23:42 -0800 (PST) (envelope-from cswiger@mac.com) Received: from mac.com ([68.161.120.219]) by out011.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040317172342.FBDM18566.out011.verizon.net@mac.com>; Wed, 17 Mar 2004 11:23:42 -0600 Message-ID: <40588915.1040905@mac.com> Date: Wed, 17 Mar 2004 12:21:25 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Vogt References: <4058710F.4060608@gmx.net> In-Reply-To: <4058710F.4060608@gmx.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out011.verizon.net from [68.161.120.219] at Wed, 17 Mar 2004 11:23:41 -0600 cc: freebsd-ipfw@freebsd.org Subject: Re: layer7 filter? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 17:23:43 -0000 Thomas Vogt wrote: > Any plans to implement a OSI layer7 filter into ipfw? Or is there > already a project for fbsd? I only know > http://l7-filter.sourceforge.net/ but it's linux only. The divert mechanism already present in IPFW can be used in conjuction with application-specific proxies to perform layer-7 filtering. For example, consider diverting outbound connections to port 80 to a Squid cache, for example, which might also perform authentication, filtering by URL, or other HTTP-protocol-specific stuff. -- -Chuck From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 17 10:07:57 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 473A616A4CE for ; Wed, 17 Mar 2004 10:07:57 -0800 (PST) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 74D8A43D1F for ; Wed, 17 Mar 2004 10:07:56 -0800 (PST) (envelope-from turbo23@gmx.net) Received: (qmail 7592 invoked by uid 65534); 17 Mar 2004 18:07:55 -0000 Received: from 253.catv107.lgt01.lan.ch (EHLO gmx.net) (62.204.107.253) by mail.gmx.net (mp027) with SMTP; 17 Mar 2004 19:07:55 +0100 X-Authenticated: #627573 Message-ID: <40589524.60801@gmx.net> Date: Wed, 17 Mar 2004 19:12:52 +0100 From: Thomas Vogt User-Agent: Mozilla Thunderbird 0.5b (Windows/20040215) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger References: <4058710F.4060608@gmx.net> <40588915.1040905@mac.com> In-Reply-To: <40588915.1040905@mac.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-ipfw@freebsd.org Subject: Re: layer7 filter? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 18:07:57 -0000 Hi Chuck Yes, but as far as I know, divert is slow. It's not usable in enviroments with >=100mbit. But I'm glad if you can show me that this not true :) regards, Thomas Chuck Swiger wrote: > Thomas Vogt wrote: > >> Any plans to implement a OSI layer7 filter into ipfw? Or is there >> already a project for fbsd? I only know >> http://l7-filter.sourceforge.net/ but it's linux only. > > > The divert mechanism already present in IPFW can be used in conjuction > with application-specific proxies to perform layer-7 filtering. For > example, consider diverting outbound connections to port 80 to a Squid > cache, for example, which might also perform authentication, filtering > by URL, or other HTTP-protocol-specific stuff. > From owner-freebsd-ipfw@FreeBSD.ORG Wed Mar 17 15:08:35 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 380DA16A4CE; Wed, 17 Mar 2004 15:08:35 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A3F143D1D; Wed, 17 Mar 2004 15:08:35 -0800 (PST) (envelope-from kris@FreeBSD.org) Received: from freefall.freebsd.org (kris@localhost [127.0.0.1]) i2HN8Ybv079241; Wed, 17 Mar 2004 15:08:34 -0800 (PST) (envelope-from kris@freefall.freebsd.org) Received: (from kris@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i2HN8YNb079237; Wed, 17 Mar 2004 15:08:34 -0800 (PST) (envelope-from kris) Date: Wed, 17 Mar 2004 15:08:34 -0800 (PST) From: Kris Kennaway Message-Id: <200403172308.i2HN8YNb079237@freefall.freebsd.org> To: kris@FreeBSD.org, freebsd-bugs@FreeBSD.org, ipfw@FreeBSD.org Subject: Re: kern/64345: 4.x IPFW2 kernel memory leak (IPFW2+rote flaps+verrevpath) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2004 23:08:35 -0000 Synopsis: 4.x IPFW2 kernel memory leak (IPFW2+rote flaps+verrevpath) Responsible-Changed-From-To: freebsd-bugs->ipfw Responsible-Changed-By: kris Responsible-Changed-When: Wed Mar 17 15:08:15 PST 2004 Responsible-Changed-Why: Assign to ipfw mailing list http://www.freebsd.org/cgi/query-pr.cgi?pr=64345 From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 02:32:35 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B762416A4CF for ; Thu, 18 Mar 2004 02:32:35 -0800 (PST) Received: from mail019.syd.optusnet.com.au (mail019.syd.optusnet.com.au [211.29.132.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13CC843D46 for ; Thu, 18 Mar 2004 02:32:30 -0800 (PST) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-241-126.eburwd5.vic.optusnet.com.au [211.28.241.126])i2IAW4B28473; Thu, 18 Mar 2004 21:32:14 +1100 Received: by marvin.home.local (Postfix, from userid 1001) id 4600A1FB81; Thu, 18 Mar 2004 21:32:00 +1100 (EST) Date: Thu, 18 Mar 2004 21:32:00 +1100 From: Tony Frank To: "J.T. Davies" Message-ID: <20040318103200.GA49704@marvin.home.local> References: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com> <20040317021928.GA26065@scylla.towardex.com> <002701c40be5$43298f70$3301020a@hostthecaost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002701c40be5$43298f70$3301020a@hostthecaost.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw@freebsd.org Subject: Re: Internal routing to different gateway X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 10:32:35 -0000 Hi there, On Tue, Mar 16, 2004 at 10:01:17PM -0800, J.T. Davies wrote: > I have an internal mail server running qmail on FreeBSD (ip of 10.2.1.52). > > I have two gateway/routers:: > Internal IP's of 10.2.1.1 and 10.2.1.2, each has their own external IP's. > > The mail server (10.2.1.52) has a default_router set as 10.2.1.1. > > However, traffic coming in from 10.2.1.2 is answered via 10.2.1.1 (and not > going back out the original route of 10.2.1.2). > > Of course this doesn't work because the NAT tables don't sync up between the > two, so 10.2.1.1 doesn't know where to route the reply traffic. > > Incoming traffic on 10.2.1.1 works very well. > > Here's my potential solution...please tell me if there's a better way > (through another port) or if I'm on a good track. > > ========== > I create an IP alias on the mail server (10.2.1.53) and create routes in > natd on 10.2.1.2 to route SMTP and POP3 traffic to the new alias IP. > > I enable IPFW on the mail server (defaults to allow connections because it's > internal). > > I'll add two rules: > ipfw add fwd 10.2.1.2 from 10.2.1.53 to any out via vr0 > ipfw add fwd 10.2.1.1 from 10.2.1.52 to any out via vr0 > (I think the syntax of the rules are right...if not, I'll experiment to > perfect them) > ========== > > Thoughts? I just (last week or so) posted a reply (on -net or -isp I think) that did this kind of things for a webserver setup with alternate upstream sources. The setup was a bit different to what you describe in that there was one 'router' with two uplinks rather than two separate routers. In that case I needed to use the natd redirection feature to proxy traffic to the alias address. Your routers will need to be able to rewrite the traffic in some way to do this (ie change the destination IP to 10.2.1.53) As it is application layer, a regular IP route is probably not sufficient. Another option is to 'reverse NAT' on the routers so the traffic to 10.2.1.52 appears to originate from 10.2.1.1 or 10.2.1.2. Then your server will reply to the appropriate address and the NAT on the router should send the result to the original client. I guess this will depend a little on the application and how well it can handle NAT; SMTP and POP3 should be fine as long as you're not trying to do source-ip based filtering. (unless you do that on the routers before they nat/proxy the traffic) Hope it helps, Tony From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 02:57:30 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA51516A4CE; Thu, 18 Mar 2004 02:57:30 -0800 (PST) Received: from u1030.c03.escapebox.net (gen045.n002.c03.escapebox.net [213.73.82.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 708E743D41; Thu, 18 Mar 2004 02:57:30 -0800 (PST) (envelope-from francis@u1030.c03.escapebox.net) Received: from francis by u1030.c03.escapebox.net with local (Exim 3.36 #1) id 1B3vDM-0006Be-00; Thu, 18 Mar 2004 11:57:28 +0100 Date: Thu, 18 Mar 2004 11:57:28 +0100 From: Francis GUDIN To: freebsd-questions@freebsd.org Message-ID: <20040318105728.GA2470@u1030.c03.escapebox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw@freebsd.org Subject: dummynet and adsl X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 10:57:31 -0000 Hello everybody, I'm in the process of setting up a bandwidth control with ipfw and dummynet. My connection is done through pppoe on adsl. In ipfw(8), i found the following: "If a device name is specified instead of a numeric value, as in ipfw pipe 1 config bw tun0 then the transmit clock is supplied by the specified device. At the moment only the tun(4) device supports this functionality, for use in conjunction with ppp(8)." Having two different bandwidth available (up- and downstream), would this option work ? Or, is only symetric bw case taken into account when using this syntax ? Any help greatly appreciated. Please cc: in your replies as i'm not subscribed to these lists. Tnx, Francis. From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 03:30:36 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E76A16A4CE for ; Thu, 18 Mar 2004 03:30:36 -0800 (PST) Received: from deliver.epitech.net (deliver.epitech.net [163.5.0.25]) by mx1.FreeBSD.org (Postfix) with SMTP id C34A843D39 for ; Thu, 18 Mar 2004 03:30:35 -0800 (PST) (envelope-from le-hen_j@epita.fr) Received: from epita.fr ([10.42.1.60]) by deliver.epitech.net (SAVSMTP 3.1.2.35) with SMTP id M2004031812274715482 ; Thu, 18 Mar 2004 12:27:47 +0100 Received: from annelo (annelo.epita.fr [10.42.120.68]) by epita.fr id i2IBUXM08572 Thu, 18 Mar 2004 12:30:33 +0100 (CET) Date: Thu, 18 Mar 2004 12:30:33 +0100 From: jeremie le-hen To: Thomas Vogt Message-ID: <20040318113033.GB5536@annelo.epita.fr> References: <4058710F.4060608@gmx.net> <40588915.1040905@mac.com> <40589524.60801@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40589524.60801@gmx.net> User-Agent: Mutt/1.4i cc: freebsd-ipfw@freebsd.org cc: Chuck Swiger Subject: Re: layer7 filter? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 11:30:36 -0000 > Yes, but as far as I know, divert is slow. It's not usable in > enviroments with >=100mbit. But I'm glad if you can show me that this > not true :) On the other hand, layer 7-filtering is not what we can call a fast match method against network traffic. AFAIK "L7-filter" for NetFilter is based on regular expressions, and matching even a simple re against every packet in a 100MBits environnement would be rather expensive. -- Jeremie LE HEN aka TtZ/TataZ jeremie.le-hen@epita.fr ttz@epita.fr Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 05:37:46 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D3AC16A4CE for ; Thu, 18 Mar 2004 05:37:46 -0800 (PST) Received: from mail.hostthecoast.org (dsl-230-142.ipns.com [209.210.230.142]) by mx1.FreeBSD.org (Postfix) with SMTP id 7274443D66 for ; Thu, 18 Mar 2004 05:37:43 -0800 (PST) (envelope-from jtd@hostthecoast.org) Received: (qmail 4709 invoked from network); 18 Mar 2004 13:38:12 -0000 Received: from unknown (HELO host1) (10.2.1.51) by mail.hostthecoast.org with SMTP; 18 Mar 2004 13:38:12 -0000 Message-ID: <003601c40cee$9decfb40$3301020a@hostthecaost.org> From: "J.T. Davies" To: References: <1078597745.1981.15.camel@w1-par1-fr.corp.ndsoftware.com><20040317021928.GA26065@scylla.towardex.com><002701c40be5$43298f70$3301020a@hostthecaost.org> <20040318103200.GA49704@marvin.home.local> Date: Thu, 18 Mar 2004 05:40:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: Internal routing to different gateway X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 13:37:46 -0000 > Hi there, > > On Tue, Mar 16, 2004 at 10:01:17PM -0800, J.T. Davies wrote: > > I have an internal mail server running qmail on FreeBSD (ip of 10.2.1.52). > > > > I have two gateway/routers:: > > Internal IP's of 10.2.1.1 and 10.2.1.2, each has their own external IP's. > > > > The mail server (10.2.1.52) has a default_router set as 10.2.1.1. > > > > However, traffic coming in from 10.2.1.2 is answered via 10.2.1.1 (and not > > going back out the original route of 10.2.1.2). > > > > Of course this doesn't work because the NAT tables don't sync up between the > > two, so 10.2.1.1 doesn't know where to route the reply traffic. > > > > Incoming traffic on 10.2.1.1 works very well. > > > > Here's my potential solution...please tell me if there's a better way > > (through another port) or if I'm on a good track. > > > > ========== > > I create an IP alias on the mail server (10.2.1.53) and create routes in > > natd on 10.2.1.2 to route SMTP and POP3 traffic to the new alias IP. > > > > I enable IPFW on the mail server (defaults to allow connections because it's > > internal). > > > > I'll add two rules: > > ipfw add fwd 10.2.1.2 from 10.2.1.53 to any out via vr0 > > ipfw add fwd 10.2.1.1 from 10.2.1.52 to any out via vr0 > > (I think the syntax of the rules are right...if not, I'll experiment to > > perfect them) > > ========== > > > > Thoughts? > > I just (last week or so) posted a reply (on -net or -isp I think) that did > this kind of things for a webserver setup with alternate upstream sources. > The setup was a bit different to what you describe in that there was one > 'router' with two uplinks rather than two separate routers. > In that case I needed to use the natd redirection feature to proxy traffic > to the alias address. > Your routers will need to be able to rewrite the traffic in some way to do this > (ie change the destination IP to 10.2.1.53) > As it is application layer, a regular IP route is probably not sufficient. > > Another option is to 'reverse NAT' on the routers so the traffic to 10.2.1.52 > appears to originate from 10.2.1.1 or 10.2.1.2. > Then your server will reply to the appropriate address and the NAT on the router > should send the result to the original client. > I guess this will depend a little on the application and how well it can handle > NAT; SMTP and POP3 should be fine as long as you're not trying to do source-ip > based filtering. (unless you do that on the routers before they nat/proxy the > traffic) > > Hope it helps, > > Tony Hi Tony, I saw your post (and a few people forwarded it to me). I did try to implement, but for some reason could not get it to work. Instead, I did this (which may not be the best option, but it works). Create an alias on the mail server of (10.2.1.53). Configure IPFW and create a rule to forward any traffic coming from 10.2.1.53 to the gateway at 10.2.1.2. Voila! It amazingly worked! Although, not too keen on having firewall rules on an internal box (the default is to accept, so any traffic coming in from internal networked machines would be able to communicate with it). Thanks! J.T. From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 08:08:49 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E859116A4CE; Thu, 18 Mar 2004 08:08:49 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9A5C43D41; Thu, 18 Mar 2004 08:08:49 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i2IG8nRS040891; Thu, 18 Mar 2004 08:08:49 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i2IG8nRm040890; Thu, 18 Mar 2004 08:08:49 -0800 (PST) (envelope-from rizzo) Date: Thu, 18 Mar 2004 08:08:49 -0800 From: Luigi Rizzo To: Francis GUDIN Message-ID: <20040318080849.A40631@xorpc.icir.org> References: <20040318105728.GA2470@u1030.c03.escapebox.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: <20040318105728.GA2470@u1030.c03.escapebox.net>; from francis@u1030.c03.escapebox.net on Thu, Mar 18, 2004 at 11:57:28AM +0100 cc: freebsd-ipfw@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: dummynet and adsl X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 16:08:50 -0000 On Thu, Mar 18, 2004 at 11:57:28AM +0100, Francis GUDIN wrote: > Hello everybody, > > I'm in the process of setting up a bandwidth control with ipfw and > dummynet. My connection is done through pppoe on adsl. > > In ipfw(8), i found the following: > "If a device name is specified instead of a numeric value, as in > > ipfw pipe 1 config bw tun0 > > then the transmit clock is supplied by the specified device. At > the moment only the tun(4) device supports this functionality, > for use in conjunction with ppp(8)." > > Having two different bandwidth available (up- and downstream), would > this option work ? Or, is only symetric bw case taken into account 'bw tun0' means that the pipe will transmit a new packet when the device's (tun0 in this case) transmit queue becomes empty. In any case the question is irrelevant here because tun0's queue is drained by the userland process reading from /dev/tun0 and writing onto the output link. With a serial line and no buffering you could hope that this matches the outbound bandwidth, but with pppoe on adsl you basically see the ethernet speed on transmission. cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 08:36:30 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88BF316A4CF; Thu, 18 Mar 2004 08:36:30 -0800 (PST) Received: from u1030.c03.escapebox.net (gen045.n002.c03.escapebox.net [213.73.82.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32F3043D3F; Thu, 18 Mar 2004 08:36:30 -0800 (PST) (envelope-from francis@u1030.c03.escapebox.net) Received: from francis by u1030.c03.escapebox.net with local (Exim 3.36 #1) id 1B40VL-000F8F-00; Thu, 18 Mar 2004 17:36:23 +0100 Date: Thu, 18 Mar 2004 17:36:23 +0100 From: Francis GUDIN To: Luigi Rizzo Message-ID: <20040318163623.GA56866@u1030.c03.escapebox.net> References: <20040318105728.GA2470@u1030.c03.escapebox.net> <20040318080849.A40631@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040318080849.A40631@xorpc.icir.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-ipfw@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: dummynet and adsl X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 16:36:30 -0000 On Thursday, 18 March 2004 at 8:08:49 -0800, Luigi Rizzo wrote : > On Thu, Mar 18, 2004 at 11:57:28AM +0100, Francis GUDIN wrote: > > Hello everybody, > > > > I'm in the process of setting up a bandwidth control with ipfw and > > dummynet. My connection is done through pppoe on adsl. > > > > In ipfw(8), i found the following: > > "If a device name is specified instead of a numeric value, as in > > > > ipfw pipe 1 config bw tun0 > > > > then the transmit clock is supplied by the specified device. At > > the moment only the tun(4) device supports this functionality, > > for use in conjunction with ppp(8)." > > > > Having two different bandwidth available (up- and downstream), would > > this option work ? Or, is only symetric bw case taken into account > > 'bw tun0' means that the pipe will transmit a new packet when > the device's (tun0 in this case) transmit queue becomes empty. > > In any case the question is irrelevant here because tun0's queue > is drained by the userland process reading from /dev/tun0 > and writing onto the output link. With a serial line and no > buffering you could hope that this matches the outbound > bandwidth, but with pppoe on adsl you basically see the > ethernet speed on transmission. > > cheers > luigi > Thank you ! Things are much clearer to me, now. Back to work ! BR, Francis. From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 10:18:56 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0DE0916A4CF for ; Thu, 18 Mar 2004 10:18:56 -0800 (PST) Received: from oahu.WURLDLINK.NET (oahu.wurldlink.net [66.193.144.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A162443D2D for ; Thu, 18 Mar 2004 10:18:55 -0800 (PST) (envelope-from vince@oahu.WURLDLINK.NET) Received: from oahu.WURLDLINK.NET (vince@localhost.WURLDLINK.NET [127.0.0.1]) by oahu.WURLDLINK.NET (8.12.9/8.12.9) with ESMTP id i2IIHmqQ061493; Thu, 18 Mar 2004 08:18:03 -1000 (HST) Received: from localhost (vince@localhost)i2IIHjBe061489; Thu, 18 Mar 2004 08:17:47 -1000 (HST) Date: Thu, 18 Mar 2004 08:17:45 -1000 (HST) From: Vincent Poy To: James In-Reply-To: <20040317021928.GA26065@scylla.towardex.com> Message-ID: <20040318072629.T8264-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org cc: Nicolas DEFFAYET Subject: Re: Latency problem with traffic shaping X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2004 18:18:56 -0000 On Tue, 16 Mar 2004, James wrote: > ohhh... you are concerned about simple 1ms difference due to > granuality (sp) in 35 meg pipe, right? > > this is a simple problem to fix: > > ipfw add 1 allow icmp from any to any icmptypes 11,0,8 > ipfw add 1 allow udp from any to any 33434-33534 > < then insert your pipe rules > > > and also, you realize that you are putting people on vlan3 > to a half duplex pipe right? > > -J While on this subject, I have one of my own... I have a 6.016Mbps/608kbps ADSL connection with 8 static IP's from my ISP. I'm using the FreeBSD box to basically limit my upstream bandwidth to 480kbps so that the downloads would work while uploading. In my kernel, I do have the following options: options IPFIREWALL #firewall options IPDIVERT #divert sockets options DUMMYNET options BRIDGE options HZ=1000 options NMBCLUSTERS=65536 The 8 IP's I'm using is 208.204.244.224-231 on a /24 block with the gateway on the other side at my ISP being 208.204.244.1. The FreeBSD machine is 208.204.244.224 and I do have gateway ip forwarding enabled. My problem is that while as far as speeds are concerned, it's working correctly on both the .224 (FreeBSD box) as well as the .225-.231 boxes behind it. The issue is that tracerouting from any box other than the FreeBSD box shows latencies of 1000+ms after the FreeBSD router beginning with hop 2 when the upstream pipe is being used while the FreeBSD box shows the latency at 40-50ms which is correct under traffic load. Anyone knows what's causing this or is this the way it's supposed to work? All the machines are pointing to .224 (FreeBSD box) as the gateway. All local traffic doesn't go through dummynet's queues. This is how I have ipfw configured. setup_loopback # Traffic Shaping for DSL connection 6.016Mbps/608Kbps # Make packets exiting dummynet not continue down the chain # If this is not enabled, then packets leaving an early # queue might enter a later queue if the conditions for # the later queue are met, which would be completely # devastating to all the prioritizing we're doing ${fwcmd} enable one_pass # Add rules so that local routable IP LAN traffic does not use natd ${fwcmd} add 39 divert natd all from 10.0.0.0/8 to any via ${natd_interface} ${fwcmd} add 40 divert natd all from 172.16.0.0/12 to any via ${natd_interface} ${fwcmd} add 41 divert natd all from 192.168.0.0/16 to any via ${natd_interface} ${fwcmd} add 42 divert natd all from 208.201.244.224/29 to 10.0.0.0/8 via ${natd_interface} ${fwcmd} add 43 divert natd all from 208.201.244.224/29 to 172.16.0.0/12 via ${natd_interface} ${fwcmd} add 44 divert natd all from 208.201.244.224/29 to 192.168.0.0/16 via ${natd_interface} ${fwcmd} add 45 divert natd all from any to 10.0.0.0/8 via ${natd_interface} ${fwcmd} add 46 divert natd all from any to 172.16.0.0/12 via ${natd_interface} ${fwcmd} add 47 divert natd all from any to 192.168.0.0/16 via ${natd_interface} ${fwcmd} add 48 divert natd all from any to 208.201.244.224/29 via ${natd_interface} ${fwcmd} add 49 skipto 100 ip from 208.201.244.224/29 to any ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # Route LAN and RFC1918 networks without Traffic Shaping ${fwcmd} add 63000 allow all from any to 10.0.0.0/8 out ${fwcmd} add 63001 allow all from any to 172.16.0.0/12 out ${fwcmd} add 63002 allow all from any to 192.168.0.0/16 out ${fwcmd} add 63003 allow all from any to 208.201.244.224/29 out # Define our upload pipe ${fwcmd} pipe 1 config bw 480Kbit/s # Define a high-priority queue ${fwcmd} queue 1 config pipe 1 weight 100 # Define a medium-high-priority queue ${fwcmd} queue 2 config pipe 1 weight 99 # Define a medium-low-priority queue ${fwcmd} queue 3 config pipe 1 weight 98 # Define a low-priority queue ${fwcmd} queue 4 config pipe 1 weight 97 # Assign outgoing empty/small ACK packets to the high-priority queue ${fwcmd} add 63004 set 0 queue 1 tcp from any to any tcpflags ack iplen 0-80 out # Assign outgoing UDP (DNS/gaming) and SSH traffic to the medium-high-priority queue ${fwcmd} add 63005 set 0 queue 2 tcp from any to any 22,23 out ${fwcmd} add 63006 set 0 queue 2 udp from any to any not 80,443 out # Assign outgoing HTTP/HTTPS WEB traffic to the medium-low-priority queue ${fwcmd} add 63007 set 0 queue 3 all from any to any 80,443 out # Assign all other outgoing traffic to the low-priority queue ${fwcmd} add 63008 set 0 queue 4 all from any to any out # End of Traffic Shaping ${fwcmd} add 65000 pass all from any to any This is what the latencies look like on the machines behind the FreeBSD router when there is a upload: Tracing route to wurldlink.net [66.193.144.22] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms adsl-208-201-244-224.sonic.net [208.201.244.224] 2 915 ms 933 ms 1025 ms adsl-208-201-244-1.sonic.net [208.201.244.1] 3 1082 ms 1015 ms 1089 ms fast1-0-0.border.sr.sonic.net [208.201.224.194] 4 1206 ms 816 ms 869 ms fast0-0.gw.equinix-sj.sonic.net [64.142.0.14] 5 943 ms 1022 ms 1091 ms bpr1-t3-7-2-0.SanJoseEquinix.cw.net [208.173.54.45] 6 1095 ms 1044 ms 1112 ms cable-and-wireless-peering.SanJoseEquinix.cw.net [208.173.54.70] 7 1160 ms 1070 ms 1115 ms sl-bb25-sj-10-0.sprintlink.net [144.232.20.62] 8 891 ms 962 ms 1049 ms sl-bb20-sj-13-0.sprintlink.net [144.232.3.197] 9 960 ms 891 ms 1005 ms sl-bb20-stk-12-0.sprintlink.net [144.232.20.98] 10 1218 ms 1101 ms 1189 ms sl-bb20-prl-9-0.sprintlink.net [144.232.8.25] 11 811 ms 889 ms 979 ms sl-gw2-prl-0-0.sprintlink.net [144.232.30.22] 12 1002 ms 1070 ms 1164 ms sl-timewarner-12-0.sprintlink.net [160.81.200.214] 13 1065 ms 1062 ms 1080 ms 64-132-26-250.gen.twtelecom.net [64.132.26.250] 14 1173 ms 1098 ms 1155 ms kpext.ksbe.edu [216.136.57.178] 15 1092 ms 1108 ms 1209 ms www.onenet-usa.net [66.193.144.22] This is a traceroute directly from the FreeBSD box... traceroute to wurldlink.net (66.193.144.22), 64 hops max, 40 byte packets 1 adsl-208-201-244-1.sonic.net (208.201.244.1) 58.235 ms 57.779 ms 76.804 ms 2 fast1-0-0.border.sr.sonic.net (208.201.224.194) 38.449 ms 48.158 ms 48.871 ms 3 fast0-0.gw.equinix-sj.sonic.net (64.142.0.14) 60.951 ms 56.486 ms 49.452 ms 4 bpr1-t3-7-2-0.SanJoseEquinix.cw.net (208.173.54.45) 53.794 ms 52.463 ms 68.045 ms 5 cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.54.70) 78.437 ms 50.674 ms 46.528 ms 6 sl-bb25-sj-10-0.sprintlink.net (144.232.20.62) 52.491 ms 81.473 ms 54.669 ms 7 sl-bb20-sj-13-0.sprintlink.net (144.232.3.197) 67.872 ms 53.260 ms 65.417 ms 8 sl-bb20-stk-12-0.sprintlink.net (144.232.20.98) 81.940 ms 48.695 ms 59.650 ms 9 sl-bb20-prl-9-0.sprintlink.net (144.232.8.25) 118.604 ms 107.292 ms 136.087 ms 10 sl-gw2-prl-0-0.sprintlink.net (144.232.30.22) 124.988 ms 128.812 ms 129.594 ms 11 sl-timewarner-12-0.sprintlink.net (160.81.200.214) 126.898 ms 149.349 ms 114.960 ms 12 64-132-26-250.gen.twtelecom.net (64.132.26.250) 116.782 ms 140.489 ms 123.899 ms 13 kpext.ksbe.edu (216.136.57.178) 165.563 ms 131.212 ms 118.557 ms 14 www.onenet-usa.net (66.193.144.22) 155.675 ms 140.607 ms 175.878 ms Any ideas why the machines behind the FreeBSD box shows the 1000+ms latency after it reaches the FreeBSD box when the upstream pipe is being used but the speeds are working correctly? Thanks! Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 20:14:29 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1F3B16A4CE; Thu, 18 Mar 2004 20:14:29 -0800 (PST) Received: from secure.net2000.com.au (secure.net2000.com.au [203.26.98.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5128243D2F; Thu, 18 Mar 2004 20:14:28 -0800 (PST) (envelope-from ktulu@net2000.com.au) Received: (from apache@localhost) by secure.net2000.com.au (8.11.6/8.11.6) id i2J4M7i09566; Fri, 19 Mar 2004 15:22:07 +1100 X-Authentication-Warning: secure.net2000.com.au: apache set sender to ktulu@net2000.com.au using -f Received: from 202.14.179.253 ([202.14.179.253]) by secure.net2000.com.au (IMP) with HTTP for ; Fri, 19 Mar 2004 15:22:07 +1100 Message-ID: <1079670127.405a756f4bafe@secure.net2000.com.au> Date: Fri, 19 Mar 2004 15:22:07 +1100 From: ktulu@net2000.com.au To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.1 X-Originating-IP: 202.14.179.253 Subject: port forwarding and ipfw rules X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 04:14:29 -0000 Hi All, I have posted this question before, but I don't think I made myself very clear in what I was hoping to achieve. Hopefully, this post will help out. I have a situation where I have one network interface (fxp1) connected to the network with the IP address xxx.xxx.19.110 which is port forwarding (on port 443) to a host xxx.xxx.19.109. Currently, this situation works fine. The problem I'm having is that I have two of these machines doing the same thing and I require the ability for one machine to take over from the other in the event of a hardware failure, etc. The diagram below basically shows what I want to achieve: Internet ---------- | | | fxp1 | fxp1 .19.110 | .19.111 | (alias) | ----------------- | FW | | Default route | | xx.xx.19.225 | | | ----------------- | / \ fxp1 / \ fxp1 .19.110/ \.19.111 (alias) / \ / \ / \ / \ / \ / \ / \ ----- ----- | | | | | | | | | | | | | | | | ----- ----- Web Server Web Server x.x.19.109:443 x.x.19.102:443 This configuration must be able to be added and removed dynamically without effecting the existing network setup (other than changing ipfw rules). Below are the relevant sections of my current configuration settings: ***BEGIN /etc/rc.conf: network interfaces="fxp1 lo0" ifconfig_lo0="inet 127.0.0.1" ifconfig_fxp1="inet xxx.xxx.19.110 netmask 255.255.255.0" defaultrouter="xxx.xxx.19.225" gateway_enable="YES" natd_enable="YES" natd_interface="fxp1" natd_flags="-l -m -redirect_port tcp xxx.xxx.19.109:443 443" firewall_enable="YES" firewall_type="custom" firewall_script="/etc/rc.firewall" firewall_quiet="NO" tcp_extensions="YES" *** END /etc/rc.conf *** BEGIN /etc/rc.firewall ############ # Set the host IP address and the forwarding IP # # Set this to your ip address. ip="xxx.xxx.19.110" # Set this to the ip of the machine traffic on 443 is being forwarded to fwd_ip="xxx.xxx.19.109" # Set this to the IP of the machine this host is used as a failover for fail_ip="xxx.xxx.19.111" # Set this to the IP of the machine traffic on 443 of the failed host is being forwarded to fail_forward="xxx.xxx.19.102" # Set this to the port of the new natd daemon for the failover fail_natd="8669" case ${firewall_type} in [Cc][Uu][Ss][Tt][Oo][Mm]) case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} fi ;; esac # Allow anything outbound from this address. ${fwcmd} add allow all from ${ip} to any out # Deny anything outbound from other addresses. ${fwcmd} add deny log all from any to any out # Allow TCP through if setup succeeded. ${fwcmd} add allow tcp from any to any established # Allow IP fragments to pass through. ${fwcmd} add allow all from any to any frag # Allow inbound ftp, ssh, email, tcp-dns, http, https, pop3, pop3s. ${fwcmd} add allow tcp from any to ${ip} 22 setup ${fwcmd} add allow tcp from any to ${ip} 80 setup # This record has to be slightly different because this machine is # not actually listening on port 443, but just forwarding traffic on # port ${fwcmd} add allow tcp from any to ${fwd_ip} 443 # Deny inbound auth, netbios, ldap, and Microsoft's DB protocol # without logging. ${fwcmd} add deny tcp from any to ${ip} 113 setup ${fwcmd} add deny tcp from any to ${ip} 139 setup ${fwcmd} add deny tcp from any to ${ip} 389 setup ${fwcmd} add deny tcp from any to ${ip} 445 setup # Deny some chatty UDP broadcast protocols without logging. ${fwcmd} add deny udp from any 137 to any ${fwcmd} add deny udp from any to any 137 ${fwcmd} add deny udp from any 138 to any ${fwcmd} add deny udp from any 513 to any ${fwcmd} add deny udp from any 525 to any # Allow inbound DNS and NTP replies. This is somewhat of a hole, # since we're looking at the incoming port number, which can be # faked, but that's just the way DNS and NTP work. ${fwcmd} add allow udp from any 53 to ${ip} ${fwcmd} add allow udp from any 123 to ${ip} # Allow inbound DNS queries. ${fwcmd} add allow udp from any to ${ip} 53 # Deny inbound NTP queries without logging. ${fwcmd} add deny udp from any to ${ip} 123 # Allow traceroute to function, but not to get in. ${fwcmd} add unreach port udp from any to ${ip} 33435-33524 # Allow some inbound icmps - echo reply, dest unreach, source quench, # echo, ttl exceeded. ${fwcmd} add allow icmp from any to any icmptypes 0,3,4,8,11 # Everything else is denied and logged. ${fwcmd} add deny log all from any to any ;; *** END /etc/rc.firewall Basically, what I've done to try and add the other configuration to this box is as follows: 1. Add the aliased IP to fxp1: ifconfig fxp1 inet xxx.xxx.19.111 netmask 255.255.255.255 alias 2. Start the additional natd daemon: /sbin/natd -same_ports -use_sockets -port 8669 -alias_address xxx.xxx.19.111 -redirect_port tcp xxx.xxx.19.102:443 xxx.xxx.19.111:443 3. Change the ipfw rules to allow this new configuration through. This is basically the same as the firewall rules above, but each entry is doubled, where ${ip} becomes ${fail_ip}. In addition to this, another rule is entered in the "natd_enable" section to divert the new natd: case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} ${fwcmd} add 50 divert ${fail_natd} all from any to any via ${natd_interface} fi ;; esac Once I've added this, this port forwarding on xxx.xxx.19.110 still works, but the port forwarding on the aliased IP (xxx.xxx.19.111) doesn't! I'm not sure exactly where the problem lies, but I assume it has something to do with my ipfw ruleset. I looked at a previous post here: http://lists.freebsd.org/pipermail/freebsd-ipfw/2004-March/000976.html that looks similar to my situation, but still no love. If any could help out with the config, it'd be much appreciated! I'm more than happy to provide any further config details, tcp dumps, etc. Regards, Leigh From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 18 23:34:03 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 895CA16A4CE for ; Thu, 18 Mar 2004 23:34:03 -0800 (PST) Received: from mailhost.wsf.at (server202.serveroffice.com [217.196.72.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44BB143D39 for ; Thu, 18 Mar 2004 23:34:02 -0800 (PST) (envelope-from tw@wsf.at) Received: from mailhost.wsf.at (root@localhost)i2J7VF71003286 for ; Fri, 19 Mar 2004 08:31:15 +0100 (CET) (envelope-from tw@wsf.at) Received: from mailhost.wsf.at (http.wsf.at [217.196.72.203]) i2J7VCqY003278; Fri, 19 Mar 2004 08:31:12 +0100 (CET) (envelope-from tw@wsf.at) Date: Fri, 19 Mar 2004 07:31:12 -0000 To: ktulu@net2000.com.au, freebsd-ipfw@freebsd.org From: Thomas Wolf X-Mailer: twiggi 1.10.3 Message-ID: <20040319083112.1q3zyahmb90kw@.mailhost.wsf.at> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: port forwarding and ipfw rules X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tw@wsf.at List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 07:34:03 -0000 ktulu@net2000.com.au schrieb: > > Basically, what I've done to try and add the other configuration to this box is > as follows: > > 1. Add the aliased IP to fxp1: > ifconfig fxp1 inet xxx.xxx.19.111 netmask 255.255.255.255 alias > > 2. Start the additional natd daemon: > /sbin/natd -same_ports -use_sockets -port 8669 -alias_address xxx.xxx.19.111 > -redirect_port tcp xxx.xxx.19.102:443 xxx.xxx.19.111:443 > > 3. Change the ipfw rules to allow this new configuration through. This is > basically the same as the firewall rules above, but each entry is doubled, where > ${ip} becomes ${fail_ip}. In addition to this, another rule is entered in the > "natd_enable" section to divert the new natd: > case ${natd_enable} in > [Yy][Ee][Ss]) > if [ -n "${natd_interface}" ]; then > ${fwcmd} add 50 divert natd all from any to any via > ${natd_interface} > ${fwcmd} add 50 divert ${fail_natd} all from any to any via ${natd_interface} > fi > ;; > esac > > > Once I've added this, this port forwarding on xxx.xxx.19.110 still works, but > the port forwarding on the aliased IP (xxx.xxx.19.111) doesn't! I think your second divert rule will never be reached because natd re-inserts the packets at the next rule-no *higher* than the rule which diverted (check the counters on rule 50). Perhaps just changing the second divert rule to 55 will do the trick. Thomas -- Thomas Wolf Wiener Software Fabrik Dubas u. Wolf GMBH 1050 Wien, Mittersteig 4 From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 19 09:37:13 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81BD816A4CE for ; Fri, 19 Mar 2004 09:37:13 -0800 (PST) Received: from mail.thekeelecentre.com (mail.thekeelecentre.com [217.206.238.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id C014743D2D for ; Fri, 19 Mar 2004 09:37:12 -0800 (PST) (envelope-from richardtector@thekeelecentre.com) Received: from localhost (localhost.thekeelecentre.com [127.0.0.1]) by mail.thekeelecentre.com (Postfix) with ESMTP id E53EE56A4; Fri, 19 Mar 2004 17:30:52 +0000 (GMT) Received: from mail.thekeelecentre.com ([217.206.238.156]) by localhost (moses.thekeelecentre.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28324-07; Fri, 19 Mar 2004 17:30:52 +0000 (GMT) Received: from localhost (mail.thekeelecentre.com [217.206.238.156]) by mail.thekeelecentre.com (Postfix) with ESMTP id AA79B5673; Fri, 19 Mar 2004 17:30:52 +0000 (GMT) Received: from haema1.capl.co.uk (haema1.capl.co.uk [217.206.238.171]) by webmail.thekeelecentre.com (IMP) with HTTP for ; Fri, 19 Mar 2004 17:30:52 +0000 Message-ID: <1079717452.405b2e4c999e8@webmail.thekeelecentre.com> Date: Fri, 19 Mar 2004 17:30:52 +0000 From: Richard Tector To: ktulu@net2000.com.au MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 / FreeBSD-4.9 X-Originating-IP: 217.206.238.171 X-Virus-Scanned: by amavisd-new at thekeelecentre.com cc: freebsd-ipfw@freebsd.org Subject: Re. port forwarding and ipfw rules X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 17:37:13 -0000 I don't think that this setup can be achieved using purely ipfw/natd. I think a better approach would be to consider inserting a proxy between the two that will do load balancing/failover. I believe squid can achieve this. It should do round robin with requests to each server and if one does not respond then it should continue by trying to request from the next server in the list. Port 443 should be forwarded to the squid server instead (this could run on the firewall box) and the squid server should be setup as a reverse proxy for the two web servers. The squid homepage can help you with this. In this setup, the client-server connection is then between the client's browser and squid. Squid then makes its own connection to the server. If you have 'proper' certificates these will need to be put on the squid. Hope this was of some help. Kind regards, Richard Tector CAPL Ltd. Quoting ktulu@net2000.com.au: > Hi All, > > I have posted this question before, but I don't think I made myself very > clear > in what I was hoping to achieve. Hopefully, this post will help out. > > I have a situation where I have one network interface (fxp1) connected to > the > network with the IP address xxx.xxx.19.110 which is port forwarding (on port > 443) to a host xxx.xxx.19.109. Currently, this situation works fine. > > The problem I'm having is that I have two of these machines doing the same > thing > and I require the ability for one machine to take over from the other in the > event of a hardware failure, etc. The diagram below basically shows what I > want > to achieve: > > > Internet > ---------- > | > | > | > fxp1 | fxp1 > .19.110 | .19.111 > | (alias) > | > ----------------- > | FW | > | Default route | > | xx.xx.19.225 | > | | > ----------------- > | > / \ > fxp1 / \ fxp1 > .19.110/ \.19.111 (alias) > / \ > / \ > / \ > / \ > / \ > / \ > / \ > ----- ----- > | | | | > | | | | > | | | | > | | | | > ----- ----- > Web Server Web Server > x.x.19.109:443 x.x.19.102:443 > > > This configuration must be able to be added and removed dynamically without > effecting the existing network setup (other than changing ipfw rules). > Below > are the relevant sections of my current configuration settings: > > ***BEGIN /etc/rc.conf: > network interfaces="fxp1 lo0" > ifconfig_lo0="inet 127.0.0.1" > ifconfig_fxp1="inet xxx.xxx.19.110 netmask 255.255.255.0" > defaultrouter="xxx.xxx.19.225" > gateway_enable="YES" > natd_enable="YES" > natd_interface="fxp1" > natd_flags="-l -m -redirect_port tcp xxx.xxx.19.109:443 443" > firewall_enable="YES" > firewall_type="custom" > firewall_script="/etc/rc.firewall" > firewall_quiet="NO" > tcp_extensions="YES" > *** END /etc/rc.conf > > *** BEGIN /etc/rc.firewall > ############ > # Set the host IP address and the forwarding IP > # > # Set this to your ip address. > ip="xxx.xxx.19.110" > # Set this to the ip of the machine traffic on 443 is being forwarded to > fwd_ip="xxx.xxx.19.109" > # Set this to the IP of the machine this host is used as a failover for > fail_ip="xxx.xxx.19.111" > # Set this to the IP of the machine traffic on 443 of the failed host is > being > forwarded to > fail_forward="xxx.xxx.19.102" > # Set this to the port of the new natd daemon for the failover > fail_natd="8669" > > case ${firewall_type} in > [Cc][Uu][Ss][Tt][Oo][Mm]) > > case ${natd_enable} in > [Yy][Ee][Ss]) > if [ -n "${natd_interface}" ]; then > ${fwcmd} add 50 divert natd all from any to any via > ${natd_interface} > fi > ;; > esac > > # Allow anything outbound from this address. > ${fwcmd} add allow all from ${ip} to any out > > # Deny anything outbound from other addresses. > ${fwcmd} add deny log all from any to any out > > # Allow TCP through if setup succeeded. > ${fwcmd} add allow tcp from any to any established > > # Allow IP fragments to pass through. > ${fwcmd} add allow all from any to any frag > > # Allow inbound ftp, ssh, email, tcp-dns, http, https, pop3, pop3s. > ${fwcmd} add allow tcp from any to ${ip} 22 setup > ${fwcmd} add allow tcp from any to ${ip} 80 setup > > # This record has to be slightly different because this machine is > # not actually listening on port 443, but just forwarding traffic on > # port > ${fwcmd} add allow tcp from any to ${fwd_ip} 443 > > # Deny inbound auth, netbios, ldap, and Microsoft's DB protocol > # without logging. > ${fwcmd} add deny tcp from any to ${ip} 113 setup > ${fwcmd} add deny tcp from any to ${ip} 139 setup > ${fwcmd} add deny tcp from any to ${ip} 389 setup > ${fwcmd} add deny tcp from any to ${ip} 445 setup > > # Deny some chatty UDP broadcast protocols without logging. > ${fwcmd} add deny udp from any 137 to any > ${fwcmd} add deny udp from any to any 137 > ${fwcmd} add deny udp from any 138 to any > ${fwcmd} add deny udp from any 513 to any > ${fwcmd} add deny udp from any 525 to any > > # Allow inbound DNS and NTP replies. This is somewhat of a hole, > # since we're looking at the incoming port number, which can be > # faked, but that's just the way DNS and NTP work. > ${fwcmd} add allow udp from any 53 to ${ip} > ${fwcmd} add allow udp from any 123 to ${ip} > > # Allow inbound DNS queries. > ${fwcmd} add allow udp from any to ${ip} 53 > > # Deny inbound NTP queries without logging. > ${fwcmd} add deny udp from any to ${ip} 123 > > # Allow traceroute to function, but not to get in. > ${fwcmd} add unreach port udp from any to ${ip} 33435-33524 > > # Allow some inbound icmps - echo reply, dest unreach, source > quench, > # echo, ttl exceeded. > ${fwcmd} add allow icmp from any to any icmptypes 0,3,4,8,11 > > # Everything else is denied and logged. > ${fwcmd} add deny log all from any to any > ;; > *** END /etc/rc.firewall > > > Basically, what I've done to try and add the other configuration to this box > is > as follows: > > 1. Add the aliased IP to fxp1: > ifconfig fxp1 inet xxx.xxx.19.111 netmask 255.255.255.255 alias > > 2. Start the additional natd daemon: > /sbin/natd -same_ports -use_sockets -port 8669 -alias_address xxx.xxx.19.111 > -redirect_port tcp xxx.xxx.19.102:443 xxx.xxx.19.111:443 > > 3. Change the ipfw rules to allow this new configuration through. This is > basically the same as the firewall rules above, but each entry is doubled, > where > ${ip} becomes ${fail_ip}. In addition to this, another rule is entered in > the > "natd_enable" section to divert the new natd: > case ${natd_enable} in > [Yy][Ee][Ss]) > if [ -n "${natd_interface}" ]; then > ${fwcmd} add 50 divert natd all from any to any via > ${natd_interface} > ${fwcmd} add 50 divert ${fail_natd} all from any to any via > ${natd_interface} > fi > ;; > esac > > > Once I've added this, this port forwarding on xxx.xxx.19.110 still works, > but > the port forwarding on the aliased IP (xxx.xxx.19.111) doesn't! I'm not > sure > exactly where the problem lies, but I assume it has something to do with my > ipfw > ruleset. I looked at a previous post here: > http://lists.freebsd.org/pipermail/freebsd-ipfw/2004-March/000976.html that > looks similar to my situation, but still no love. > > If any could help out with the config, it'd be much appreciated! I'm more > than > happy to provide any further config details, tcp dumps, etc. > > Regards, > Leigh > _______________________________________________ > 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" > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 19 10:34:32 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F64216A4CE for ; Fri, 19 Mar 2004 10:34:32 -0800 (PST) Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3580443D2F for ; Fri, 19 Mar 2004 10:34:32 -0800 (PST) (envelope-from co0lkizz@btinternet.com) Received: from [81.129.139.226] (helo=mushas) by tungsten.btinternet.com with smtp (Exim 3.22 #25) id 1B4OpB-0000yh-00 for freebsd-ipfw@freebsd.org; Fri, 19 Mar 2004 18:34:29 +0000 Message-ID: <007301c40de0$cfda1d70$0400a8c0@c15970.findquick.com> From: "Smo0ke" To: Date: Fri, 19 Mar 2004 18:34:27 -0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: ipfw uid problems X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2004 18:34:32 -0000 I have a problem with ipfw im not sure wether its due to me or the = software, here is a setup ive implemented as a test: # ipfw show 00100 0 0 allow tcp from 66.x.x.236 to any uid root 00200 10 440 deny tcp from 66.x.x.236 to any 65535 349814 68070365 allow ip from any to any # now as you can see no packets are being accepted under the uid root, im = trying to get through on port 80 for httpd with no avial, ive tried a = few things such as adding uid www but that didnt work ive also tried = setting up a log, you can see the results of the above ruleset below = when trying to access 66.x.x.236 on port 80: Mar 19 16:46:17 host /kernel: ipfw: 100 Accept TCP 81.x.x.226:24862 = 66.x.x.236:80 in via fxp0 Mar 19 16:46:26 host last message repeated 2 times Any suggestions my machine is running 4.9-RELEASE, Regards, Grant Millar From owner-freebsd-ipfw@FreeBSD.ORG Fri Mar 19 19:23:33 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5664416A4CE; Fri, 19 Mar 2004 19:23:33 -0800 (PST) Received: from mail001.syd.optusnet.com.au (mail001.syd.optusnet.com.au [211.29.132.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 682D043D1D; Fri, 19 Mar 2004 19:23:31 -0800 (PST) (envelope-from tfrank@optushome.com.au) Received: from marvin.home.local (c211-28-241-126.eburwd5.vic.optusnet.com.au [211.28.241.126])i2K3NSo06438; Sat, 20 Mar 2004 14:23:29 +1100 Received: by marvin.home.local (Postfix, from userid 1001) id 9C3031FB81; Sat, 20 Mar 2004 14:23:28 +1100 (EST) Date: Sat, 20 Mar 2004 14:23:28 +1100 From: Tony Frank To: ktulu@net2000.com.au Message-ID: <20040320032328.GA66773@marvin.home.local> References: <1079670127.405a756f4bafe@secure.net2000.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1079670127.405a756f4bafe@secure.net2000.com.au> User-Agent: Mutt/1.4.2.1i cc: freebsd-net@freebsd.org cc: freebsd-ipfw@freebsd.org Subject: Re: port forwarding and ipfw rules X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 03:23:33 -0000 Hi there, On Fri, Mar 19, 2004 at 03:22:07PM +1100, ktulu@net2000.com.au wrote: > Hi All, > > I have posted this question before, but I don't think I made myself very clear > in what I was hoping to achieve. Hopefully, this post will help out. > > I have a situation where I have one network interface (fxp1) connected to the > network with the IP address xxx.xxx.19.110 which is port forwarding (on port > 443) to a host xxx.xxx.19.109. Currently, this situation works fine. > > The problem I'm having is that I have two of these machines doing the same thing > and I require the ability for one machine to take over from the other in the > event of a hardware failure, etc. The diagram below basically shows what I want > to achieve: > > > Internet > ---------- > | > | > | > fxp1 | fxp1 > .19.110 | .19.111 > | (alias) > | > ----------------- > | FW | > | Default route | > | xx.xx.19.225 | > | | > ----------------- > | > / \ > fxp1 / \ fxp1 > .19.110/ \.19.111 (alias) > / \ > / \ > / \ > / \ > / \ > / \ > / \ > ----- ----- > | | | | > | | | | > | | | | > | | | | > ----- ----- > Web Server Web Server > x.x.19.109:443 x.x.19.102:443 fxp1 seems to be very busy in this picture. My understanding is that you want to do: 1. redirect any connections to .19.110:443 to .19.109:443 2. redirect any connections to .19.111:443 to .19.102:443 Assuming your uplink is sending traffic for .19.110 and .19.111 to your interface (fxp1) (You can do this by aliasing 111 to the 110 interface as you already indicated) You just need a natd.conf with something like this in it: redirect_port tcp .19.109:443 .19.110:443 redirect_port tcp .19.102:443 .19.111:443 I got it going with similar kind of setup. In my case I used port 80 and tried to get network setup as I understand your description, something like the below: (internet) | public IP +------+ | fxp0 | In my case this one runs natd/squid | ext. | so all queries to internal net appear to | f/w | originate from .10 | fxp2 | +------+ | .10 +---+------+---------+ .110 | .111 | .109 | .102 +------+ +------+ +------+ | fxp0 | | fxp0 | | fxp0 | | g/w | | www1 | | www2 | +------+ +------+ +------+ g/w is running ipfw + natd to divert traffic www1 and www2 are simple servers running apache tcpdump shows: 1. syn packet comes in to 110:80 2. syn packet is sent out to 109:80 (rewritten by natd to appear from 110:80) 3. syn+ack comes back to 110 4. 110 forwards back to original source and so on for the rest of the connection. Same deal for traffic to 111 (tcpdump output below) Note: www1 and www2 see the traffic as originating from .110 and reply appropriately. .110 sends it all to natd which replaces the IP headers so the reply traffic has source either .110 or .111 depending on where the request came from. Also my g/w (.110) is currently 5.2.1 but the config should be same for 4.9. Details follow: /etc/natd.conf: log yes dynamic yes log_denied yes deny_incoming no use_sockets yes same_ports yes target_address 255.255.255.255 log_ipfw_denied yes redirect_port tcp 192.168.200.109:80 192.168.200.110:80 redirect_port tcp 192.168.200.102:80 192.168.200.111:80 ifconfig -a: midway# ifconfig -a fxp0: flags=8943 mtu 1500 inet 192.168.200.110 netmask 0xffffff00 broadcast 192.168.200.255 inet 192.168.200.111 netmask 0xffffffff broadcast 192.168.200.111 ether 00:06:29:f1:82:72 media: Ethernet autoselect (100baseTX ) status: active plip0: flags=8810 mtu 1500 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ipfw rules: 00050 216691 60715152 divert 8668 ip from any to any via fxp0 00100 0 0 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 65000 212716 60372772 allow ip from any to any 65535 0 0 deny ip from any to any tcpdumps of the traffic: 13:47:25.595348 192.168.200.10.3881 > 192.168.200.110.80: S 642583182:642583182(0) win 65535 (DF) 13:47:25.596052 192.168.200.110.3881 > 192.168.200.109.80: S 642583182:642583182(0) win 65535 (DF) 13:47:25.596121 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:47:25.596495 192.168.200.109.80 > 192.168.200.110.3881: S 1971745869:1971745869(0) ack 642583183 win 65535 (DF) 13:47:25.596712 192.168.200.110.80 > 192.168.200.10.3881: S 1971745869:1971745869(0) ack 642583183 win 65535 (DF) 13:47:25.596791 192.168.200.110 > 192.168.200.109: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:47:25.596847 192.168.200.10.3881 > 192.168.200.110.80: . ack 1 win 33304 (DF) 13:47:25.597035 192.168.200.110.3881 > 192.168.200.109.80: . ack 1 win 33304 (DF) 13:47:25.597098 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:47:25.597211 192.168.200.10.3881 > 192.168.200.110.80: P 1:509(508) ack 1 win 33304 (DF) 13:47:25.597415 192.168.200.110.3881 > 192.168.200.109.80: P 1:509(508) ack 1 win 33304 (DF) 13:47:25.597480 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:47:25.616863 192.168.200.109.80 > 192.168.200.110.3881: P 1:274(273) ack 509 win 33304 (DF) 13:47:25.617161 192.168.200.110.80 > 192.168.200.10.3881: P 1:274(273) ack 509 win 33304 (DF) 13:47:25.617227 192.168.200.110 > 192.168.200.109: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:47:25.716982 192.168.200.10.3881 > 192.168.200.110.80: . ack 274 win 33304 (DF) 13:47:25.717368 192.168.200.110.3881 > 192.168.200.109.80: . ack 274 win 33304 (DF) 13:47:25.717436 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.109 to host 192.168.200.109 (DF) 13:49:48.703004 192.168.200.10.3882 > 192.168.200.111.80: S 3017889378:3017889378(0) win 65535 (DF) 13:49:48.703591 192.168.200.110.3882 > 192.168.200.102.80: S 3017889378:3017889378(0) win 65535 (DF) 13:49:48.703680 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) 13:49:48.703941 192.168.200.102.80 > 192.168.200.110.3882: S 33897141:33897141(0) ack 3017889379 win 65535 (DF) 13:49:48.704137 192.168.200.111.80 > 192.168.200.10.3882: S 33897141:33897141(0) ack 3017889379 win 65535 (DF) 13:49:48.704201 192.168.200.110 > 192.168.200.102: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:49:48.704270 192.168.200.10.3882 > 192.168.200.111.80: . ack 1 win 33304 (DF) 13:49:48.704458 192.168.200.110.3882 > 192.168.200.102.80: . ack 1 win 33304 (DF) 13:49:48.704521 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) 13:49:48.704636 192.168.200.10.3882 > 192.168.200.111.80: P 1:509(508) ack 1 win 33304 (DF) 13:49:48.704839 192.168.200.110.3882 > 192.168.200.102.80: P 1:509(508) ack 1 win 33304 (DF) 13:49:48.704904 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) 13:49:48.718553 192.168.200.102.80 > 192.168.200.110.3882: P 1:274(273) ack 509 win 33304 (DF) 13:49:48.718844 192.168.200.111.80 > 192.168.200.10.3882: P 1:274(273) ack 509 win 33304 (DF) 13:49:48.718910 192.168.200.110 > 192.168.200.102: icmp: redirect 192.168.200.10 to host 192.168.200.10 (DF) 13:49:48.818588 192.168.200.10.3882 > 192.168.200.111.80: . ack 274 win 33304 (DF) 13:49:48.818947 192.168.200.110.3882 > 192.168.200.102.80: . ack 274 win 33304 (DF) 13:49:48.819014 192.168.200.110 > 192.168.200.10: icmp: redirect 192.168.200.102 to host 192.168.200.102 (DF) > This configuration must be able to be added and removed dynamically without > effecting the existing network setup (other than changing ipfw rules). Below > are the relevant sections of my current configuration settings: Should be able to do this by using ifconfig to add/remove an alias on the interface. There are various tools in ports to do this automatically. If the mappings are static, you should be able to have all combinations defined in a standard natd config file. Hope it helps, Tony From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 20 00:13:47 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0771B16A4CE for ; Sat, 20 Mar 2004 00:13:47 -0800 (PST) Received: from mordrede.visionsix.net (mordrede.visionsix.com [65.202.119.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id A24B443D2D for ; Sat, 20 Mar 2004 00:13:46 -0800 (PST) (envelope-from lists@visionsix.com) Received: from vsis169 (unverified [65.202.119.169]) by mordrede.visionsix.net for ; Sat, 20 Mar 2004 02:13:45 -0600 Message-ID: <004d01c40e53$3f8b8880$df0a0a0a@visionsix.net> From: "Lewis Watson" To: Date: Sat, 20 Mar 2004 02:13:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: ping timeouts X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 08:13:47 -0000 Hello, I would greatly appreciate some advice on the following situation... Ou goal is to use a FreeBSD box as a gateway/ router for several clients. These clients are being provided Internet access through our network and other than a few common worm holes blocked and bandwidth management they should have open access. We are passing traffic through the gateway at this time and bandwidth management seems to work fine (when browsing or just doing normal stuff it is not noticable) but when pinging with a minimal load (one client behind the gateway sending 500byte icmp packets) we are getting around 15% to 25% timeouts. This occurs even if just pinging the internal interface. If we move the host from behind the gateway it has no problem pinging another host. This occurs even when we remove dummynet pipes and rules. Also we have tried this on two seperate machines running FreeBSD 4.9. NIC's are all 3com 3c905 (xl0, xl1) I am using the following rules after rebuilding the kernel with the additions mentioned below. # Kernel Config Changes options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=10 options DUMMYNET options HZ=1000 # This is my attempt at a using IPFW to allow a very open network # It's essentially open except for a very few things. # See Below, it's all commented. # fwcmd="/sbin/ipfw" # Flush previous rules ${fwcmd} -f flush # Block the Microsoft Worm :-), SQL in and Ident ${fwcmd} add deny udp from any to any 135-137,139,445 ${fwcmd} add deny tcp from any to any 135-137,139,445,1434 ${fwcmd} add reset tcp from any to any 113 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) ${fwcmd} add deny all from any to 0.0.0.0/8 ${fwcmd} add deny all from any to 169.254.0.0/16 ${fwcmd} add deny all from any to 192.0.2.0/24 ${fwcmd} add deny all from any to 224.0.0.0/4 # Each client would have an in and out pipe and their own subnet # ${fwcmd} add pipe 1 ip from any to 192.168.1.252/30 in ${fwcmd} add pipe 2 ip from 192.168.1.252/30 to any out ${fwcmd} pipe 1 config bw 900Kbit/s queue 112Kbytes ${fwcmd} pipe 2 config bw 900Kbit/s queue 112Kbytes ${fwcmd} add 65000 pass all from any to any Thanks, Lewis From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 20 01:17:55 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A67FE16A4CE for ; Sat, 20 Mar 2004 01:17:55 -0800 (PST) Received: from mordrede.visionsix.net (mordrede.visionsix.com [65.202.119.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 280CD43D39 for ; Sat, 20 Mar 2004 01:17:53 -0800 (PST) (envelope-from lists@visionsix.com) Received: from vsis169 (unverified [65.202.119.169]) by mordrede.visionsix.net for ; Sat, 20 Mar 2004 03:17:52 -0600 Message-ID: <003101c40e5c$33ef08e0$df0a0a0a@visionsix.net> From: "Lewis Watson" To: References: <004d01c40e53$3f8b8880$df0a0a0a@visionsix.net> Date: Sat, 20 Mar 2004 03:17:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: ping timeouts X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 09:17:55 -0000 > I would greatly appreciate some advice on the following situation... > Turned out to be a bad switch - no problems here! Lewis From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 20 02:17:36 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67A7016A4CE for ; Sat, 20 Mar 2004 02:17:36 -0800 (PST) Received: from mx1.subnetmask.net (mx1.subnetmask.net [207.44.145.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42AE743D31 for ; Sat, 20 Mar 2004 02:17:36 -0800 (PST) (envelope-from mcgehrin@reverse.net) Received: from localhost (mx1.subnetmask.net [207.44.145.31]) by mx1.subnetmask.net (Postfix) with ESMTP id 39E83F396C for ; Sat, 20 Mar 2004 05:17:35 -0500 (EST) Received: by localhost (Postfix, from userid 1012) id D0C275E56; Sat, 20 Mar 2004 05:17:34 -0500 (EST) Received: from orange (unknown [192.168.0.175]) by localhost (Postfix) with SMTP id E2BFC5E3B for ; Sat, 20 Mar 2004 05:17:25 -0500 (EST) Message-ID: <001501c40e64$8b081e20$af00a8c0@orange> From: "Matthew McGehrin" To: References: <004d01c40e53$3f8b8880$df0a0a0a@visionsix.net> Date: Sat, 20 Mar 2004 05:17:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) X-Spam-Status: No, hits=-4.0 required=4.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: Subject: Re: ping timeouts X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 10:17:36 -0000 I know you said you fixed your issue by replacing the switched. But your queue size is a bit extreme. Perhaps 8K or 10K would be better. ----- Original Message ----- From: "Lewis Watson" To: Sent: Saturday, March 20, 2004 3:13 AM Subject: ping timeouts > ${fwcmd} pipe 1 config bw 900Kbit/s queue 112Kbytes > ${fwcmd} pipe 2 config bw 900Kbit/s queue 112Kbytes From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 20 03:15:48 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF8B016A4CE; Sat, 20 Mar 2004 03:15:48 -0800 (PST) Received: from oahu.WURLDLINK.NET (oahu.wurldlink.net [66.193.144.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60D4C43D1D; Sat, 20 Mar 2004 03:15:48 -0800 (PST) (envelope-from vince@oahu.WURLDLINK.NET) Received: from oahu.WURLDLINK.NET (vince@localhost.WURLDLINK.NET [127.0.0.1]) by oahu.WURLDLINK.NET (8.12.9/8.12.9) with ESMTP id i2KBEdqQ002724; Sat, 20 Mar 2004 01:14:54 -1000 (HST) Received: from localhost (vince@localhost)i2KBEdWR002721; Sat, 20 Mar 2004 01:14:39 -1000 (HST) Date: Sat, 20 Mar 2004 01:14:38 -1000 (HST) From: Vincent Poy To: freebsd-ipfw@freebsd.org, Message-ID: <20040320011336.C8264-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Latency problem with traffic shaping (ipfw/dummynet) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 11:15:49 -0000 On this subject, I have one of my own... I have a 6.016Mbps/608kbps ADSL connection with 8 static IP's from my ISP. I'm using the FreeBSD box to basically limit my upstream bandwidth to 480kbps so that the downloads would work while uploading. In my kernel, I do have the following options: options IPFIREWALL #firewall options IPDIVERT #divert sockets options DUMMYNET options BRIDGE options HZ=1000 options NMBCLUSTERS=65536 The 8 IP's I'm using is 208.204.244.224-231 on a /24 block with the gateway on the other side at my ISP being 208.204.244.1. The FreeBSD machine is 208.204.244.224 and I do have gateway ip forwarding enabled. My problem is that while as far as speeds are concerned, it's working correctly on both the .224 (FreeBSD box) as well as the .225-.231 boxes behind it. The issue is that tracerouting from any box other than the FreeBSD box shows latencies of 1000+ms after the FreeBSD router beginning with hop 2 when the upstream pipe is being used while the FreeBSD box shows the latency at 40-50ms which is correct under traffic load. Anyone knows what's causing this or is this the way it's supposed to work? All the machines are pointing to .224 (FreeBSD box) as the gateway. All local traffic doesn't go through dummynet's queues. This is how I have ipfw configured. setup_loopback # Traffic Shaping for DSL connection 6.016Mbps/608Kbps # Make packets exiting dummynet not continue down the chain # If this is not enabled, then packets leaving an early # queue might enter a later queue if the conditions for # the later queue are met, which would be completely # devastating to all the prioritizing we're doing ${fwcmd} enable one_pass # Add rules so that local routable IP LAN traffic does not use natd ${fwcmd} add 39 divert natd all from 10.0.0.0/8 to any via ${natd_interface} ${fwcmd} add 40 divert natd all from 172.16.0.0/12 to any via ${natd_interface} ${fwcmd} add 41 divert natd all from 192.168.0.0/16 to any via ${natd_interface} ${fwcmd} add 42 divert natd all from 208.201.244.224/29 to 10.0.0.0/8 via ${natd_interface} ${fwcmd} add 43 divert natd all from 208.201.244.224/29 to 172.16.0.0/12 via ${natd_interface} ${fwcmd} add 44 divert natd all from 208.201.244.224/29 to 192.168.0.0/16 via ${natd_interface} ${fwcmd} add 45 divert natd all from any to 10.0.0.0/8 via ${natd_interface} ${fwcmd} add 46 divert natd all from any to 172.16.0.0/12 via ${natd_interface} ${fwcmd} add 47 divert natd all from any to 192.168.0.0/16 via ${natd_interface} ${fwcmd} add 48 divert natd all from any to 208.201.244.224/29 via ${natd_interface} ${fwcmd} add 49 skipto 100 ip from 208.201.244.224/29 to any ${fwcmd} add 50 divert natd all from any to any via ${natd_interface} ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any # Route LAN and RFC1918 networks without Traffic Shaping ${fwcmd} add 63000 allow all from any to 10.0.0.0/8 out ${fwcmd} add 63001 allow all from any to 172.16.0.0/12 out ${fwcmd} add 63002 allow all from any to 192.168.0.0/16 out ${fwcmd} add 63003 allow all from any to 208.201.244.224/29 out # Define our upload pipe ${fwcmd} pipe 1 config bw 480Kbit/s # Define a high-priority queue ${fwcmd} queue 1 config pipe 1 weight 100 # Define a medium-high-priority queue ${fwcmd} queue 2 config pipe 1 weight 99 # Define a medium-low-priority queue ${fwcmd} queue 3 config pipe 1 weight 98 # Define a low-priority queue ${fwcmd} queue 4 config pipe 1 weight 97 # Assign outgoing empty/small ACK packets to the high-priority queue ${fwcmd} add 63004 set 0 queue 1 tcp from any to any tcpflags ack iplen 0-80 out # Assign outgoing UDP (DNS/gaming) and SSH traffic to the medium-high-priority queue ${fwcmd} add 63005 set 0 queue 2 tcp from any to any 22,23 out ${fwcmd} add 63006 set 0 queue 2 udp from any to any not 80,443 out # Assign outgoing HTTP/HTTPS WEB traffic to the medium-low-priority queue ${fwcmd} add 63007 set 0 queue 3 all from any to any 80,443 out # Assign all other outgoing traffic to the low-priority queue ${fwcmd} add 63008 set 0 queue 4 all from any to any out # End of Traffic Shaping ${fwcmd} add 65000 pass all from any to any This is what the latencies look like on the machines behind the FreeBSD router when there is a upload: Tracing route to wurldlink.net [66.193.144.22] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms adsl-208-201-244-224.sonic.net [208.201.244.224] 2 915 ms 933 ms 1025 ms adsl-208-201-244-1.sonic.net [208.201.244.1] 3 1082 ms 1015 ms 1089 ms fast1-0-0.border.sr.sonic.net [208.201.224.194] 4 1206 ms 816 ms 869 ms fast0-0.gw.equinix-sj.sonic.net [64.142.0.14] 5 943 ms 1022 ms 1091 ms bpr1-t3-7-2-0.SanJoseEquinix.cw.net [208.173.54.45] 6 1095 ms 1044 ms 1112 ms cable-and-wireless-peering.SanJoseEquinix.cw.net [208.173.54.70] 7 1160 ms 1070 ms 1115 ms sl-bb25-sj-10-0.sprintlink.net [144.232.20.62] 8 891 ms 962 ms 1049 ms sl-bb20-sj-13-0.sprintlink.net [144.232.3.197] 9 960 ms 891 ms 1005 ms sl-bb20-stk-12-0.sprintlink.net [144.232.20.98] 10 1218 ms 1101 ms 1189 ms sl-bb20-prl-9-0.sprintlink.net [144.232.8.25] 11 811 ms 889 ms 979 ms sl-gw2-prl-0-0.sprintlink.net [144.232.30.22] 12 1002 ms 1070 ms 1164 ms sl-timewarner-12-0.sprintlink.net [160.81.200.214] 13 1065 ms 1062 ms 1080 ms 64-132-26-250.gen.twtelecom.net [64.132.26.250] 14 1173 ms 1098 ms 1155 ms kpext.ksbe.edu [216.136.57.178] 15 1092 ms 1108 ms 1209 ms www.onenet-usa.net [66.193.144.22] This is a traceroute directly from the FreeBSD box... traceroute to wurldlink.net (66.193.144.22), 64 hops max, 40 byte packets 1 adsl-208-201-244-1.sonic.net (208.201.244.1) 58.235 ms 57.779 ms 76.804 ms 2 fast1-0-0.border.sr.sonic.net (208.201.224.194) 38.449 ms 48.158 ms 48.871 ms 3 fast0-0.gw.equinix-sj.sonic.net (64.142.0.14) 60.951 ms 56.486 ms 49.452 ms 4 bpr1-t3-7-2-0.SanJoseEquinix.cw.net (208.173.54.45) 53.794 ms 52.463 ms 68.045 ms 5 cable-and-wireless-peering.SanJoseEquinix.cw.net (208.173.54.70) 78.437 ms 50.674 ms 46.528 ms 6 sl-bb25-sj-10-0.sprintlink.net (144.232.20.62) 52.491 ms 81.473 ms 54.669 ms 7 sl-bb20-sj-13-0.sprintlink.net (144.232.3.197) 67.872 ms 53.260 ms 65.417 ms 8 sl-bb20-stk-12-0.sprintlink.net (144.232.20.98) 81.940 ms 48.695 ms 59.650 ms 9 sl-bb20-prl-9-0.sprintlink.net (144.232.8.25) 118.604 ms 107.292 ms 136.087 ms 10 sl-gw2-prl-0-0.sprintlink.net (144.232.30.22) 124.988 ms 128.812 ms 129.594 ms 11 sl-timewarner-12-0.sprintlink.net (160.81.200.214) 126.898 ms 149.349 ms 114.960 ms 12 64-132-26-250.gen.twtelecom.net (64.132.26.250) 116.782 ms 140.489 ms 123.899 ms 13 kpext.ksbe.edu (216.136.57.178) 165.563 ms 131.212 ms 118.557 ms 14 www.onenet-usa.net (66.193.144.22) 155.675 ms 140.607 ms 175.878 ms Any ideas why the machines behind the FreeBSD box shows the 1000+ms latency after it reaches the FreeBSD box when the upstream pipe is being used but the speeds are working correctly? Thanks! Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 20 12:05:00 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CF7F16A4D3 for ; Sat, 20 Mar 2004 12:05:00 -0800 (PST) Received: from mordrede.visionsix.net (mordrede.visionsix.com [65.202.119.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32B0043D2D for ; Sat, 20 Mar 2004 12:04:58 -0800 (PST) (envelope-from lists@visionsix.com) Received: from vsis169 (unverified [65.202.119.169]) by mordrede.visionsix.net (Vircom SMTPRS 3.1.293.1) with SMTP id ; Sat, 20 Mar 2004 14:04:57 -0600 Message-ID: <007601c40eb6$987e3060$df0a0a0a@visionsix.net> From: "Lewis Watson" To: "Matthew McGehrin" , References: <004d01c40e53$3f8b8880$df0a0a0a@visionsix.net> <001501c40e64$8b081e20$af00a8c0@orange> Date: Sat, 20 Mar 2004 14:04:47 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: ping timeouts X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 20:05:00 -0000 > > ${fwcmd} pipe 1 config bw 900Kbit/s queue 112Kbytes > > ${fwcmd} pipe 2 config bw 900Kbit/s queue 112Kbytes > I know you said you fixed your issue by replacing the switched. > > But your queue size is a bit extreme. Perhaps 8K or 10K would be better. Hi Matthew. I am very new to creating pipes and queues and appreciate any insight you could give me with this. I based it off the thought that 900Kbit/s / 8 = 112.5 Kbytes What is the best way to determine queue size? I have done some testing such as downloading a 100MB file and at the same time pinging another host. I did not see any timeouts and speed was about what I expected so I felt comfortable with the queue size but I would like to have my network as efficient as possible. Please tell me the reasoning for 8K or 10K so I can learn. Thanks! Lewis From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 20 14:19:23 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7183B16A4CE; Sat, 20 Mar 2004 14:19:23 -0800 (PST) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D22343D3F; Sat, 20 Mar 2004 14:19:23 -0800 (PST) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.9p1/8.12.8) with ESMTP id i2KMJNRS007676; Sat, 20 Mar 2004 14:19:23 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.9p1/8.12.3/Submit) id i2KMJMks007675; Sat, 20 Mar 2004 14:19:22 -0800 (PST) (envelope-from rizzo) Date: Sat, 20 Mar 2004 14:19:22 -0800 From: Luigi Rizzo To: Vincent Poy Message-ID: <20040320141922.B7314@xorpc.icir.org> References: <20040320011336.C8264-100000@oahu.WURLDLINK.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: <20040320011336.C8264-100000@oahu.WURLDLINK.NET>; from vince@oahu.wurldlink.net on Sat, Mar 20, 2004 at 01:14:38AM -1000 cc: freebsd-ipfw@freebsd.org cc: questions@freebsd.org Subject: Re: Latency problem with traffic shaping (ipfw/dummynet) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 22:19:23 -0000 cannot comment on the reason for the huge delay (but one way to check what is going on is to change the pipe's bandwidth and see if anything changes), but i see a big misunderstanding on weights vs. priorities in your configuration: > # Define our upload pipe > ${fwcmd} pipe 1 config bw 480Kbit/s > # Define a high-priority queue > ${fwcmd} queue 1 config pipe 1 weight 100 > # Define a medium-high-priority queue > ${fwcmd} queue 2 config pipe 1 weight 99 > # Define a medium-low-priority queue > ${fwcmd} queue 3 config pipe 1 weight 98 > # Define a low-priority queue > ${fwcmd} queue 4 config pipe 1 weight 97 the above configuration means that if queue 1 is getting a bandwidth X, then queue 2 will get 0.99X, queue 3 will get 0.98X, queue 4 will get 0.97X. Hardly matching any reasonable definition of high-mid-low priority! cheers luigi From owner-freebsd-ipfw@FreeBSD.ORG Sat Mar 20 14:57:15 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A6AF16A4CE; Sat, 20 Mar 2004 14:57:15 -0800 (PST) Received: from oahu.WURLDLINK.NET (oahu.wurldlink.net [66.193.144.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4D2743D2D; Sat, 20 Mar 2004 14:57:14 -0800 (PST) (envelope-from vince@oahu.WURLDLINK.NET) Received: from oahu.WURLDLINK.NET (vince@localhost.WURLDLINK.NET [127.0.0.1]) by oahu.WURLDLINK.NET (8.12.9/8.12.9) with ESMTP id i2KMu9qQ017776; Sat, 20 Mar 2004 12:56:19 -1000 (HST) Received: from localhost (vince@localhost)i2KMu8KJ017773; Sat, 20 Mar 2004 12:56:08 -1000 (HST) Date: Sat, 20 Mar 2004 12:56:08 -1000 (HST) From: Vincent Poy To: Luigi Rizzo In-Reply-To: <20040320141922.B7314@xorpc.icir.org> Message-ID: <20040320124422.W8264-100000@oahu.WURLDLINK.NET> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-ipfw@freebsd.org cc: questions@freebsd.org Subject: Re: Latency problem with traffic shaping (ipfw/dummynet) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Mar 2004 22:57:15 -0000 On Sat, 20 Mar 2004, Luigi Rizzo wrote: > cannot comment on the reason for the huge delay (but one > way to check what is going on is to change the pipe's bandwidth > and see if anything changes), but i see a big > misunderstanding on weights vs. priorities in your > configuration: The delay only seems to be coming from machines behind the FreeBSD box and not the FreeBSD box itself since every box has static IP's, only the outgoing is via the FreeBSD box but the downstream is direct from the modem through the switch and then the machines directly. > > # Define our upload pipe > > ${fwcmd} pipe 1 config bw 480Kbit/s > > # Define a high-priority queue > > ${fwcmd} queue 1 config pipe 1 weight 100 > > # Define a medium-high-priority queue > > ${fwcmd} queue 2 config pipe 1 weight 99 > > # Define a medium-low-priority queue > > ${fwcmd} queue 3 config pipe 1 weight 98 > > # Define a low-priority queue > > ${fwcmd} queue 4 config pipe 1 weight 97 > > the above configuration means that if queue 1 is getting a bandwidth > X, then queue 2 will get 0.99X, queue 3 will get 0.98X, queue > 4 will get 0.97X. Hardly matching any reasonable definition of high-mid-low > priority! Hmm, I think I did it that way because 100 is the largest number and I didn't decide on how many queues I may add later so the numbers will change but does the weight number really mean 99%, 98%, 97% priority? So should it really be 66, 33, and 1? Cheers, Vince - vince@WURLDLINK.NET - Vice President ________ __ ____ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] WurldLink Corporation / / / / | / | __] ] San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____] Almighty1@IRC - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin