We are currently using only 1 ISA at our headquarters and 1 ISA at the remote office. We have site to site VPN working great and client VPN's are working great, but we are now looking into putting in a B2B network on both sides. Question is how will the Site to Site VPN work and how will the client VPN's work to access the internal network. Is this a possible scenerio and if so, how can one do it. Tom, is this covered in the ISA Server Beyond? I probably overlooked an example of this site, and if I did - just simply point me in the correct direction.
Good question! Although I've not set one up yet, I believe that you'll be able to create a gateway to gateway connection between the external firewalls, and then create a second one between the internal firewalls.
The trick is going to be figuring out how to control the damage in the event that one of the DMZ hosts is compromised. If someone ends up owning a machine in one of the DMZs, how to you control the damage he can do not only in that DMZ, but in the other one too. Of course, the point of a DMZ is to put your "sacrifical lambs" in there (publicly accessible servers), so it might be less of a problem than I imagine.
hmmmm - I guess that scenerio doesnt look so good after all. I would be no better off than implementing a tri-homed scenerio other than the fact I wouldn't be able to use the server publishing feature for the DMZ. Under the scenerio I stated above - needing site to site VPN and VPN Clients and to isolate a DMZ - what would you say is the best way to do this.
Microsoft I have a wish list for the next release - give us a true (server publishable) DMZ without the need to install multiple boxs, one were we can use a private class of IP's to truely seperate the DMZ and internal network with the same ease that we have setting up the internal network now. - just my 2 cents.
Oh by the way - your ISA Server and Beyond will be delivered by Friday and I have the first book also Keep up the good work.
You can still use Server Publishing Rules, no problem with that. The DMZ would still use private addresses, so you can still take advatnage of the "full faith and credit" of Server and Web Publishing Rules! So you don't suffer any of the limitations of the trihomed DMZ.
We may be able to isolated SiteA DMZ from SiteB DMZ using packet filters. What we might be able to do is block communications from DMZ hosts in DMZ-A from communicating with DMZ host in DMZ-B, and vice-versa. I've got the scenario almost set up in the lab, its just a matter of time to work things out.
I've got a few things to do today, but I'll burn the midnight oil to doc this out and then present it at my TechMentor talk on April 12
I haven't worked out all the details yet, but it does work as advertised. Here's the short course:
1. Run the local VPN Wizard on the local external ISA Server
2. Run the remote VPN Wizard on the remote external ISA Server
3. Firewall up the demand dial interface after making the fixes I noted in my latest gateway to gateway VPN article. You can let the remote dial if you want, and it might be easier if you're not famiilar with demand dial interfaces
4. Run the local VPN Wizard on the local internal ISA Server
5. Run the remote VPN Wizard on the remote internal ISA Server
6. Make the tweaks to the VPN gateway configurations for the internal ISA Servers
7. Fire up the demand dial interface on the remote external ISA Server
8. Fire up the demand dial interface on the remote internal ISA Server
That is the very short course, but it should get you up and running. Remember a basic fact of life: nothing works the first ten times you try it. If it works before the tenth attempt, you're a very lucky person
As for controlling traffic between the DMZs, just create static routing table entries for the external interface of the on the opposite internal ISA Server. So, if someone ends up owning one of your servers in DMZ-A, they won't be able to access anything but the ISA Server's external interface on DMZ-B, and ain't no one going to crack a properly configured ISA Server.