Date: Tue, 20 Jul 1999 11:25:21 +0300 From: Ruslan Ermilov <ru@ucb.crimea.ua> To: Tim Walker <tim@cyberghost.org> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Weird IPFW / NATD problem... Message-ID: <19990720112521.A99153@relay.ucb.crimea.ua> In-Reply-To: <4.1.19990717080057.009a4880@mail.cyberia.com>; from Tim Walker on Sat, Jul 17, 1999 at 08:03:32AM -0400 References: <377F88A7.FC5680E7@a-lehdet.fi> <4.1.19990717080057.009a4880@mail.cyberia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii On Sat, Jul 17, 1999 at 08:03:32AM -0400, Tim Walker wrote: > I am running FreeBSD as my network's gateway to the Internet and am > trying to pass Web traffic through to a server on my internal network > (FreeBSD machine has a routable IP address and the internal web server > has a non-routable address). > > It is working fine from the outside world, but from machines on my > internal network they always end up on the FreeBSD webserver. > > In the natd.conf file I have: > > use_sockets yes > same_ports yes > interface ed1 > redirect_port tcp 192.168.1.2:80 80 > redirect_port tcp 192.168.1.2:21 21 > redirect_port tcp 192.168.1.2:20 20 > Looks good. > > and in the rc.firewalls file I have: > > ipfw add 10 divert natd tcp from 192.168.1.2 80 to any > ipfw add 11 divert natd tcp from any to 192.168.1.2 80 > ipfw add 12 divert natd tcp from any to 192.168.1.100 80 > > (192.168.1.2 is the webserver, and 192.168.1.100 is the inside interface of > the FreeBSD machine). > > Does anyone have any suggestions? > > Tim Walker > The following should do the trick: ipfw add 10 divert natd tcp from any 80 to any ipfw add 11 divert natd tcp from any to any 80 See the attached message for a more detailed explanation. Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --J2SCkAp4GZ/dPZZf Content-Type: message/rfc822 Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id PAA46112; Fri, 2 Jul 1999 15:16:15 +0300 (EEST) (envelope-from ru) Date: Fri, 2 Jul 1999 15:16:15 +0300 From: Ruslan Ermilov <ru@FreeBSD.ORG> To: Ludwig Pummer <ludwigp@bigfoot.com> Cc: Brian Somers <brian@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sbin/natd natd.8 Message-ID: <19990702151615.A29698@relay.ucb.crimea.ua> References: <199906210758.AAA59491@freefall.freebsd.org> <199906210758.AAA59491@freefall.freebsd.org> <19990701170841.A35816@relay.ucb.crimea.ua> <4.1.19990701223654.0091eda0@mail-r> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: <4.1.19990701223654.0091eda0@mail-r>; from Ludwig Pummer on Thu, Jul 01, 1999 at 10:56:07PM -0700 X-Operating-System: FreeBSD 3.2-STABLE i386 On Thu, Jul 01, 1999 at 10:56:07PM -0700, Ludwig Pummer wrote: > 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 <ludwigp@bigfoot.com> > > 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?) > /usr/ports/net/netcat - simple utility which reads and writes data across network connections, very handy. > 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. > Ah, I see now what did you mean, but you're wrong anyway. It works(!) even in such configuration, look what I did: Host running natd: (internal interface 192.168.1.1/24) fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:a0:c9:55:13:22 media: autoselect (10baseT/UTP) status: active supported media: autoselect 100baseTX <full-duplex> 100baseTX 10baseT/UTP <full-duplex> 10baseT/UTP (external interface 212.110.138.1/28) fxp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 inet 212.110.138.1 netmask 0xfffffff0 broadcast 212.110.138.15 ether 00:a0:c9:5a:51:f9 media: manual supported media: manual # ipfw list 1 00001 divert 6666 tcp from any to any 80 00001 divert 6666 tcp from any 80 to any *** Note that there are no "via" keywords, otherwise it will not work. # natd -v -p 6666 -n fxp2 -u -redirect_port tcp 192.168.1.13:80 80 (telnet from 192.168.1.3 to 212.110.138.1:80) In [TCP] [TCP] 192.168.1.3:4138 -> 212.110.138.1:80 aliased to [TCP] 192.168.1.3:4138 -> 192.168.1.13:80 Out [TCP] [TCP] 192.168.1.3:4138 -> 192.168.1.13:80 aliased to [TCP] 212.110.138.1:4138 -> 192.168.1.13:80 (reply from 192.168.1.13:80) In [TCP] [TCP] 192.168.1.13:80 -> 212.110.138.1:4138 aliased to [TCP] 192.168.1.13:80 -> 192.168.1.3:4138 Out [TCP] [TCP] 192.168.1.13:80 -> 192.168.1.3:4138 aliased to [TCP] 212.110.138.1:80 -> 192.168.1.3:4138 (telnet from 212.110.138.4 to 212.110.138.1:80) In [TCP] [TCP] 212.110.138.4:49247 -> 212.110.138.1:80 aliased to [TCP] 212.110.138.4:49247 -> 192.168.1.13:80 Out [TCP] [TCP] 212.110.138.4:49247 -> 192.168.1.13:80 aliased to [TCP] 212.110.138.4:49247 -> 192.168.1.13:80 (reply from 192.168.1.13:80) In [TCP] [TCP] 192.168.1.13:80 -> 212.110.138.4:49247 aliased to [TCP] 192.168.1.13:80 -> 212.110.138.4:49247 Out [TCP] [TCP] 192.168.1.13:80 -> 212.110.138.4:49247 aliased to [TCP] 212.110.138.1:80 -> 212.110.138.4:49247 > 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. > I hope you're ready to do it now! > ** 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. > No, you misunderstood the concept. It is very simple, in fact: There are two kinds of packets, "incoming" and "outgoing". Outgoing packets are "aliased", i.e. their source IP address is replaced by the "aliasing" address. And vice versa, incoming packets are "de-aliased", i.e. their destination IP address (which is equal to one of the "aliasing" addresses, yes, there can be more than one) is looked for in the internal natd's mapping table, which is created "on the fly" and by "redirect" rules. Whether the packet is considered an "incoming" or "outgoing", depends on how the natd has been run. If run with ``-p port'', then the rules described in divert(4) take place. You can override this by running natd with "-i inport" and "-o outport". This will instruct natd to treat all packets from "inport" as being "incoming", and permorm "de-aliasing" for them, and all packets from "outport" as "outgoing", and perform "aliasing" for them. It gives you more flexibility, but unneeded in most cases. Another option that changes this behaviour is "-reverse" option. One important thing that should be taken into the account is the ipfw's configuration. You should make sure to configure it properly, I think you understood this from my example. Cheers, -- Ruslan Ermilov Sysadmin and DBA of the ru@ucb.crimea.ua United Commercial Bank, ru@FreeBSD.org FreeBSD committer, +380.652.247.647 Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age --J2SCkAp4GZ/dPZZf-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990720112521.A99153>