Re: EBS 2008, TMG and external firewall. Don't want double NAT
- From: "Cliff Galiher" <cgaliher@xxxxxxxxx>
- Date: Wed, 30 Dec 2009 11:41:57 -0700
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@xxxxxxxxxx> wrote in message news:uBpMCSWiKHA.1236@xxxxxxxxxxxxxxxxxxxxxxx
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 :D).
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 :)
.
- Follow-Ups:
- References:
- Prev by Date: Re: Exchange 2003, Google DNS, and IMF Connection Filtering RBL Failures
- Next by Date: SBS 2008 / Outlook 2007 Problem with LogIn-Window
- Previous by thread: EBS 2008, TMG and external firewall. Don't want double NAT
- Next by thread: Re: EBS 2008, TMG and external firewall. Don't want double NAT
- Index(es):
Relevant Pages
|
