I'd like to second the suggestion of using NAT for the windows clients, and the shell accounts etc.
So my preference would be to use the 32 IP's addresses for the DMZ, I'd run a squid proxy, and have browsers use it, which will conserve your bandwidth, and offer faster access when pages are revisited. How cleanly you can seperate the functions depends on what hardware you have available, there's a trade off between rack space, hardware cost, and security. So you might like to take a look at something like Smoothwall, which can do firewalling on older legacy hardware and has good support for things like IPSEC, routing and packet filtering (plus IIRC incoming dial up), see www.smoothwall.org. Then you can use your better server for web proxy, SMTP and POP/IMAP support. For shell access I'd suggest rather than allowing telnet, to use OpenSSH and distribute the client putty to windows users. You may need to make some kind of 'virtual server' type environment, depending on what you're offering to your customers. It's not really clear to me what you are protecting, it seems just an email and DNS server with proxy cache, no web server, or exported services, so the firewall and NAT solves most of the problems protecting the Windows boxes. So I suspect you can afford to be relatively relaxed, rather than go for top security levels. Assuming you use one box for firewall, one as server for DNS/SMTP/WWW proxy (which could be run with 2 NICs with routing turned off), then you are only left with the problem of the shell accounts. This should really be on a seperate machine, a play pen box, which is not trusted, depending on what you're offering it might be best to segregate that one completely by splitting the DMZ. In that case for the main firewall/router you'll appreciate a 4 port NIC, Dlink make a good one that is good value and is supported with Linux. Rob
