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

Discussion in 'Windows Small Business Server' started by Freaky, Dec 30, 2009.

  1. Freaky

    Freaky Guest

    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
    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 :)
    Freaky, Dec 30, 2009
    1. Advertisements

  2. 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

    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 Galiher, Dec 30, 2009
    1. Advertisements

  3. Freaky

    Freaky Guest

    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).
    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:
    Freaky, Dec 31, 2009
  4. Freaky

    Freaky Guest

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

    Output from netstat:


    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.
    Freaky, Dec 31, 2009
  5. Freaky

    Freaky Guest

    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 :D

    Thanks for the help.
    Freaky, Dec 31, 2009
  6. 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 Galiher, Dec 31, 2009
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.