EBS 2008, TMG and external firewall. Don't want double NAT

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

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" <> wrote in message
news:...
> 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

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" <> wrote in message
> news:...
>> 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
>

Hit some key combination that equals send by by accident (not even on
the official list ).

Output from netstat:

TCP 0.0.0.0:25 0.0.0.0:0 LISTENING

by now I'm pretty confident on getting the firewall to work. As setting
it to low doesn't actually remove rules but just inserts the rule on top
which allows all traffic I'll just ditch that one and then customize the
rest and see what happens.

My largest issue now is incoming mail isn't working. This gets in a
loop. The edge server seems to try an route it through DNS, which is odd
as it should be aware of the local users and that they're hosted on the
Exchange server.

Running the cmd-let start-edgesynchronization clearly shows it syncing
settings. I already trashed the edge subscription, this also removed the
2 edge send connectors, and resubscribed (twice). Every time
test-edgesynchronization etc. seem to run fine. I see the send
connectors being made, they show up on the edge, the accepted domains
show up, outgoing mails start functioning and inspecting the headers
clearly shows they are send from exchange -> edge -> outside.

The incoming mail however comes into edge and then edge tries to send it
to the MX record (which is the external firewall, which forwards 25 to
edge...). That something is wrong also clearly shows in edge accepting
whilst recipient filtering is turned on and as
the addresses are replicated to it's ADAM database it should be very
aware of the address not existing.

Any ideas on debugging that? The cmdlets I saw to test edge don't turn
up anything useful, sync works fine... or well, according to the
cmdlets. As the list of accepted domains is published to the edge and
the connectors appear etc. it should atleast work largely too.

Thanks for bearing with me.

Seem to have it working now. The recipient filtering was configured
properly and was enabled but had to start/enable the agent through
powershell to get it to work.

Enable-TransportAgent "Recipient Filter Agent"
Restart-Service msexchangetransport



After resubscribing edge this time (and thus recreating edge connectors)
I got a new error. It nicely tried to send it to exchange, but my
collegue had made a new receive connector here for the entire internal
LAN for the fake POP3 accounts (we use these to allow people to send out
under other e-mail addresses). This was picking up the mail from the
Edge server and now gave an authentication failure.

Finally got rid of the big issues, so pressure is relieved. Can make it
home on time for new year now

Thanks for the help.


On 31-12-09 09:29, Freaky wrote:
> Hit some key combination that equals send by by accident (not even on
> the official list ).
>
> Output from netstat:
>
> TCP 0.0.0.0:25 0.0.0.0:0 LISTENING
>
> by now I'm pretty confident on getting the firewall to work. As setting
> it to low doesn't actually remove rules but just inserts the rule on top
> which allows all traffic I'll just ditch that one and then customize the
> rest and see what happens.
>
> My largest issue now is incoming mail isn't working. This gets in a
> loop. The edge server seems to try an route it through DNS, which is odd
> as it should be aware of the local users and that they're hosted on the
> Exchange server.
>
> Running the cmd-let start-edgesynchronization clearly shows it syncing
> settings. I already trashed the edge subscription, this also removed the
> 2 edge send connectors, and resubscribed (twice). Every time
> test-edgesynchronization etc. seem to run fine. I see the send
> connectors being made, they show up on the edge, the accepted domains
> show up, outgoing mails start functioning and inspecting the headers
> clearly shows they are send from exchange -> edge -> outside.
>
> The incoming mail however comes into edge and then edge tries to send it
> to the MX record (which is the external firewall, which forwards 25 to
> edge...). That something is wrong also clearly shows in edge accepting
> whilst recipient filtering is turned on and as
> the addresses are replicated to it's ADAM database it should be very
> aware of the address not existing.
>
> Any ideas on debugging that? The cmdlets I saw to test edge don't turn
> up anything useful, sync works fine... or well, according to the
> cmdlets. As the list of accepted domains is published to the edge and
> the connectors appear etc. it should atleast work largely too.
>
> Thanks for bearing with me.
>

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" <> wrote in message
news:...
> 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" <> wrote in message
>> news:...
>>> 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
>>
>