On Tue, 2006-05-16 at 00:50 +0000, [EMAIL PROTECTED] wrote: > I know the ISA 2004 is the recommended way to deploy but at this point > using ISA isn't an option.
:( > What I meant by opening each individual port was that for some reason > I was thinking that instead of opening ports, 443, 389, 3268, 88, and > whatever else, I could tunnel everything via IPSEC. I would only have > to allow that to pass through the firewall instead of each one of the > ports that are required for the Front End Server to communicate with > the Back End Server. So I thought all of that information would > traverse the IPSEC tunnel and then the application/server itself would > decrypt the tunnel and then use whatever ports it needs. I wish I > could draw in e-mail....I think it would less non-sense if I could > draw a diagram. Either way I guess I was wrong. What you're talking about is creating an IPSec tunnel from the host to the destination rather than using IPSec in transport mode, which is the normal configuration for front/back end exchange. Essentially, you'd be treating your DMZ as the outside world and making a VPN connection as a client with remote access would. You could do this using IPSec support in the device which is doing the NAT, if it supports it, or by passing through IPSec or L2TP/IPSec (or pptp) traffic to a VPN server behind the device using something like Routing and Remote Access (again, if it supports it - if your options are portforwarding, then you're fairly out of luck). If you don't mind answering on a public list, what is your NAT-performing-device, and what is it running? In any case, doing this without terminating the connection at the NAT device and filtering it (or generally doing filtering 'off' the DMZ'd box) would make your DMZ completely redundant as your DMZ'd host would logically be 'in' your internal network anyway and an intruder on the DMZ'd host would have complete access to your internal machines as if there were no DMZ. To be honest, as a previous poster has said, you're not in the best position having used NAT between two machines that should really have traffic being routed between them, and a topology change to make your DMZ segment routed onto your LAN (with filtering) would ultimately cause you the least pain. this will generally break if you just portforward it) You wouldn't even have to pay money to do this (or use isa) - a firewall like m0n0wall or any of the other linux/BSD firewalls would probably do you just fine (although m0n0wall has the best combination of ease of use and applicability to specifically what you want). Most packages like m0n0wall and IPCop have support for IPSec built in too, even if you decided to continue going with NAT and wanted, as above, to terminate the IPSec connection at the router. > Everything I've read from microsoft so far says to use ISA server. So > I've been trying to figure out a secure, reliable alternative. Ideally - at the end of the day ISA solves lots of headaches involved with securing front/backend exchange and presenting exchange to the world in general - the application-layer filtering exchange will do with OWA as well as SMTP is really really nice, and I would strongly consider it for any internet-facing exchange deployment. Hope that helps! - James. -- James (njan) Eaton-Lee | 10807960 | http://www.jeremiad.org Semper Monemus Sed Non Audiunt, Ergo Lartus - (Jean-Croix) sites: https://www.bsrf.org.uk ~ http://www.security-forums.com ca: https://www.cacert.org/index.php?id=3
smime.p7s
Description: S/MIME cryptographic signature
