quote:

---

Originally posted by AmyB:
Tom,

There are some really dramatic differences in the way that the upgrade from ISA2000 is configured vs. a clean install is ISA2004 using the SP1 CD set. An article on these would be in order. I've been making a collection of them and could contribute.

Nice to see SBS finally getting its due.

Amy

---

quote:

---

Originally posted by Compukirk:
Tom-thanks for this series of articles. One comment is that typically a new install of SBS 2003 would have an internal NIC IP of 192.168.16.2 instead of the 192.168.2.0 you have listed. I just did my first SP1 install with slipstreamed media and it also defaults to that IP. Of course that can be changed during the setup with the wizards and there is another wizard you can run anytime later that will also easily change the internal IP.

---

quote:

---

Originally posted by DAW:
Great intro, I hope that you will address hosting Internet websites (multiple in my case) on the SBS/ISA box. The web publishing rules in combination with split DNS and SSL was very confusing to me, and I still have at least one bug in my config (fortunately it errors on the side of denying service).

Also I would love to hear your take on the default set of firewall and policy rules the wizards setup. Some seem unnecessary and potentially hazardous (DHCP on WAN interface, ICMP, and DNS rules for example).

I was restrained by budget to put everything in one basket, but because we have a few notebooks on the network, I LOVE that my server is setup not to trust LAN connections as well as WAN.

Thank you again for taking up the flag for us lowly SBS'rs :-)

-Dave

---

quote:

---

Originally posted by dvord:
Tom,

Honestly I'm very surprised and a bit disappointed that isaserver.org is going to be supportive of SBS.

MVP's have come right out and said that SBS's implementation, forcing administrators to run the Domain Controller on the same machine as the ISA Server is nothing less than watching a car crash in slow motion.

Most security folks understand that the most secure environment has key systems like firewalls and proxy servers located away from business-critical functions like collaboration applications (Exchange), and business organization functions (like AD, File and Print, etc.). By design, SBS flies in the face of conventional security. What makes matters worse is that Microsoft is frequently the target of attacks by hackers. Turning a bad situation ugly by putting vulnerable systems all together in one package.

I have posted several questions regarding SBS on Microsoft's own news server on support of this product and I'm frequently told by MVP's that "oh you shouldn't run a public website on SBS", or stating that other features which Microsoft MARKETS with SBS aren't to be used because they are flawed or highly problematic. This is not indicative of a healthy, secure system.

Security advocates have a responsibility to the people who listen to them, and ultimately to the greater good at large.

Is SBS now secure enough that concerns about ISA being on the DC are no longer valid? Wouldn't you agree that if Microsoft is marketing a critically flawed product, it is a disservice to the administrative community (and IT consumers at large) to give it "time" from such a well-recognized authority such as yourself?

---

Hi D,

Its true that SBS represents a security compromise. But given the large and increasing installed base, it seems to me that the best approach is help those folks secure their installations as much as possible.

Many of us have encouraged MS to unbundle an ISA and Windows lic for a single white box install of ISA, but those requests fall on deaf ears

Thanks!
Tom

quote:

---

Originally posted by nigejn:
I've had a look through the article and Scenario 3 is an interesting one. I can see the cost implications involved in buying an additional ISA Server, but if a HP DL320 ISA server for ú1700 ($3000) is purchased, it doesn't cost much more than a non ISA firewall, like Juniper or Watchguard.

I've been looking at a new firewall solution for our business and i've been considering an ISA Server.

Tom does your new book cover configuring 2 ISA server like in Scenario 3?

Thanks

Nigel

---

quote:

---

Originally posted by AmyB:
Hi Tom,

Na, I don't think that there is any advantage to explaining the clean install of ISA2000 no one will be doing that anymore. When you run the upgrade from a clean ISA2000 install to ISA2004 you'll be really surprised to see what happens. I'm no longer running the upgrade. I uninstall ISA2000 and then install ISA2004. Otherwise you end up with an ISA2004 server acting like an ISA2000 box and it messes with my mind when I try to configure it for the company that owns it.

We are using 'el cheapo pinhole firewalls to take the pressure off. The major benefit is that it gets rid of most of the port scans that dynamic IP networks are prone to. Side benefit when even though the business is under contract to me, the family genius comes home from college where "he's studying engineering but he knows a lot about computers too" decides to make a few changes so things can run faster, the pinhole firewall holds down the fort until I get there to straighten things back up.

It's an interesting world.

---

Hi Amy,

That's good to hear! I did do a single ISA2k upgrade to ISA2004, and I'm afraid the entire setup was so bungled by me and that I didn't even notice what the end result was to the firewall policy.

I have to admit that the end result from a clean ISA2004 install's firewall policy is a bit scary (being used to the ISA firewall being a network brick after install)

For consumer broadband connections I typically do the same thing with a NAT device in front of them (I can't bring myself to call most of these NAT device "firewalls"). Really simplifies the DHCP and PPPoE issues.

Thanks!
Tom

quote:

---

Originally posted by Cameron Ye:
This is a great article. Thank you so much for this sharing.

In addition, it seems there is a mis-typed information:

"The internal interface can use any private (non-Internet routable) address you like. The key requirement is that the IP address on the internal interface of the simple stateful packet inspection firewall or NAT device in front of the SBS 2003 SP1/ISA firewall must be on the same network ID as the external interface of the SBS 2003 SP1/ISA firewall computer. For example, you could assign the IP address 192.168.1.1/24 to the internal interface of the NAT device and assign the IP address 192.168.16.0/24 to the external interface of the SBS 2003 SP1/ISA firewall."

If my understanding is correct, the last sentence should be "For example, you could assign the IP address 192.168.1.1/24 to the internal interface of the NAT device and assign the IP address 192.168.1.0 /24 to the external interface of the SBS 2003 SP1/ISA firewall". After that, the external NIC of the SBS and the internal NIC of the BE firewall will be in the same subnet.

---

quote:

---

Originally posted by Tyler White:
New question (RE: Scenario 3):

Here's my existing network config:

SBS 2k > ISA 2k (separate Win2k Server box)

ISA 2k has 2 NICs, one to cable modem, one to LAN.

I'm getting ready to replace the SBS 2k with an entirely new box, so the config will be:

SBS 2k3 Premium > ISA 2k (no change from above).

Here's the question/situation: I would like to implement Scenario 3 since I have all of the building blocks, but is there an issue with the SBS 2k3 running ISA 2004 on the inside and having ISA 2k on the outside?

Thanks!

---

Hi Tyler,

That's a great question!

This would be the back to back ISA firewall configuration, with a twist

There are many ways you could approach this configuration:

1. Make the SBS 2003 SP1 box a Web proxy client of the front-end ISA2k firewall

2. Make the SBS 2003 SP1 box a Firewall client of the front-end ISA2k firewall

3. Make the SBS 2003 SP1 box a SecureNAT client of the front-end ISA2k firewall

4. Some combination of the above

I would do all three. However, there is a bug in ISA 2004 that doesn't allow authentication when doing Firewall Chaining (Web Proxy chaining auth works fine). So, don't require auth for non-Web protocols.

This would be a great topic for an article series, but I wonder how many people would apply this config?

Thanks!
Tom