On Thu, 31 Jul 2003, Jefferson Ogata wrote:One downside to bridges is that they can't do NAT, except perhaps in very limited ways.
What is it you would need to us NAT for. The FTP proxy works fine on a Bridging firewall without any ip-address including Active mode. I haven't yet tried the other proxies on a bridge but I expect they may very well work too. It is the in-kernel proxies one would want to use in the NAT configuration and examples of how to use them on a transparent bridging firewall have been posted to this list.
First of all, you make a good case for routing with comments such as "I haven't yet tried... but I expect they may very well work". And who feels like digging through the list archives to find those examples?
Secondly, there are plenty of applications for NAT beyond the kernel proxies. I use NAT extensively to virtualize my network services away from the addresses of real systems. That makes it easy to move the service from one system to another. For example, a nameserver can be actually just a rdr rule on the firewall, with the real nameserver located somewhere on a service network on the other side. Or SSH to a particular IP actually goes to a chrooted sshd running on port 222 on a box where there's also a regular sshd on port 22.
And there are dozens of other scenarios where NAT can provide an effective solution, e.g. load balancing, short-term service relocation for remote services that go down outside your administrative domain (e.g. DNS, LDAP, SMTP), redirection of services to alternate ports, etc.
Whether you can do these sorts of things with NAT on some particular brand X bridging firewall varies, but I've seen it stated repeatedly on this list that some NAT features in IP Filter do not work in bridge configurations.
And finally, I think you are missing the point. If you stick to the garden-variety routing firewall configuration, you can replace the device with a PIX, Checkpoint, Linux box, IP Filter, router with ACLs, *whatever you've got*, in an emergency. Once you get into a bridged configuration, you're stuck with very few replacement options. You also make it harder for the next admin to find a replacement device.
And what's the point? What actual benefit do you get out of a bridged configuration? If you're only answer is, "no IP to attack", that's just silly. You can always just block all traffic to the box's IPs, if you can't secure it with a little more finesse than that.
I've got nothing against bridges per se -- you want to use 'em? go for it! -- but when someone asks, as in this case, "I'm setting something up; bridged or routing, what do you think?" the clear winner from my point of view, considering ease of use, maintainability, overall features, disaster recovery, and migration path, is: "routing".
-- Jefferson Ogata <[EMAIL PROTECTED]> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
