David, so in the end we talk about remote access VPN and not about site-to-site VPNs...
Looking at your draw, I think you should go Jason's way, have the transit network between ASA and ISA, with ISA routing traffic between its Internal and External Networks. I'm not sure if you really need this route relationship (what's in that ASA DMZ), if you do not terminate site-to-site VPN connections on ASA and you will use ISA as a VPN server.
With a NAT relationship on ISA between Internal and External Networks, it would be more easy "to keep the current access rules".
But if in the future you plan to terminate site-to-site VPN connections on ASA, it would be better to do the work now (route relationship), and prepare yourself for the future. Although you will have to do more work now.
I think you would have much more flexibility terminating the remote access VPN connections on ISA (thus to use ISA as a VPN server), granular control per your domain's users/groups.
I would not create the site-to-site VPN between ASA and ISA.
About using ISA with a single NIC, I would rather shoot myself in the foot...
With the single NIC, you loose the firewall functionality of ISA "as an arhitecture" ...
ISA will not be "in the path" no matter what you would do, including the sandwich of hardware firewalls with ISA between them.
If we look at the doc for ISA 2006 EAL certification, chapter Certification Security Objectives for the Environment:
OE.SINGEN: Information should not flow among the internal and external networks unless it passes through the TOE. Thereby the TOE administrator has to
guarantee an adequate integration of the TOE into the environment.
The "adequate integration" sounds fishy 'cause some may say that the sandwich of hardware firewalls is an "adequate integration", but there is no concept of External Network with single NIC mode.
So if you want to take advantage of ISA's features, you should use it as a firewall. I know that this sounds like a relative comment ...
You can benefit of ISA's intelligent application layer protection for HTTP and HTTPS (SSL/TLS) connections though (so you get your OWA working).
You can't publish SMTP with single NIC mode, check this:
Create a secure publishing rule. For Web publishing, create a rule using the Web Publishing Rule Wizard. For publishing Outlook Web Access, create a rule using the Mail Server Publishing Wizard. Note that you can also publish Outlook Mobile Access, RPC over HTTP, and Exchange ActiveSync using this wizard. To publish servers securely, use an HTTPS-to-HTTPS bridging configuration. In this scenario, users connect to ISA Server using SSL. ISA Server terminates the SSL connection at the ISA Server computer and inspects traffic. Packets are then forwarded to the published Web server over a new HTTPS connection.
Application layer inspection. Application level filtering is not functional, except for the Web Proxy filter (for HTTP, HTTPS, and FTP over HTTP).
Server publishing. Server publishing is not supported. There is no separation of Internal and External networks, so ISA Server cannot provide the network address translation (NAT) functionality required in a server publishing scenario.
Jason, I see you did not bite the "traditional dmz" question.
Yep, ASA appears to suit better than ISA for IPsec Tunnel Mode site-to-site connections. With ISA there are some two cents limitations that unfortunetely I see in the TMG Beta 1 release too.
I do not like the ASA SSL VPN at all.
Personally I did not "play" too much with IAG, I did not have the chance. It's a complex product, requiring many hours of "playing" in order to trully understand and exploit its capabilities.
But from my experience so for, IAG rocks!
In justmee's defense in depth approach (TM), there isn't simple inbound and outbound traffic, and simple transit networks.
I do not worry about clear text traffic, because I do have to... This is by design ...
Like you have a multidoor/multiaccess building and you direct people on different paths.
You won't see cars on the bus lane ...
Yeah, that's not simple. And not practical for most people ...
Me too I would feel better with one ISA than with too ASAs. I would rather invest in ISA addons: antivirus capabilities, content filtering, VPN endpoint compliancy, maybe in Clear Tunnel ...
One subtle "problem" with ISA is its firewall arhitecture. Microsoft did a great job putting all the pieces togeter, and it works out of the box as an advanced/intelligent firewall.
There are a lot of tiny things that makes a firewall secure, and with ISA they go unnoticed 'cause they just work (silently by default in background). And you can get some application awareness, not just L7 awareness, which is crap, because it can mean anything and almost nothing.
With Cisco's approach of evolving a NAT device into a firewall not all the pieces are working togeter, and you may have to do some work that "makes you feel better" and gives you the "feeling of control over packets". So you need to glue things yourself, which is unnecessary and complicated. And the problem, is that in the end all these things you need to do, might not add so much intelligence, since in some scenarious this is missing by design.
By the way, with justmee's defense in depth approach (TM), the Internal Network is also "perimiterized": segmented, proper switches preventing MITM with ARP spoofing, HIPS+host based firewall, antivirus, spyware...
There is also a patching/updating infrastructure. Defense in depth approach includes exploiting at maximum the Group Policy too.
In the end defense in depth and "DMZs" can be high priced fud or real deal.
I love these chats too ...
Now I've think I've messed completely David's topic.
But since Jason you are an administrator, you can "clean" it if you want...
< Message edited by justmee -- 8.Jun.2008 7:01:56 AM >