You should *Really* consider moving this to an EBS specific group so you get
more insight. SBS doesn't come with TMG at all and ISA2006 isn't exactly
comparable.

With that said, here is my quick synopsis.

EBS comes with several preconfigured rules. These aren't created by TMG,
but are created *by* EBS during install and are done based on the default
installation configuration. Thus if you are changing things, you have to
expect to change rules.

You should have three SMTP rules. With NAT, the first rule is a publishing
rule from the external interface to the internal interface. This is done
because Exchange is bound to the internal interface and leaves the external
interface to be *completely* controlled by TMG...a good security guideline
by the way. Since Exchange is listening on the internal IP, you have to get
traffic there. If you are disabling NAT then you'll need to change this
from a publishing rule to an access rule, but it should still work fine.

You should also have two other SMTP rules predefined. The first is an access
rule allows traffic from the internal IP to the external interface (for
outgoing mail from exchange) and to the messaging server (from the edge
server to the hub server.)

The third rule allows SMTP traffic from the messaging server to the internal
IP of the security server. This allows the exchange hub server to send mail
to the edge server for final delivery.



You also mention a rule that allows all traffic from anywhere to anywhere
and would negate all other rules. This is *not* a default EBS rule! In
fact, in a straight-out-of-the-box deployment, the last rule in the chain is
a "deny" rule from all protected networks to all protected networks for all
users. So while you are correct that such a rule would negate other rules,
simply removing the rule will alleviate that problem. Based on the other
facts you've uncovered during this deployment, I suspect someone added that
rule as a cheap band-aid to fix a problem they were seeing.

As far as the rest of your proposed setup, I don't envision any immediate
issues. The default rules should already have you covered. One of the
default rules is an "internet access for all users" that allows http and
https by default. This rule can be customized, however, to restrict users
or add protocols. If you run the "configure web access policy" wizard, the
rule mentioned above will be disabled automatically and more granular
caching and proxy rules will get created as well.

-Cliff




"Freaky" <wontsay@newsgroup> wrote in message
news:uBpMCSWiKHA.1236@newsgroup

> Hi there,
>
> this is actually somewhat of a double post. As the topic has shifted to
> TMG instead of e-mail issues (see my thread on EBS 2008 and e-mail
> issues).
>
> If I reset the firewall rules to default SMTP is published to
> the internal interface of the security server. It is then
> accessible through the external IP (whilst NAT is still turned on as is
> default on medium-high security).
>
> If I turn off NAT, it stops working however (on the external IP thus, if
> I forward from the firewall to the internal interface it works (external
> firewall knows the route),
> apparently this does use the publishing rule for acceptance of the
> traffic but not for the NAT part. Removing the publishing rule removes
> access to SMTP on the internal IP as well). My guess would be because
> the NAT setting is turned off and publishing requires some form of NAT
> (dst nat). If I forward to the Exchange server (yes I know I'm not
> supposed to do this, it's just for testing) a publishing rule works
> fine. Which leads me to conclude that DNAT on it's own interfaces (ie
> within the same box) won't
> work with NAT turned off. Which actually makes sense. I shouldn't need
> publishing in routing mode in the first place, unless I want to point to
> the security server IP and forward it internally (which thus leads to
> double dnat), but I could just
> create an access rule and dnat it from the external firewall to the
> internal one. This works as well.
>
> Something nice to point out, if you just change the setting to NAT and
> then change it back to routing, so one would assume nothing has changed,
> rerunning the change security level wizard is not possible. Apparently
> upon changing nat/routing mode it changes some other things and the
> wizard can not handle this. It will advise to reset the rule set to
> default.
>
> Need some advise now as I'm not really familiar with ISA/TMG. The
> customer here wants to exclude some users from internet. Our external
> firewall can only do this on IP basis (well I could work with FSAE which
> needs to be installed and then allow AD traffic from external firewall
> to internal, but this has issues with terminal users and opens holes in
> the TMG/middle firewall I rather not have), unfortunately we can't do it
> that
> simple here as users roam across workstations, so some form of
> authentication is required.
>
> I do NOT like double NAT. In fact I hate it . It makes logs in my
> external firewall nearly useless as everything passing it appears to
> come from the security server. And I've seen in the past that some
> applications don't work (well) with double NAT, although theory states
> it should not be an issue (all applications that don't NAT well due to
> random ports etc).
>
> As I must run the ISA/TMG, it might as well do something. So I figured
> I'd take the easy route, set the security level to medium-high, ISA/TMG
> will then filter etc. and just turn off the NAT and voila. This doesn't
> work thus.
>
> Setting the security level to low allows SMTP on the external interface.
> All rules except the first one are made useless as the
> first rule states:
>
> "From anywhere, to anywhere, any protocol, accept."
>
> This will obviously remove any firewalling on the external interface and
> thus opens 25 (in fact it reduces ISA to a basic router with a caching
> proxy). The publishing rule which remains further down doesn't do
> anything any more. All other features are disabled. No authentication,
> no packet filtering, no virusscanning, nothing but webcaching according
> to the manual.
>
> I'm thinking about doing the following now:
>
> Setting security level to medium-high.
> Changing to route mode.
> Remove the default SMTP publishing rule.
> Create an access (not publishing thus) rule for SMTP to the security
> server.
> Go past other rules and see what I can trash.
> Add a rule to allow all traffic out (for authenticated users and some
> static IPs).
>
> Whilst TMG isn't my favorite firewall, not using any of it's features if
> I must run it would be a shame. It might as well provide an additional
> level of defense and be used to block internet for users that aren't
> allowed (still have to figure out how to do this, but other issues now
> first.. like the rest of the migration ).
>
> Would this be a setup you'd recommend, or am I better of with security
> level low and adding all the features myself? Does anyone predict any
> problems with proposed setup? There are several rules in the TMG that
> seem to act like a reverse proxy rewriting URLs. Mainly the rules
> allowing access to the OWA, RWW, companyweb etc. Not sure what these
> will do.
>
> TIA

As I've mentioned in a previous post, the MS EBS group (and the SBS08 group
for that matter) is no longer hosted on usenet servers. MS runs private
servers that you can still use any NNTP client with (or a web interface if
you prefer) but searching usenet/techarena/etc will not reveal these groups.
connect.microsoft.com has an EBS group that is fairly active and has a
better chance of having more people that have done what you are attempting
to do.

-Cliff


"Freaky" <wontsay@newsgroup> wrote in message
news:OFPw8HfiKHA.1648@newsgroup

> Hi Cliff,
>
> once again, thanks for the responses. I tried searching an ebs group,
> but didn't find it (searched this server for business, ebs and essential).
>

>> You also mention a rule that allows all traffic from anywhere to
>> anywhere and would negate all other rules. This is *not* a default EBS
>> rule! In fact, in a straight-out-of-the-box deployment, the last rule
>> in the chain is a "deny" rule from all protected networks to all
>> protected networks for all users. So while you are correct that such a
>> rule would negate other rules, simply removing the rule will alleviate
>> that problem. Based on the other facts you've uncovered during this
>> deployment, I suspect someone added that rule as a cheap band-aid to fix
>> a problem they were seeing.

>
> This rule is actually created by EBS. But, this is done by the change
> security level tool that comes with feature pack 1 if you set the
> security level to low. This is the only level in which the tool will
> disable NAT. By default it's on medium-high.
>
> Whilst you are right on the security server controlling the external
> interface, it is not bound on only the internal interface. Netstat
> clearly shows this:
>
>

>> As far as the rest of your proposed setup, I don't envision any
>> immediate issues. The default rules should already have you covered.
>> One of the default rules is an "internet access for all users" that
>> allows http and https by default. This rule can be customized, however,
>> to restrict users or add protocols. If you run the "configure web
>> access policy" wizard, the rule mentioned above will be disabled
>> automatically and more granular caching and proxy rules will get created
>> as well.
>>
>> -Cliff
>>
>>
>>
>>
>> "Freaky" <wontsay@newsgroup> wrote in message
>> news:uBpMCSWiKHA.1236@newsgroup

>>> Hi there,
>>>
>>> this is actually somewhat of a double post. As the topic has shifted to
>>> TMG instead of e-mail issues (see my thread on EBS 2008 and e-mail
>>> issues).
>>>
>>> If I reset the firewall rules to default SMTP is published to
>>> the internal interface of the security server. It is then
>>> accessible through the external IP (whilst NAT is still turned on as is
>>> default on medium-high security).
>>>
>>> If I turn off NAT, it stops working however (on the external IP thus, if
>>> I forward from the firewall to the internal interface it works (external
>>> firewall knows the route),
>>> apparently this does use the publishing rule for acceptance of the
>>> traffic but not for the NAT part. Removing the publishing rule removes
>>> access to SMTP on the internal IP as well). My guess would be because
>>> the NAT setting is turned off and publishing requires some form of NAT
>>> (dst nat). If I forward to the Exchange server (yes I know I'm not
>>> supposed to do this, it's just for testing) a publishing rule works
>>> fine. Which leads me to conclude that DNAT on it's own interfaces (ie
>>> within the same box) won't
>>> work with NAT turned off. Which actually makes sense. I shouldn't need
>>> publishing in routing mode in the first place, unless I want to point to
>>> the security server IP and forward it internally (which thus leads to
>>> double dnat), but I could just
>>> create an access rule and dnat it from the external firewall to the
>>> internal one. This works as well.
>>>
>>> Something nice to point out, if you just change the setting to NAT and
>>> then change it back to routing, so one would assume nothing has changed,
>>> rerunning the change security level wizard is not possible. Apparently
>>> upon changing nat/routing mode it changes some other things and the
>>> wizard can not handle this. It will advise to reset the rule set to
>>> default.
>>>
>>> Need some advise now as I'm not really familiar with ISA/TMG. The
>>> customer here wants to exclude some users from internet. Our external
>>> firewall can only do this on IP basis (well I could work with FSAE which
>>> needs to be installed and then allow AD traffic from external firewall
>>> to internal, but this has issues with terminal users and opens holes in
>>> the TMG/middle firewall I rather not have), unfortunately we can't do it
>>> that
>>> simple here as users roam across workstations, so some form of
>>> authentication is required.
>>>
>>> I do NOT like double NAT. In fact I hate it . It makes logs in my
>>> external firewall nearly useless as everything passing it appears to
>>> come from the security server. And I've seen in the past that some
>>> applications don't work (well) with double NAT, although theory states
>>> it should not be an issue (all applications that don't NAT well due to
>>> random ports etc).
>>>
>>> As I must run the ISA/TMG, it might as well do something. So I figured
>>> I'd take the easy route, set the security level to medium-high, ISA/TMG
>>> will then filter etc. and just turn off the NAT and voila. This doesn't
>>> work thus.
>>>
>>> Setting the security level to low allows SMTP on the external interface.
>>> All rules except the first one are made useless as the
>>> first rule states:
>>>
>>> "From anywhere, to anywhere, any protocol, accept."
>>>
>>> This will obviously remove any firewalling on the external interface and
>>> thus opens 25 (in fact it reduces ISA to a basic router with a caching
>>> proxy). The publishing rule which remains further down doesn't do
>>> anything any more. All other features are disabled. No authentication,
>>> no packet filtering, no virusscanning, nothing but webcaching according
>>> to the manual.
>>>
>>> I'm thinking about doing the following now:
>>>
>>> Setting security level to medium-high.
>>> Changing to route mode.
>>> Remove the default SMTP publishing rule.
>>> Create an access (not publishing thus) rule for SMTP to the security
>>> server.
>>> Go past other rules and see what I can trash.
>>> Add a rule to allow all traffic out (for authenticated users and some
>>> static IPs).
>>>
>>> Whilst TMG isn't my favorite firewall, not using any of it's features if
>>> I must run it would be a shame. It might as well provide an additional
>>> level of defense and be used to block internet for users that aren't
>>> allowed (still have to figure out how to do this, but other issues now
>>> first.. like the rest of the migration ).
>>>
>>> Would this be a setup you'd recommend, or am I better of with security
>>> level low and adding all the features myself? Does anyone predict any
>>> problems with proposed setup? There are several rules in the TMG that
>>> seem to act like a reverse proxy rewriting URLs. Mainly the rules
>>> allowing access to the OWA, RWW, companyweb etc. Not sure what these
>>> will do.
>>>
>>> TIA

>>

>