From owner-cvs-all Thu Jul 1 22:56:12 1999 Delivered-To: cvs-all@freebsd.org Received: from inet.chip-web.com (c1003518-a.plstn1.sfba.home.com [24.1.82.47]) by hub.freebsd.org (Postfix) with SMTP id AFF8214E73 for ; Thu, 1 Jul 1999 22:56:08 -0700 (PDT) (envelope-from ludwigp@bigfoot.com) Received: (qmail 9426 invoked from network); 2 Jul 1999 05:56:06 -0000 Received: from speedy.chip-web.com (HELO speedy) (172.16.1.1) by inet.chip-web.com with SMTP; 2 Jul 1999 05:56:06 -0000 Message-Id: <4.1.19990701223654.0091eda0@mail-r> X-Sender: ludwigp@toy.chip-web.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 01 Jul 1999 22:56:07 -0700 To: Ruslan Ermilov , Brian Somers From: Ludwig Pummer Subject: Re: cvs commit: src/sbin/natd natd.8 Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG In-Reply-To: <19990701170841.A35816@relay.ucb.crimea.ua> References: <199906210758.AAA59491@freefall.freebsd.org> <199906210758.AAA59491@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk At 07:08 AM 7/1/1999 , Ruslan Ermilov wrote: >On Mon, Jun 21, 1999 at 12:58:26AM -0700, Brian Somers wrote: >> brian 1999/06/21 00:58:26 PDT >> >> Modified files: >> sbin/natd natd.8 >> Log: >> Mention that data going from one internal address to another will >> not be processed by natd. >> Requested by: Ludwig Pummer I don't think that's how I worded it... >> Revision Changes Path >> 1.19 +11 -4 src/sbin/natd/natd.8 >> > >The text of this change was: >} It should be noted that only incoming packets are affected. >} ^^^^^^^^ >} Data going from one internal network to another will not be >} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >} processed by natd. This also isn't quite what I meant... >I don't understand. Look at my example: > ># ipfw add 1 divert 6666 tcp from 192.168.1.1 1234 to any ># nc -s 192.168.1.1 -p 1234 192.168.1.2 5678 ># natd -v -p 6666 -a 1.2.3.4 -redirect_port tcp 192.168.1.1:1234 2345 >Out [TCP] [TCP] 192.168.1.1:1234 -> 192.168.1.2:5678 aliased to > [TCP] 1.2.3.4:1234 -> 192.168.1.2:5678 > >It is outgoing packet following from one internal host to another, >and it _is_ affected. What did you mean? I'm not understanding the example very well (what's 'nc' and what is it doing?) Let me restate what I originally said/meant to say: I have a machine doing natd. It has an internal network address 172.16.1.5/24 and an external network address of 24.2.21.36/24. If I do 'redirect_port tcp 172.16.1.30:80 80' and then try to point my web browser (from a machine in the 172.16.1.5/24 network) at http://24.2.21.36:80, it will not reach 172.16.1.30:80. If, however, I point my web browser (from a machine on the internet) at http://24.2.21.36:80, it _will_ reach 172.16.1.30:80. I felt that despite this being logical according to routing and the way the ipfw rule is written**, this was worth pointing out. Otherwise, many newbies setting up natd for the first time would do something very similar to my example above, and become disappointed/discouraged/confused when they can't connect to http://24.2.21.36:80 from their inside machine. I came to this conclusion after helping someone with natd over ICQ, and then recalling that I had similar problems when I was first playing with natd. ** This is my thinking: Packets addressed to 24.2.21.36:80 from an inside machine are not actually sent out via the external network interface and then back, because the address is recognized as belonging to the computer running natd. Instead, the packets are just routed over the loopback network interface. Because the packets are never sent in and out via the interface listed in the ipfw rule, they are never sent through natd and therefore are not redirected to 172.16.1.30:80. --Ludwig Pummer ( ludwigp@bigfoot.com ) ICQ UIN: 692441 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message