From owner-freebsd-questions Wed Sep 8 5:33:18 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 C44F714E5E for ; Wed, 8 Sep 1999 05:30:55 -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 PAA05564; Wed, 8 Sep 1999 15:26:01 +0300 (EEST) (envelope-from ru) Date: Wed, 8 Sep 1999 15:26:01 +0300 From: Ruslan Ermilov To: "Jeffrey D. LaCoursiere" Cc: freebsd-questions@FreeBSD.ORG Subject: Re: NATD Message-ID: <19990908152601.C22077@relay.ucb.crimea.ua> Mail-Followup-To: "Jeffrey D. LaCoursiere" , freebsd-questions@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.3i In-Reply-To: ; from Jeffrey D. LaCoursiere on Sun, Sep 05, 1999 at 11:42:33AM -0500 X-Operating-System: FreeBSD 3.2-STABLE i386 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Sep 05, 1999 at 11:42:33AM -0500, Jeffrey D. LaCoursiere wrote: > > Greetings, > > Have been playing with natd this weekend on a new box with two nic's. I > have it basically working for a handful of machines on the dirty inside > net. I pass the following to natd in /etc/natd.conf: > > redirect_address 10.1.1.3 209.197.192.68 > This rule means: #1 If packet is incoming and ip_dst==209.197.192.68, change its `ip_dst' to 10.1.1.3 #2 If packet is outgoing and ip_src==10.1.1.3, change its `ip_src' to 209.197.192.68. NB: Packet should be passed to natd(8) for the aliasing to take place. This is done by `divert' rules of ipfw(8). Seems obvious? See below... > And added the 209.197.192.68 address as an alias on the outside interface > (whose normal address is 209.197.192.66). > > This works like a charm for external hosts to hit the web port on the > inside machine and get a reply through natd. > > Inside machines, on the other hand, must use the dirty address of this web > box to talk to it. The gateway box running natd cannot talk to it but on > the dirty address either. > This is a common misconception of how natd(8) works. Basically, natd(8) treats the packets as either incoming or outgoing. For outgoing packets, it changes the `ip_src' so that it becomes equal to the ALIAS_IP. ALIAS_IP is one of the a) interface's primary address (if `-n ifname' option is used); b) IP address explicitly specified with a `-a' option; c) publicIP address of the `redirect_address localIP publicIP' command; the latter is only true for packets with ip_src==localIP. d) similarly for `redirect_port'. An entry is then made (for cases `a' and `b') in the internal translation table to record this fact (that the source address has been changed). For incoming packets, the reverse action takes place. For packets with ip_dst==ALIAS_IP, the correct ip_dst is looked up in the internal table, and reverse substitution is being done. For example, if the following rule has been given (redirect_port localIP publicIP), the incoming packet with ip_dst==publicIP is rewritten so, that its ip_dst=localIP. So, why your internal hosts can't reach your Web server by 209.197.192.68? Because your firewall rule for natd(8) looks like: NNNNN divert natd ip from any to any via ed0 This causes natd(8) to work only on packets sent/received via external interface ed0. The following will do the trick (add these rules to the above one): NNNNN divert natd ip from any to any http NNNNN divert natd ip from any http to any Note, that there is no `via' keyword, so the aliasing will take place for internal hosts as well. > I have trapped the following on the external > interface when the gateway box tries to ping the inside box using the > external secondary address: > > 11:25:17.459779 arp who-has 209.197.192.68 tell 209.197.192.66 > 11:25:18.469800 arp who-has 209.197.192.68 tell 209.197.192.66 > > So it looks like the gateway is ARPing for the alias address on the > external interface - the same interface the alias is attached to! > > Is this a FreeBSD bug? Seems like it ought to RARP itself :) > This is another story. 209.197.192.68 should be in static ARP table, of course, if 209.197.192.68 has been aliased to the interface. Everything could be done by properly adjusting ipfw(8) and natd(8) rules. It's not easy to make the gateway box access the inside box using the external secondary address. For this to work (if you really need to) you will have to change the natd's idea about incoming and outgoing packets. This could be done with `-i' and `-o' options of natd(8), and writing some rules for ipfw(8). The best way is to run natd with `-v' and test on the fly. > I am also confused why the translation didn't take place first. > I ran natd in -v mode to see what it was doing: > > dudemon% s /sbin/natd -v -f /etc/natd.conf -n ed0 > Out [ICMP] [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) aliased to > [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) > Out [ICMP] [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) aliased to > [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) > Out [ICMP] [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) aliased to > [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) > Out [ICMP] [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) aliased to > [ICMP] 209.197.192.66 -> 209.197.192.68 8(0) > ^C > > No translation taking place? What am I missing? > As I said above, for outgoing packets, natd(8) changes the `ip_src' of the packet to the ALIAS_IP. In your case (-n ed0), ALIAS_IP is 209.197.192.66, so natd(8) changes 209.197.192.66 to 209.197.192.66, in other words, does nothing. The following aliasing would take place if this packet was incoming: } In [ICMP] [ICMP] X.X.X.X -> 209.197.192.68 8(0) aliased to } [ICMP] X.X.X.X -> 10.1.1.3 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