From owner-freebsd-ipfw Mon Mar 6 7:40:29 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from lk.tempest.sk (lk.tempest.sk [195.28.100.47]) by hub.freebsd.org (Postfix) with ESMTP id F349937BDAA for ; Mon, 6 Mar 2000 07:40:25 -0800 (PST) (envelope-from lk@tempest.sk) Received: (from koren@localhost) by lk.tempest.sk (8.9.3/8.9.3) id QAA32568; Mon, 6 Mar 2000 16:38:56 +0100 (CET) (envelope-from koren) Date: Mon, 6 Mar 2000 16:38:56 +0100 (CET) Message-Id: <200003061538.QAA32568@lk.tempest.sk> From: Ludo Koren To: robert+freebsd@cyrus.watson.org Cc: luigi@info.iet.unipi.it, ipfw@FreeBSD.ORG In-reply-to: (message from Robert Watson on Fri, 3 Mar 2000 19:00:38 -0500 (EST)) Subject: Re: ipdivert and ethernet bridging Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I have a 3.4-STABLE box which I have enabled ethernet > bridging, bridging and ipfw, and also ipdivert, as I would > like to transform/process some packets as they pass through > the bridge using a userland process. However, the results so > far seem not to be good--while the packet due indeed disappear > from processing at the divert rule, they never reappear > following it, or reach the userland process :-(. Packets > originating locally on the bridge box seem to be processed > fine. > I was wondering if you had any thoughts on whether this should > be something that works, or how I could get it to work? I'm > not averse to using -current instead, if necessary. I have a patch for bridge. I am using forwarding to redirect packets for squid. So far it is working well. If you are interested I can send you the patch. ludo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Mar 6 7:52:44 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E68A937BDD4 for ; Mon, 6 Mar 2000 07:52:40 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id KAA12316; Mon, 6 Mar 2000 10:53:28 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Mar 2000 10:53:28 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Ludo Koren Cc: luigi@info.iet.unipi.it, ipfw@FreeBSD.ORG Subject: Re: ipdivert and ethernet bridging In-Reply-To: <200003061538.QAA32568@lk.tempest.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ludo, I would be very interested in this code. While I probably could develop it myself, I'd really rather not :-). Presumably you pull the same tricks that the normal ip_input code does for reassembly appropriate-looking packets, etc, etc. On Mon, 6 Mar 2000, Ludo Koren wrote: > > > I have a 3.4-STABLE box which I have enabled ethernet > > bridging, bridging and ipfw, and also ipdivert, as I would > > like to transform/process some packets as they pass through > > the bridge using a userland process. However, the results so > > far seem not to be good--while the packet due indeed disappear > > from processing at the divert rule, they never reappear > > following it, or reach the userland process :-(. Packets > > originating locally on the bridge box seem to be processed > > fine. > > > I was wondering if you had any thoughts on whether this should > > be something that works, or how I could get it to work? I'm > > not averse to using -current instead, if necessary. > > > I have a patch for bridge. I am using forwarding to redirect packets > for squid. So far it is working well. If you are interested I can send > you the patch. > > ludo > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Mar 6 9:15:51 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from lk.tempest.sk (lk.tempest.sk [195.28.100.47]) by hub.freebsd.org (Postfix) with ESMTP id 78E2237BE4F for ; Mon, 6 Mar 2000 09:15:46 -0800 (PST) (envelope-from lk@tempest.sk) Received: (from koren@localhost) by lk.tempest.sk (8.9.3/8.9.3) id SAA35436; Mon, 6 Mar 2000 18:15:06 +0100 (CET) (envelope-from koren) Date: Mon, 6 Mar 2000 18:15:06 +0100 (CET) Message-Id: <200003061715.SAA35436@lk.tempest.sk> From: Ludo Koren To: robert+freebsd@cyrus.watson.org Cc: luigi@info.iet.unipi.it, ipfw@FreeBSD.ORG In-reply-to: (message from Robert Watson on Mon, 6 Mar 2000 10:53:28 -0500 (EST)) Subject: Re: ipdivert and ethernet bridging Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Ludo, > I would be very interested in this code. While I probably > could develop it myself, I'd really rather not :-). > Presumably you pull the same tricks that the normal ip_input > code does for reassembly appropriate-looking packets, etc, etc. The patch follows. Comments are welcomed. ludo Index: src/sys/net/bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/bridge.c,v retrieving revision 1.4.2.6 diff -c -r1.4.2.6 bridge.c *** bridge.c 2000/01/18 14:07:13 1.4.2.6 --- bridge.c 2000/03/06 17:04:54 *************** *** 645,650 **** --- 645,651 ---- struct ip_fw_chain *rule = NULL ; int off; struct ip *ip ; + extern struct sockaddr_in *ip_fw_fwd_addr; m = *m0 ; #ifdef DUMMYNET *************** *** 708,714 **** * The third parameter to the firewall code is the dst. interface. * Since we apply checks only on input pkts we use NULL. */ ! off = (*ip_fw_chk_ptr)(NULL, 0, NULL, &dummy, &m, &rule, NULL) ; if (m == NULL) { /* pkt discarded by firewall */ /* --- 709,715 ---- * The third parameter to the firewall code is the dst. interface. * Since we apply checks only on input pkts we use NULL. */ ! off = (*ip_fw_chk_ptr)(NULL, 0, NULL, &dummy, &m, &rule, &ip_fw_fwd_addr) ; if (m == NULL) { /* pkt discarded by firewall */ /* *************** *** 719,724 **** --- 720,747 ---- if (canfree) *m0 = NULL ; return 0 ; + } + + if (ip_fw_fwd_addr != NULL) { + eh = mtod(m, struct ether_header *); + ip = (struct ip *)(eh + 1); + + HTONS(ip->ip_len); + HTONS(ip->ip_id); + HTONS(ip->ip_off); + + m_adj(m, sizeof(struct ether_header)); + ip_input(m); + ip_fw_fwd_addr = NULL; + + /* cleanup any mbuf leftover. */ + if (m == *m0) + *m0 = NULL ; + if (canfree && *m0) { + m_freem(*m0); + *m0 = NULL ; + } + return 0; } /* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Mar 6 9:57:32 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 49E8D37BE72 for ; Mon, 6 Mar 2000 09:57:28 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id SAA57984; Mon, 6 Mar 2000 18:56:00 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200003061756.SAA57984@info.iet.unipi.it> Subject: Re: ipdivert and ethernet bridging In-Reply-To: <200003061715.SAA35436@lk.tempest.sk> from Ludo Koren at "Mar 6, 2000 06:15:06 pm" To: Ludo Koren Date: Mon, 6 Mar 2000 18:56:00 +0100 (CET) Cc: robert+freebsd@cyrus.watson.org, ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > The patch follows. Comments are welcomed. I had a slightly different solution in mind. In my design, a match in a "divert" rule would make bdg_forward return a special code so that the packet would appear as destined for the local interface and passed to the upper layer (hence calling ip_input() etc.). While your approach is more compact i see some potential problems: 1) a packet destined to a local address probably ends up being duplicated, as it gets diverted once in bdg_forward(), and once again when it goes to ether_input() and up. Duplicates are discarded by TCP so things might work without problem except performance. 2) packets diverted like this bypass the ipintrq queue, which is probably not a problem at all but worth mentioning. cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) Mobile +39-347-0373137 -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Mar 6 18:25:48 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id EF76937BE25 for ; Mon, 6 Mar 2000 18:25:45 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id VAA16734; Mon, 6 Mar 2000 21:26:29 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Mon, 6 Mar 2000 21:26:29 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Luigi Rizzo Cc: Ludo Koren , ipfw@FreeBSD.ORG Subject: Re: ipdivert and ethernet bridging In-Reply-To: <200003061756.SAA57984@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi, I've been reading through the bridge/ipfw code, and can't seem to find a place where eh->ether_type is checked to see if it is ETHERTYPE_IP before the firewall rules are evaluated. I was wondering if the check is not taking place, or if so, where it takes place? net/bridge.c: ... /* * before calling the firewall, swap fields the same as IP does. * here we assume the pkt is an IP one and the header is contiguous */ eh = mtod(m, struct ether_header *); ip = (struct ip *)(eh + 1 ) ; NTOHS(ip->ip_len); NTOHS(ip->ip_id); NTOHS(ip->ip_off); ... Thanks, Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Mar 6 19:59:53 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from atlas.usls.edu (atlas.usls.edu [202.47.133.46]) by hub.freebsd.org (Postfix) with ESMTP id 2AE5037BD03 for ; Mon, 6 Mar 2000 19:59:44 -0800 (PST) (envelope-from francis@usls.edu) Received: by atlas.usls.edu (Postfix, from userid 1001) id C0FCC9B1D; Tue, 7 Mar 2000 11:59:11 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by atlas.usls.edu (Postfix) with ESMTP id B54EB5D17 for ; Tue, 7 Mar 2000 11:59:11 +0800 (PHT) Date: Tue, 7 Mar 2000 11:59:11 +0800 (PHT) From: "Francis A. Vidal" To: FreeBSD IPFW Subject: howto Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I'm about to build a firewall using FreeBSD 4.0RC2 and I want to know if there are pointers available on the web on how to build one. My setup -------- [internet]---[router]---[switch] | | | +---[office network] | +---[public servers] | +---[workstations w/ private IPs] i want to block off some traffic (and probably limit the bandwidth) in between the switch and office network. i only want the office workstations to access ports 80, 443, 563, 3128, 21, and 25. there's one workstation in the office network that has a public IP address that i want to exclude from the policy. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Mon Mar 6 21:15:31 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0514837BE0B for ; Mon, 6 Mar 2000 21:15:29 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id AAA17230; Tue, 7 Mar 2000 00:16:36 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Mar 2000 00:16:36 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Luigi Rizzo Cc: Ludo Koren , ipfw@FreeBSD.ORG Subject: Re: ipdivert and ethernet bridging In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Aha, found it in ip_fw_chk, only the check is done after twiddling the various parts of the IP header, not before... :-) On Mon, 6 Mar 2000, Robert Watson wrote: > > Luigi, > > I've been reading through the bridge/ipfw code, and can't seem to find a > place where eh->ether_type is checked to see if it is ETHERTYPE_IP before > the firewall rules are evaluated. I was wondering if the check is not > taking place, or if so, where it takes place? > > net/bridge.c: > ... > /* > * before calling the firewall, swap fields the same as IP does. > * here we assume the pkt is an IP one and the header is > contiguous > */ > eh = mtod(m, struct ether_header *); > ip = (struct ip *)(eh + 1 ) ; > NTOHS(ip->ip_len); > NTOHS(ip->ip_id); > NTOHS(ip->ip_off); > ... > > Thanks, > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 7 0:25:47 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 5021337BDCF for ; Tue, 7 Mar 2000 00:25:36 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id JAA60597; Tue, 7 Mar 2000 09:24:17 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200003070824.JAA60597@info.iet.unipi.it> Subject: Re: ipdivert and ethernet bridging In-Reply-To: from Robert Watson at "Mar 7, 2000 00:16:36 am" To: Robert Watson Date: Tue, 7 Mar 2000 09:24:17 +0100 (CET) Cc: Ludo Koren , ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Aha, found it in ip_fw_chk, only the check is done after twiddling the > various parts of the IP header, not before... :-) you are right, the check should be done earlier. I think it does not harm too much to do things like this now (hopefully) because the header is restored afterwards in all cases. Will check this. In an ideal world, the bridging code should call *fw_chk() depending on packet type... cheers luigi > On Mon, 6 Mar 2000, Robert Watson wrote: > > > > > Luigi, > > > > I've been reading through the bridge/ipfw code, and can't seem to find a > > place where eh->ether_type is checked to see if it is ETHERTYPE_IP before > > the firewall rules are evaluated. I was wondering if the check is not > > taking place, or if so, where it takes place? > > > > net/bridge.c: > > ... > > /* > > * before calling the firewall, swap fields the same as IP does. > > * here we assume the pkt is an IP one and the header is > > contiguous > > */ > > eh = mtod(m, struct ether_header *); > > ip = (struct ip *)(eh + 1 ) ; > > NTOHS(ip->ip_len); > > NTOHS(ip->ip_id); > > NTOHS(ip->ip_off); > > ... > > > > Thanks, > > > > Robert N M Watson > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > TIS Labs at Network Associates, Safeport Network Services > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-ipfw" in the body of the message > > > > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 7 3:33:48 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from alpha.cnc.una.py (alpha.cnc.una.py [200.10.228.103]) by hub.freebsd.org (Postfix) with ESMTP id 427E037BCE3 for ; Tue, 7 Mar 2000 03:33:37 -0800 (PST) (envelope-from jsegovia@alpha.cnc.una.py) Received: from jss ([200.10.228.69]) by alpha.cnc.una.py (8.9.3/8.9.3) with ESMTP id IAA28808; Tue, 7 Mar 2000 08:33:45 -0400 (GMT-0400) Message-Id: <200003071233.IAA28808@alpha.cnc.una.py> From: jsegovia@cnc.una.py To: Luigi Rizzo Date: Tue, 7 Mar 2000 08:34:57 -0400 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: keep-state and fwd Cc: freebsd-ipfw@FreeBSD.ORG In-reply-to: <200002291751.SAA32091@info.iet.unipi.it> References: <200002251834.OAA26064@alpha.cnc.una.py> from "jsegovia@cnc.una.py" at "Feb 25, 2000 02:35:29 pm" X-mailer: Pegasus Mail for Win32 (v3.12a) Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > ok, just committed a fix on -current, code for -stable should > follow shortly. > > Now it works as expected for both local and externally initiated > connections. > > Please try it out Everything seems to be working correctly. Thanks! Juan -- Centro Nacional de Computacion Universidad Nacional de Asuncion Tel. +595 (21) 585 550 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 7 11:58:22 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from vcnet.com (mail.vcnet.com [209.239.239.15]) by hub.freebsd.org (Postfix) with SMTP id DEC8137BDF4 for ; Tue, 7 Mar 2000 11:58:19 -0800 (PST) (envelope-from jpr@vcnet.com) Received: (qmail 56585 invoked from network); 7 Mar 2000 19:58:17 -0000 Received: from joff.vc.net (HELO ?209.239.239.22?) (209.239.239.22) by mail.vcnet.com with SMTP; 7 Mar 2000 19:58:17 -0000 Mime-Version: 1.0 Message-Id: Date: Tue, 7 Mar 2000 11:58:20 -0800 To: freebsd-ipfw@freebsd.org From: Jon Rust Subject: ipfw, natd and dialpad Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On dialpad.com's faq page they say I can issue the following ruleset to ipmaswadm to apparently enable forwarding of received packets to the correct internal host: /usr/sbin/ipmasqadm autofw -A -v -u -r udp 51200 51201 -c tcp 7175 /usr/sbin/ipmasqadm autofw -A -v -u -r tcp 51210 51210 -c tcp 7175 I don't see that there is a way to do this with natd and ipfw, but wanted to check to be sure. Can ipfilter do it? Just curious really. jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 7 12:30:36 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 74FE137BDC3; Tue, 7 Mar 2000 12:30:18 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id PAA21258; Tue, 7 Mar 2000 15:31:11 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Mar 2000 15:31:10 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Luigi Rizzo Cc: jkh@freebsd.org, freebsd-ipfw@freebsd.org Subject: fix to bridging code--m_dup instead of m_copypacket Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luigi, I patched support for bridging into if_dc.c and discovered a problem--broadcast packets were being correctly bridged, but were not being delivered to the bridge itself (?). It looks like some interface output code modifies the packet in-place, and copies for per-interface delivery were made using m_copypacket instead of m_dup. Changing the code to use m_dup instead appeared to work correctly. I'm not sure why the packet is getting modified in-place, as it goes out on the bridged segment with the broadcast address. Also, it introduces an extra copy for each interface a packet is delivered to, which can be large if your MAC address working set exceeds the address hash, etc. However, it seems to make things much more stable from the perspective of communicating with the bridge box. Here's the patch against -current, which I'd like to commit before the release if it looks OK by you. I'd also like to commit bridge support for if_dc.c, which prompted me to discover this problem. Assuming this fix is good, I'll do that as a followup. Index: bridge.c =================================================================== RCS file: /home/ncvs/src/sys/net/bridge.c,v retrieving revision 1.16 diff -u -r1.16 bridge.c --- bridge.c 2000/02/08 14:53:55 1.16 +++ bridge.c 2000/03/07 20:16:33 @@ -788,10 +788,10 @@ if (canfree && once ) { /* no need to copy */ m = *m0 ; *m0 = NULL ; /* original is gone */ - } else /* on a P5-90, m_copypacket takes 540 ticks */ - m = m_copypacket(*m0, M_DONTWAIT); + } else + m = m_dup(*m0, M_DONTWAIT); if (m == NULL) { - printf("bdg_forward: sorry, m_copy failed!\n"); + printf("bdg_forward: sorry, m_dup failed!\n"); return ENOBUFS ; /* the original is still there... */ } /* Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 7 12:34:58 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id E124637B6BC; Tue, 7 Mar 2000 12:34:54 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id PAA21281; Tue, 7 Mar 2000 15:36:04 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Mar 2000 15:36:04 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Luigi Rizzo Cc: jkh@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: fix to bridging code--m_dup instead of m_copypacket In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On further inspection, the bug still seems to be occurring, although it took more to break bridging (previously a short flood ping at the bridge hosts's IP address would break it, now it takes a long one). The symptom is that the bridge host stops responding to broadcasts, and inspection of the mbuf in kernel using a debugger shows that following bdg_forward, before ether_input is called, the destination ethernet address in the packet is rewritten, resulting in ether_input rejecting the packet as not destined for the local host, although bridge_in() did return BDG_BCAST. I had assumed that the interface output routines in bdg_forward() were stomping the value (hence switching to m_duping before sending the mbuf to the output routine), but the problem appears to remain. I'm going to play with it some more, but was wondering if you had seen this behavior before? On Tue, 7 Mar 2000, Robert Watson wrote: > > Luigi, > > I patched support for bridging into if_dc.c and discovered a > problem--broadcast packets were being correctly bridged, but were not > being delivered to the bridge itself (?). It looks like some interface > output code modifies the packet in-place, and copies for per-interface > delivery were made using m_copypacket instead of m_dup. Changing the code > to use m_dup instead appeared to work correctly. I'm not sure why the > packet is getting modified in-place, as it goes out on the bridged segment > with the broadcast address. Also, it introduces an extra copy for each > interface a packet is delivered to, which can be large if your MAC address > working set exceeds the address hash, etc. However, it seems to make > things much more stable from the perspective of communicating with the > bridge box. > > Here's the patch against -current, which I'd like to commit before the > release if it looks OK by you. I'd also like to commit bridge support for > if_dc.c, which prompted me to discover this problem. Assuming this fix is > good, I'll do that as a followup. > > Index: bridge.c > =================================================================== > RCS file: /home/ncvs/src/sys/net/bridge.c,v > retrieving revision 1.16 > diff -u -r1.16 bridge.c > --- bridge.c 2000/02/08 14:53:55 1.16 > +++ bridge.c 2000/03/07 20:16:33 > @@ -788,10 +788,10 @@ > if (canfree && once ) { /* no need to copy */ > m = *m0 ; > *m0 = NULL ; /* original is gone */ > - } else /* on a P5-90, m_copypacket takes 540 ticks */ > - m = m_copypacket(*m0, M_DONTWAIT); > + } else > + m = m_dup(*m0, M_DONTWAIT); > if (m == NULL) { > - printf("bdg_forward: sorry, m_copy failed!\n"); > + printf("bdg_forward: sorry, m_dup failed!\n"); > return ENOBUFS ; /* the original is still there... */ > } > /* > > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 7 14:26:41 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6F51D37B836 for ; Tue, 7 Mar 2000 14:26:36 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id RAA21744; Tue, 7 Mar 2000 17:27:44 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 7 Mar 2000 17:27:43 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Luigi Rizzo Cc: freebsd-ipfw@freebsd.org Subject: Re: fix to bridging code--m_dup instead of m_copypacket In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On yet more inspection, it looks like the problem is that bdg_forward() makes mbuf-related calls that rearrange the mbuf buffers, alignment, etc, and if calling code from the interface driver has any pointers cast from the contents of the mbuf, then those pointers will be incorrect following the return of bdg_forward(). In the if_dc driver, a struct ether_header was retrieved using mtod(), and following the bridge call, it no longer pointed to the right data, resulting in the code that followed seeing it as a non-broadcast ethernet address and dropping it. if_xl.c and if_ed.c also use mtod before and after calls to bdg_forward and might suffer from the same problem. if_de.c seems to copy out the ethernet header before the call, and uses the copy for its call to ether_input() and friends; if_ed casts also, but based on its ring buffer, so I'm not sure what the results would be. Either way, the flawed assumption seems to be that the mbuf will remain somewhat the same in structure at the end of the bridge calls, which is clearly not true :-). Recasting following the bridge call eh = mtod(m, struct ether_header *); seems to clear things up. I don't have the various other ethernet devices, so am unable to test to see if this is an issue, but suspect it might be. The problem only arose after a fair amount of network use, so presumably has to do with long term mbuf-allocation trends, et al. Robert On Tue, 7 Mar 2000, Robert Watson wrote: > > On further inspection, the bug still seems to be occurring, although it > took more to break bridging (previously a short flood ping at the bridge > hosts's IP address would break it, now it takes a long one). > > The symptom is that the bridge host stops responding to broadcasts, and > inspection of the mbuf in kernel using a debugger shows that following > bdg_forward, before ether_input is called, the destination ethernet > address in the packet is rewritten, resulting in ether_input rejecting the > packet as not destined for the local host, although bridge_in() did return > BDG_BCAST. I had assumed that the interface output routines in > bdg_forward() were stomping the value (hence switching to m_duping before > sending the mbuf to the output routine), but the problem appears to > remain. > > I'm going to play with it some more, but was wondering if you had seen > this behavior before? > > > On Tue, 7 Mar 2000, Robert Watson wrote: > > > > > Luigi, > > > > I patched support for bridging into if_dc.c and discovered a > > problem--broadcast packets were being correctly bridged, but were not > > being delivered to the bridge itself (?). It looks like some interface > > output code modifies the packet in-place, and copies for per-interface > > delivery were made using m_copypacket instead of m_dup. Changing the code > > to use m_dup instead appeared to work correctly. I'm not sure why the > > packet is getting modified in-place, as it goes out on the bridged segment > > with the broadcast address. Also, it introduces an extra copy for each > > interface a packet is delivered to, which can be large if your MAC address > > working set exceeds the address hash, etc. However, it seems to make > > things much more stable from the perspective of communicating with the > > bridge box. > > > > Here's the patch against -current, which I'd like to commit before the > > release if it looks OK by you. I'd also like to commit bridge support for > > if_dc.c, which prompted me to discover this problem. Assuming this fix is > > good, I'll do that as a followup. > > > > Index: bridge.c > > =================================================================== > > RCS file: /home/ncvs/src/sys/net/bridge.c,v > > retrieving revision 1.16 > > diff -u -r1.16 bridge.c > > --- bridge.c 2000/02/08 14:53:55 1.16 > > +++ bridge.c 2000/03/07 20:16:33 > > @@ -788,10 +788,10 @@ > > if (canfree && once ) { /* no need to copy */ > > m = *m0 ; > > *m0 = NULL ; /* original is gone */ > > - } else /* on a P5-90, m_copypacket takes 540 ticks */ > > - m = m_copypacket(*m0, M_DONTWAIT); > > + } else > > + m = m_dup(*m0, M_DONTWAIT); > > if (m == NULL) { > > - printf("bdg_forward: sorry, m_copy failed!\n"); > > + printf("bdg_forward: sorry, m_dup failed!\n"); > > return ENOBUFS ; /* the original is still there... */ > > } > > /* > > > > > > Robert N M Watson > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > TIS Labs at Network Associates, Safeport Network Services > > > > > > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 7 14:34:18 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from bb1.betterbox.net (bb1.betterbox.net [209.83.132.66]) by hub.freebsd.org (Postfix) with ESMTP id 7D62237B540 for ; Tue, 7 Mar 2000 14:34:13 -0800 (PST) (envelope-from better@betterbox.net) Received: from [10.1.5.111] (guardian.epconline.net [216.178.14.38]) by bb1.betterbox.net (8.9.3/8.9.3) with ESMTP id OAA79977 for ; Tue, 7 Mar 2000 14:49:56 -0600 (CST) (envelope-from better@betterbox.net) Message-Id: Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" Date: Tue, 7 Mar 2000 14:51:22 -0600 To: freebsd-ipfw@FreeBSD.ORG From: Joong Kim Subject: Re: ipfw, natd and dialpad Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >On dialpad.com's faq page they say I can issue the following ruleset >to ipmaswadm to apparently enable forwarding of received packets to >the correct internal host: > > /usr/sbin/ipmasqadm autofw -A -v -u -r udp 51200 51201 -c tcp 7175 > /usr/sbin/ipmasqadm autofw -A -v -u -r tcp 51210 51210 -c tcp 7175 > >I don't see that there is a way to do this with natd and ipfw, but >wanted to check to be sure. Can ipfilter do it? Just curious really. > >jon > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-ipfw" in the body of the message Jon, You would probably want to do this using natd's redirect_port From man natd: -redirect_port proto targetIP:targetPORT[-targetPORT] [aliasIP:]alias- PORT[-aliasPORT] [remoteIP[:remotePORT[-remotePORT]]] Redirect incoming connections arriving to given port(s) to another host and port(s). Proto is either tcp or udp, tar- getIP is the desired target IP number, targetPORT is the de- sired target PORT number or range, aliasPORT is the requested PORT number or range, and aliasIP is the aliasing address. RemoteIP and remotePORT can be used to specify the connection more accurately if necessary. The targetPORT range and aliasPORT range need not be the same numerically, but must have the same size. If remotePORT is not specified, it is assumed to be all ports. If remotePORT is specified, it must match the size of targetPORT, or be 0 (all ports). For exam- ple, the argument tcp inside1:telnet 6666 means that tcp packets destined for port 6666 on this machine will be sent to the telnet port on the inside1 machine. tcp inside2:2300-2399 3300-3399 will redirect incoming connections on ports 3300-3399 to host inside2, ports 2300-2399. The mapping is 1:1 meaning port 3300 maps to 2300, 3301 maps to 2301, etc. From dialpad's FAQ: I have a private network, how can I use Dialpad?? If you have a private network, even though you can call someone, you wouldn't be able to hear the remote end. This is because the incoming voice packets cannot find its way to the PC without a valid (public) IP address. In order to use Dialpad on a private network, you have to map the incoming ports on the server. You have to map the following incoming ports UDP: 51200, 51201 TCP: 51210 If you need a trigger for them, use TCP: 7175 (outgoing) Here's what you would need to setup: i.e. Let's say that 10.1.5.47 is the internal workstation. Then you would setup the following in natd.cf (/usr/src/sbin/natd/samples/natd.cf.sample) file: redirect_port tcp 10.1.5.47:51210 51210 redirect_port udp 10.1.5.47:51200-51201 51200-51201 redirect_port tcp 10.1.5.47:7175 7175 I hope this helps! :-) Of course, you would need to setup the other settings correctly in natd.cf and run natd like this and put flags for natd in rc.conf, natd_flags="-f /etc/natd.cf" natd -f /etc/natd.cf -Joong Kim EPC, Inc. better@betterbox.net +---------------------------+---------------------------------+ | Joong Hyun Kim | BetterBOX.net | | System Administrator | http://www.betterbox.net/ | +---------------------------+---------------------------------+ | The "BETTER" place to host your mud and web site! | +-------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 8 2:14:49 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 3D3ED37B59A for ; Wed, 8 Mar 2000 02:14:44 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id LAA65647; Wed, 8 Mar 2000 11:13:25 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200003081013.LAA65647@info.iet.unipi.it> Subject: Re: fix to bridging code--m_dup instead of m_copypacket In-Reply-To: from Robert Watson at "Mar 7, 2000 05:27:43 pm" To: Robert Watson Date: Wed, 8 Mar 2000 11:13:25 +0100 (CET) Cc: freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > On yet more inspection, it looks like the problem is that bdg_forward() > makes mbuf-related calls that rearrange the mbuf buffers, alignment, etc, > and if calling code from the interface driver has any pointers cast from you spotted the problem. I think i fixed this in the -stable branch (probably in "ed" and "fxp" drivers) but maybe i forgot to fix the version in -current. "de" is currently broken for bridging i believe. I hope i can give a sweep to the network interfaces before monday. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 8 4:12:44 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from beta.chem.msu.ru (beta.chem.msu.ru [195.208.208.11]) by hub.freebsd.org (Postfix) with ESMTP id 6A4DA37B78D for ; Wed, 8 Mar 2000 04:12:37 -0800 (PST) (envelope-from aospan@fds.chem.msu.ru) Received: (from uucp@localhost) by beta.chem.msu.ru (8.9.3/8.9.3) with UUCP id PAA04917 for ipfw@FreeBSD.ORG; Wed, 8 Mar 2000 15:12:26 +0300 (MSK) Received: from ws537 (ws537.fds.chem.msu.ru [10.4.3.137]) by fds.chem.msu.ru (8.9.1/8.9.1) with SMTP id OAA26598 for ; Wed, 8 Mar 2000 14:58:07 +0300 (MSK) (envelope-from aospan@fds.chem.msu.ru) Message-ID: <006201bf88f5$864977b0$8903040a@fds.chem.msu.ru> From: "Abylai Ospan aka chemist" To: Subject: divert or forward ? Date: Wed, 8 Mar 2000 14:57:48 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01BF890E.AB5C8CE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2417.2000 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_005F_01BF890E.AB5C8CE0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi, All ! I have two running web servers on the same machine (ports 80 and 8000 = accordingly). Soft: FreeBSD 3.0 + Apache/1.3.9 + ipfw (with divert = enabled, rule-based forwarding enabled).=20 I want to make the following thing: Somebody (from specific IP) see port = 8000 web server, when he try to connect on port 80. Can I make it whith divert or forward ?=20 I have tryed this lines: /sbin/ipfw add 1 divert 8000 tcp from 'someIP' to 'myIP' 80=20 or /sbin/ipfw add 1 fwd 'myIP',8000 tcp from 'someIP' to 'myIP' 80 Yours faithfully ------=_NextPart_000_005F_01BF890E.AB5C8CE0 Content-Type: text/html; charset="koi8-r" Content-Transfer-Encoding: quoted-printable
Hi, All !
 
I have two running web = servers=20 on the same machine (ports 80 and 8000 accordingly). Soft: FreeBSD = 3.0 +=20 Apache/1.3.9 + ipfw (with divert enabled, rule-based forwarding = enabled).=20
I want to make the following = thing: Somebody=20 (from specific IP) see port 8000 web server,  = when he try=20 to connect on port 80.
Can I make it whith divert or = forward ?=20
 
I have tryed this = lines:
/sbin/ipfw add 1 divert 8000 tcp = from=20 'someIP' to 'myIP' 80
or
/sbin/ipfw add 1 fwd 'myIP',8000 = tcp from=20 'someIP' to 'myIP' 80
 
 
Yours faithfully
 
------=_NextPart_000_005F_01BF890E.AB5C8CE0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 8 15:57:13 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from vcnet.com (mail.vcnet.com [209.239.239.15]) by hub.freebsd.org (Postfix) with SMTP id BEEE637B6AB for ; Wed, 8 Mar 2000 15:57:06 -0800 (PST) (envelope-from jpr@vcnet.com) Received: (qmail 31032 invoked from network); 8 Mar 2000 23:57:04 -0000 Received: from joff.vc.net (HELO ?209.239.239.22?) (209.239.239.22) by mail.vcnet.com with SMTP; 8 Mar 2000 23:57:04 -0000 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 8 Mar 2000 15:57:09 -0800 To: freebsd-ipfw@FreeBSD.ORG From: Jon Rust Subject: Re: ipfw, natd and dialpad Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I guess I didn't explain very well. :-) -redirect_port will work for static mappings. I have no problem with that. But let's say i have a lan with 10 computers, heck even just 2 computers. It would appear there is no way to make dialpad.com work for all computers at the same time. However, with linux's ipmasqadm, it appears that there is a way. It uses outgoing connections to port 7175 to trigger a mapping for returning traffic to ports 51200, 51201, etc. Well, that's what I gathered from the config snippet. I don't have access to a linux box so I can't test out. If ipfw can do this, I'd love to see how. (Not bashing ipfw-- an honest question.) jon >>>original email follows At 2:51 PM -0600 3/7/00, Joong Kim wrote: >On dialpad.com's faq page they say I can issue the following ruleset >to ipmaswadm to apparently enable forwarding of received packets to >the correct internal host: > > /usr/sbin/ipmasqadm autofw -A -v -u -r udp 51200 51201 -c tcp 7175 > /usr/sbin/ipmasqadm autofw -A -v -u -r tcp 51210 51210 -c tcp 7175 > >I don't see that there is a way to do this with natd and ipfw, but >wanted to check to be sure. Can ipfilter do it? Just curious really. > >jon > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-ipfw" in the body of the message Jon, You would probably want to do this using natd's redirect_port To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Mar 9 22:46: 9 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from MailAndNews.com (MailAndNews.com [199.29.68.160]) by hub.freebsd.org (Postfix) with ESMTP id E8A6C37B6FA for ; Thu, 9 Mar 2000 22:46:06 -0800 (PST) (envelope-from mheffner@mailandnews.com) Received: from muriel.penguinpowered.com [208.138.199.76] (mheffner@mailandnews.com); Fri, 10 Mar 2000 01:46:02 -0500 X-WM-Posted-At: MailAndNews.com; Fri, 10 Mar 00 01:46:02 -0500 Content-Length: 913 Message-ID: X-Mailer: XFMail 1.4.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Fri, 10 Mar 2000 01:46:34 -0500 (EST) Reply-To: Mike Heffner From: Mike Heffner To: freebsd-ipfw@freebsd.org Subject: ipfw doesn't match when src == dest Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, When I recently redid my firewall, I wanted to block a strange packet from my cablemodem, Deny P:2 192.168.100.1 192.168.100.1 in via ed1 as you can see, the source equals the destination. When I installed the ipfw rule below, it wouldn't match the packet: 00146 0 0 deny log ip from 192.168.100.1 to 192.168.100.1 via ed1 But when I change the rule to this: 00146 0 0 deny log ip from 192.168.100.1 to any via ed1 it'll match the packet and deny it correctly. Has anyone else noticed this, or have I got this confused somehow? I'm planning to look into it a little further, but just wondered if anyone had any ideas offhand. Later, /**************************************** * Mike Heffner * * Fredericksburg, VA -- ICQ# 882073 * * Sent at: 10-Mar-2000 -- 01:37:17 EST * * http://my.ispchannel.com/~mheffner * ****************************************/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Mar 10 3:38: 5 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (Postfix) with ESMTP id 9CF9E37B9A5 for ; Fri, 10 Mar 2000 03:37:59 -0800 (PST) (envelope-from luigi@info.iet.unipi.it) Received: (from luigi@localhost) by info.iet.unipi.it (8.9.3/8.9.3) id MAA75621; Fri, 10 Mar 2000 12:36:43 +0100 (CET) (envelope-from luigi) From: Luigi Rizzo Message-Id: <200003101136.MAA75621@info.iet.unipi.it> Subject: Re: ipfw doesn't match when src == dest In-Reply-To: from Mike Heffner at "Mar 10, 2000 01:46:34 am" To: Mike Heffner Date: Fri, 10 Mar 2000 12:36:42 +0100 (CET) Cc: freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hello, > > When I recently redid my firewall, I wanted to block a strange packet from my > cablemodem, > > Deny P:2 192.168.100.1 192.168.100.1 in via ed1 are you sure that the logging code prints the right thing ? I noticed (from source code analysis) it does strange things with fragments, it might as well misbehave with short packets etc. cheers luigi > as you can see, the source equals the destination. When I installed the ipfw > rule below, it wouldn't match the packet: > > 00146 0 0 deny log ip from 192.168.100.1 to 192.168.100.1 via ed1 > > But when I change the rule to this: > > 00146 0 0 deny log ip from 192.168.100.1 to any via ed1 > > it'll match the packet and deny it correctly. > > Has anyone else noticed this, or have I got this confused somehow? I'm planning > to look into it a little further, but just wondered if anyone had any ideas > offhand. > > > Later, > > /**************************************** > * Mike Heffner * > * Fredericksburg, VA -- ICQ# 882073 * > * Sent at: 10-Mar-2000 -- 01:37:17 EST * > * http://my.ispchannel.com/~mheffner * > ****************************************/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Mar 10 12: 2:17 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from hydrant.intranova.net (msb-ts-slip09.UMDNJ.EDU [130.219.28.69]) by hub.freebsd.org (Postfix) with SMTP id 259E237BA4A for ; Fri, 10 Mar 2000 12:02:11 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 22775 invoked from network); 10 Mar 2000 20:02:25 -0000 Received: from hydrant.abuselabs.com (HELO hydrant) (@192.168.0.1) by hydrant.abuselabs.com with SMTP; 10 Mar 2000 20:02:25 -0000 Date: Fri, 10 Mar 2000 15:02:24 -0500 (EST) From: Omachonu Ogali To: Luigi Rizzo Cc: Mike Heffner , freebsd-ipfw@FreeBSD.ORG Subject: Re: ipfw doesn't match when src == dest In-Reply-To: <200003101136.MAA75621@info.iet.unipi.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I usually run across those fragments when logging IGMP packets. On Fri, 10 Mar 2000, Luigi Rizzo wrote: > > Hello, > > > > When I recently redid my firewall, I wanted to block a strange packet from my > > cablemodem, > > > > Deny P:2 192.168.100.1 192.168.100.1 in via ed1 > > are you sure that the logging code prints the right thing ? > I noticed (from source code analysis) it does strange things with > fragments, it might as well misbehave with short packets etc. > > cheers > luigi > > as you can see, the source equals the destination. When I installed the ipfw > > rule below, it wouldn't match the packet: > > > > 00146 0 0 deny log ip from 192.168.100.1 to 192.168.100.1 via ed1 > > > > But when I change the rule to this: > > > > 00146 0 0 deny log ip from 192.168.100.1 to any via ed1 > > > > it'll match the packet and deny it correctly. > > > > Has anyone else noticed this, or have I got this confused somehow? I'm planning > > to look into it a little further, but just wondered if anyone had any ideas > > offhand. > > > > > > Later, > > > > /**************************************** > > * Mike Heffner * > > * Fredericksburg, VA -- ICQ# 882073 * > > * Sent at: 10-Mar-2000 -- 01:37:17 EST * > > * http://my.ispchannel.com/~mheffner * > > ****************************************/ > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-ipfw" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message > -- +-------------------------------------------------------------------------+ | Omachonu Ogali oogali@intranova.net | | Intranova Networking Group http://tribune.intranova.net | | PGP Key ID: 0xBFE60839 | | PGP Fingerprint: C8 51 14 FD 2A 87 53 D1 E3 AA 12 12 01 93 BD 34 | +-------------------------------------------------------------------------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Mar 10 12:15:13 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from MailAndNews.com (MailAndNews.com [199.29.68.160]) by hub.freebsd.org (Postfix) with ESMTP id A254337BB03 for ; Fri, 10 Mar 2000 12:15:08 -0800 (PST) (envelope-from mheffner@mailandnews.com) Received: from muriel.penguinpowered.com [208.138.199.76] (mheffner@mailandnews.com); Fri, 10 Mar 2000 15:14:57 -0500 X-WM-Posted-At: MailAndNews.com; Fri, 10 Mar 00 15:14:57 -0500 Content-Length: 3382 Message-ID: X-Mailer: XFMail 1.4.4 on FreeBSD X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_=XFMail.1.4.4.FreeBSD:20000310151538:5922=_" In-Reply-To: <200003101136.MAA75621@info.iet.unipi.it> Date: Fri, 10 Mar 2000 15:15:38 -0500 (EST) Reply-To: Mike Heffner From: Mike Heffner To: Luigi Rizzo Subject: Re: ipfw doesn't match when src == dest Cc: freebsd-ipfw@FreeBSD.ORG Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This message is in MIME format --_=XFMail.1.4.4.FreeBSD:20000310151538:5922=_ Content-Type: text/plain; charset=us-ascii On 10-Mar-2000 Luigi Rizzo wrote: |> Hello, |> |> When I recently redid my firewall, I wanted to block a strange packet from |> my |> cablemodem, |> |> Deny P:2 192.168.100.1 192.168.100.1 in via ed1 | | are you sure that the logging code prints the right thing ? | I noticed (from source code analysis) it does strange things with | fragments, it might as well misbehave with short packets etc. | Your right! When it logs ICMP or unknown ip packets, it'll incorrectly print the source and destination as the same address. This is from incorrect use of inet_ntoa(3)...from the manpage: "The string returned by inet_ntoa() resides in a static memory area. " So the following patch fixes it: (also attached as mailer will murder tabs) Index: sys/netinet/ip_fw.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v retrieving revision 1.131 diff -u -r1.131 ip_fw.c --- ip_fw.c 2000/02/29 17:51:25 1.131 +++ ip_fw.c 2000/03/10 20:04:13 @@ -464,7 +464,6 @@ } } - len = 0; switch (ip->ip_p) { case IPPROTO_TCP: len = snprintf(SNPARGS(proto, 0), "TCP %s", @@ -500,12 +499,13 @@ icmp->icmp_type, icmp->icmp_code); else len = snprintf(SNPARGS(proto, 0), "ICMP "); - snprintf(SNPARGS(proto, len), "%s %s", inet_ntoa(ip->ip_src), - inet_ntoa(ip->ip_dst)); + len += snprintf(SNPARGS(proto, len), "%s", inet_ntoa(ip->ip_src)); + snprintf(SNPARGS(proto, len), " %s", inet_ntoa(ip->ip_dst)); break; default: - snprintf(SNPARGS(proto, 0), "P:%d %s %s", ip->ip_p, - inet_ntoa(ip->ip_src), inet_ntoa(ip->ip_dst)); + len = snprintf(SNPARGS(proto, 0), "P:%d %s", ip->ip_p, + inet_ntoa(ip->ip_src)); + snprintf(SNPARGS(proto, len), " %s", inet_ntoa(ip->ip_dst)); break; } Later, /**************************************** * Mike Heffner * * Fredericksburg, VA -- ICQ# 882073 * * Sent at: 10-Mar-2000 -- 15:10:12 EST * * http://my.ispchannel.com/~mheffner * ****************************************/ --_=XFMail.1.4.4.FreeBSD:20000310151538:5922=_ Content-Disposition: attachment; filename="ip_fw.patch.gz" Content-Transfer-Encoding: base64 Content-Description: ip_fw.patch.gz Content-Type: application/octet-stream; name=ip_fw.patch.gz; SizeOnDisk=428 H4sICGVVyTgAA2lwX2Z3LnBhdGNoAK1S30vDMBB+Tv+KYzBYaWKSblMWUSZ7kD3oyub7mG2qwZmW Jk5F/N9Nuk5UrBM0kF+X++777i5TncknAebZUC2tcpOqcpk/HqTByd9HMJ8sIFdrKYDeFveS6nRj qKlS+g0h3gSVtJWSG6VvoHKbUYUGfsD7PMhUngN5AFLVd9iJJITszihmjFEW03gE/EgMuYiHaIuO ouiLV59yBjETbCB4PxiPgQwOB/gIIr8dwngcAEKvbnEzIGgtNZwAO3YG86hsegs9VZJTF7MM4cVZ 05WRME2S+exqtryaJMLjtyijy0ppm/cWl8nZ/HzRK6vCFhhYiKHjXKFrOriWMGQM89hpGI0w7zci ELih0ntP59alfS4l/mhIi0yGXhmSayNryC+Ip5OLBDoORxBqc3RhvGvX1BLBN2upbbHa5e4aGWIf oJb49TUzNnTxo62cqF3PO00bxzbKHniLxkaFq8p1JVd3/pTJfPWwtuKn1OsaJaKbwXv2Tb/bE67L sa8Oe9rSUH7ii5pP0Mb5z+XxP/4NvVZ2UhcEAAA= --_=XFMail.1.4.4.FreeBSD:20000310151538:5922=_-- End of MIME message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Sat Mar 11 17:59:57 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.prod.itd.earthlink.net [207.217.121.85]) by hub.freebsd.org (Postfix) with ESMTP id 440D037B884 for ; Sat, 11 Mar 2000 17:59:55 -0800 (PST) (envelope-from aerosmith@earthlink.net) Received: from kindred (pool0666.cvx31-bradley.dialup.earthlink.net [209.179.148.156]) by gull.prod.itd.earthlink.net (8.9.3/8.9.3) with SMTP id RAA04682 for ; Sat, 11 Mar 2000 17:59:54 -0800 (PST) Message-ID: <008401bf8bc7$6d473840$9c94b3d1@gryphonsoft.com> Reply-To: "Will Schroeder" From: "Will Schroeder" To: Subject: Hybrid Cable Modem masquerading Date: Sat, 11 Mar 2000 18:05:22 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01BF8B84.5E7C1F80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0081_01BF8B84.5E7C1F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey everyone, I have a Hybrid cable modem (at least I think that's how you refer = to a one way cable modem). It's a com21. How exactly could I setup a NAT = with the uplink ppp and the downlink ethernet? Just in case it matters, = my ethernet connection to the cable modem is a 3com 3c905b, the one to = the LAN is a Realtek 8139 and my modem is a 3com USR 56k Sporster (NOT = the win modem). Can anyone help me out? Will ------=_NextPart_000_0081_01BF8B84.5E7C1F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hey everyone,
    I have a Hybrid cable modem (at = least I=20 think that's how you refer to a one way cable modem). It's a com21. How = exactly=20 could I setup a NAT with the uplink ppp and the downlink ethernet? Just = in case=20 it matters, my ethernet connection to the cable modem is a 3com 3c905b, = the one=20 to the LAN is a Realtek 8139 and my modem is a 3com USR 56k Sporster = (NOT the=20 win modem). Can anyone help me out?
 
Will
------=_NextPart_000_0081_01BF8B84.5E7C1F80-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message