Date: Wed, 8 Sep 1999 15:26:01 +0300 From: Ruslan Ermilov <ru@ucb.crimea.ua> To: "Jeffrey D. LaCoursiere" <jeff@jeff.net> Cc: freebsd-questions@FreeBSD.ORG Subject: Re: NATD Message-ID: <19990908152601.C22077@relay.ucb.crimea.ua> In-Reply-To: <Pine.BSF.4.10.9909051122450.13202-100000@dudemon.jeff.net>; from Jeffrey D. LaCoursiere on Sun, Sep 05, 1999 at 11:42:33AM -0500 References: <Pine.BSF.4.10.9909051122450.13202-100000@dudemon.jeff.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990908152601.C22077>