Date: Sun, 12 Mar 2000 13:34:16 -0600 (CST) From: Ryan Thompson <ryan@sasknow.com> To: cjclark@home.com Cc: freebsd-questions@freebsd.org Subject: Re: Funny routing problem... Message-ID: <Pine.BSF.4.21.0003121238380.5995-100000@ren.sasknow.com> In-Reply-To: <20000312005541.J24340@cc942873-a.ewndsr1.nj.home.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Crist J. Clark wrote to Ryan Thompson: > On Sat, Mar 11, 2000 at 11:14:21PM -0600, Ryan Thompson wrote: > > Crist J. Clark wrote to Ryan Thompson: > > OK... You have _one_ machine behind the gateway. natd(8) might > actually be overkill for this. It seems all you want to do is direct > one registered IP, x.x.x.10, to this machine. There are more 'light > weight' tools for that... but I am not personally familiar with any. I've had good success with natd in the past in other applications, so I decided to stick with it. It doesn't appear to add a lot of overhead. > > I'm sure that YOU know what you're talking about, my friend... But, > > without a wee bit more explanation than that, I'm afriad I don't quite > > follow you :-) > > I did not elaborate more since I really did not comprehend what you > mean by, "Using any broader of a netmask than 0xfffffff would make > nearby (numerically, that is) addresses unreachable." Using a netmask > of 0xffffffff makes _no_ other addresses reachable on that subnet. Hmm... I believe I see what you are saying... And, at first, I didn't agree with you. However, even still, it appears to make very little difference either way in my application, as I do have a default route of 0.0.0.0/1 => x.x.x.1. Nonetheless, I usually DID give one IP 0xffffff00. It has only been recently that I've changed. > > > Then why have registered numbers on the internal machines at all? > > > > Public keys, reverse lookups, transferring export controlled software, > > etc. > > But if you use NAT with only one public IP address on the gateway, all > internal machines are mapped to that address as far as the outside > world is concerned. That address can be referenced for the above > purposes. Yes, but, from that internal machine, I don't want to lose the ability to refer to the localhost by its registered IP. I use the machine (among other things) for web site development, and, as such, I have at least a few name-based virtual hosts on it at any given time. I wouldn't really want to have to plug in seperate virtualhost entries for both the public and internal IP of the machine just so I can access those vhosts locally. Seems kind of redundant to me. > > Unless of course you mean to say "why configure public IPs on the internal > > machine's interface"? And, to that, I say I did no such thing :-) I > > simply did: > > > > ifconfig dc0 10.0.0.2 netmask 0xff000000 broadcast x.x.x.10 > > OK... So that diagram was completely wrong. I thought that address was > the internal interface of the gateway machine. Nope.. Sorry. :-) > > OK, I think I understand what you have now. That diagram you made > seems to have no connection to what you are actually doing. Yeah, yeah... It was late.. I was tired. :-) > That has been what has been causing all of the confusion at my end. > You have a gateway machine that has a number of registered IPs on its > external interface (ep0). The gateway has 10.0.0.1 on the internal > interface (pn0) and one internal machine at 10.0.0.2. You want to > direct external traffic to x.x.x.10 to the internal machine. Now we're talking :-) > OK, I see two problems still. First, you have no "real" address on > ep0. They are all aliases with 0xffffffff netmasks. You should give > one of those numbers the actual netmask on that LAN. Done. > Second, and more important, you are doing NAT at the wrong > interface. You should be doing, > > # natd -n ep0 -u -redirect_address 10.0.0.2 x.x.x.10 > Done. Obviously I've been doing things backwards for quite a while... I am now left wondering why it worked at all in the first place :-) It didn't immediately work after I flipped that around... > And in rc.conf have, > > natd_interface="ep0" > HA! Uhh... Problem solved. I momentarily forgot to reset the firewall rules to divert on ep0 instead of pn0. After manually resetting the rules (as opposed to rebooting), things work much better now. Thanks, Crist, for your patience and input. -- Ryan Thompson <ryan@sasknow.com> Systems Administrator, Accounts Phone: +1 (306) 664-1161 SaskNow Technologies http://www.sasknow.com #106-380 3120 8th St E Saskatoon, SK S7H 0W2 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?Pine.BSF.4.21.0003121238380.5995-100000>