|> From: Doug Clements [mailto:dsclements@linkline.com] |> Sent: Thursday, September 06, 2001 7:14 PM |> > A business that requires direct Internet access can't use |> > NAT at the border. |> |> Not true. While I expect you will take this as nitpicking, |> one:one NAT is very conveniently used for servers while |> one:many NAT can be used for generic workstation access |> while preserving a consistent LAN numbering scheme. |> Anything that a "full" internet connection gets you will |> also work with one:one NAT. Yes, one:one NAT has transitional uses. It is also good for many dial-up scenarios. But, it is not a full internet connection and users should be told so. |> > A business that delivers services to the internet can't |> use NAT, for their |> > application servers, at all. |> |> This is laughable. You're telling me that we can't use |> our Alteons or Arrowpoints that use NAT to provide |> (redundant and load balanced!) internet services? I |> guess we should just go back to the One Big Web Server |> days, and put all our MS SQL database servers out in |> "full" view of the internet. Now there's any idea. 'A' doesn't follow 'B'. Just because the app servers are visible, doesn't mean that the RDBMS servers have to be (and yes, I like F5's). That isn't even a NAT issue. The only RDBMS servers visible, on my LANs, are Oracle Enterprise Management servers and usually they are behind a VPN. There is no earthly reason to expose an RDBMS server to the internet. The only ones that need to see them are the (dual NIC) app servers and the VPN gateway. You can't run a IPSEC VPN from NAT'd space. But, we have gotten quite far from the original post, which was prompted by a scheme to implement multi-homing, using dual NAT interfaces (one to each provider). Thereby, allowing multi-homing without having to advertise the /24 in BGP. This makes a many:one relationship. Basically, you burn two static IP addrs for each host, just to avoid advertising the /24. That's 512 IP addrs where 255 would have done the job.