From owner-freebsd-questions Fri Jul 30 3:55:29 1999 Delivered-To: freebsd-questions@freebsd.org Received: from relay.ucb.crimea.ua (relay.ucb.crimea.ua [212.110.138.1]) by hub.freebsd.org (Postfix) with ESMTP id CC0A9150A6 for ; Fri, 30 Jul 1999 03:45:06 -0700 (PDT) (envelope-from ru@ucb.crimea.ua) Received: (from ru@localhost) by relay.ucb.crimea.ua (8.9.3/8.9.3/UCB) id NAA85287; Fri, 30 Jul 1999 13:41:23 +0300 (EEST) (envelope-from ru) Date: Fri, 30 Jul 1999 13:41:23 +0300 From: Ruslan Ermilov To: Wayne Cuddy Cc: FreeBSD Questions Subject: Re: natd won't alias?? What the deal? Message-ID: <19990730134123.A82145@relay.ucb.crimea.ua> Mail-Followup-To: Wayne Cuddy , FreeBSD Questions References: <19990722101951.D78891@relay.ucb.crimea.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Wayne Cuddy on Wed, Jul 21, 1999 at 11:59:55PM -0400 X-Operating-System: FreeBSD 3.2-STABLE i386 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Jul 21, 1999 at 11:59:55PM -0400, Wayne Cuddy wrote: > I have 2 ip addresses bound to one NIC card and I am attempting to use NATD to > route addresses from my private network to the internet with little success. > > Addresses: > 207.196.47.5 mask 0xfffffff0 (public iface) > 10.0.0.20 mask 0xffffff00 > > When I run natd in debug mode it sees packets from my internal hosts but does > not translate their addresses for some reason. Here is the output from natd > -v -a 207.196.47.5 > > In [ICMP] [ICMP] 10.0.0.1 -> 209.70.120.131 8(0) aliased to > [ICMP] 10.0.0.1 -> 209.70.120.131 8(0) > That's right because natd(8) aliases (read: changes the source IP address) only for ``outgoing'' packets, while this packet is incoming. But you should see the following later, when this packet will be ``outgoing'', don't you? Out [ICMP] [ICMP] 10.0.0.1 -> 209.70.120.131 8(0) aliased to [ICMP] 207.196.47.5 -> 209.70.120.131 8(0) > Out [ICMP] [ICMP] 207.196.47.5 -> 10.0.0.1 3(1) aliased to > [ICMP] 207.196.47.5 -> 10.0.0.1 3(1) > That's right as well, because: a) natd(8) is run with ``-unregistered_only'' flag b) this packet is already `aliased' (its sourceIP is already 207.196.47.5). > Here is what I would expect: > In [ICMP] [ICMP] 10.0.0.1 -> x.x.x.x 8(0) aliased to > [ICMP] 207.196.47.5 -> x.x.x.x 8(0) > Wrong assumption, explained above. > Out [ICMP] [ICMP] 207.196.47.5 -> x.x.x.x 3(1) aliased to > [ICMP] 10.0.0.20 -> 10.0.0.1 3(1) > Wrong assumption, explained above. On Thu, Jul 22, 1999 at 11:43:57PM -0400, Wayne Cuddy wrote: > Here is the output you requested. Thanks for the help. I was able to set > this up easily under linux but the FreeBSD interface with natd and ipfw is > very confusing. > > > Script started on Thu Jul 22 23:22:05 1999 > # ifconfig -a > ed0: flags=8843 mtu 1500 > inet 207.196.47.5 netmask 0xfffffff0 broadcast 207.196.47.1 > inet 10.0.0.20 netmask 0xffffff00 broadcast 10.0.0.255 > ether 00:40:33:94:36:d2 > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 207.196.47.1 UGSc 4 60 ed0 > 10/24 link#1 UC 0 0 ed0 > 10.0.0.1 0:40:5:47:79:19 UHLW 0 188 ed0 1038 > 10.0.0.20 0:40:33:94:36:d2 UHLW 0 4 lo0 > 10.0.0.50 0:10:4b:b:a1:63 UHLW 2 422 ed0 1079 > 127.0.0.1 127.0.0.1 UH 1 26 lo0 > 207.196.47/28 link#1 UC 0 0 ed0 > 207.196.47.1 ff:ff:ff:ff:ff:ff UHLWb 4 4 ed0 > 207.196.47.2 0:10:4b:b:a1:63 UHLW 0 0 ed0 1079 > 207.196.47.5 0:40:33:94:36:d2 UHLW 0 20 lo0 > # ipfw list > 00300 divert 8668 ip from any to any via 207.196.47.5 > 00400 allow ip from any to any via ed0 > 65535 deny ip from any to any > # exit > > Script done on Thu Jul 22 23:22:20 1999 Assuming that ``ipfw list'' output is full, everything looks OK except the following rule is missing: allow ip from any to any via lo0 But it doesn't make sense for this particular problem. On Wed, Jul 28, 1999 at 11:06:16PM -0400, Wayne Cuddy wrote: > I wish to use NATD on a computer with single interface card in it. I have > looked in the handbook and "The Complete FreeBSD" but neither have information > pertaining to this particular information. I am currently running linux as a > natbox in this configuration but wish to switch it to freebsd. > > If anyone could help me with the natd switches and the ipfw rules I would > greatly appreciated it. > > Here is my configuration: > > public interface 207.196.47.5 netmask 255.255.255.240 > interface on private network 10.0.0.50 > netmask of private network 255.255.255.0 > > I have tried natd -u -a 207.196.47.5 but this did not seem to work. I saw > natd viewing the packets on debug but it did not translate them and they went > nowhere. > > thanks in advance, > Wayne Sorry, I was too busy last week to help you. Now I'm ready. Let's start from a small experiment. What happens with the following ipfw(8) rules: 00100 divert natd log ip from any to any via ed0 00200 allow ip from any to any via ed0 00300 allow ip from any to any via lo0 00400 deny log ip from any to any 65535 deny ip from any to any (note the ``log'' keywords for test purposes) natd(8) is run as: # natd -v -u -a 207.196.47.5 and you ping 209.70.120.131 from 10.0.0.1 as follows: # ping -c 1 209.70.120.131 Send me the output of ``natd'' and ``dmesg | grep "^ipfw:"''. You should see the following lines on natd(8) screen: In [ICMP] [ICMP] 10.0.0.1 -> 209.70.120.131 8(0) aliased to [ICMP] 10.0.0.1 -> 209.70.120.131 8(0) Out [ICMP] [ICMP] 10.0.0.1 -> 209.70.120.131 8(0) aliased to [ICMP] 207.196.47.5 -> 209.70.120.131 8(0) In [ICMP] [ICMP] 209.70.120.131 -> 207.196.47.5 8(0) aliased to [ICMP] 209.70.120.131 -> 10.0.0.1 8(0) Out [ICMP] [ICMP] 209.70.120.131 -> 10.0.0.1 8(0) aliased to [ICMP] 209.70.120.131 -> 10.0.0.1 8(0) -- 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message