Even with NAT disabled, my point is that a NIC gets an IP bound to it as
part of the windows networking stack initialization. Even with a rule
published in TMG, that IP should not be directly accessible externally. You
may not agree with me on that point, but considering you obviously *have*
problems with traffic getting to and from your security server, you may not
want to dismiss my assessment *quite* so quickly. That is, of course,
ultimately your decision to make however.
"Freaky" <wontsay@newsgroup> wrote in message
> No, not really. I have turned of NAT and set it to routing. The
> Fortigate knows the route oc and there is a publish rule in TMG that
> exposes it. Without the TMG publish rule internal is not reachable.
> All e-mail is stuck in the queue under 'submission'. Normally, when
> routing to external, it creates queues for the domainname.
> Thanks for the re'.
> On 29-12-09 19:47, Cliff Galiher wrote:
>> Just the fact that you can forward traffic to 10.1.1.254 is a sign that
>> you have a physical network problem. The NIC with that IP should not be
>> directly reachable from the fortigate, so the fact that the fortigate is
>> reaching it shows an exposed internal NIC on the external network.
>> "Freaky" <wontsay@newsgroup> wrote in message
>>> Hi there,
>>> whilst I was on vacation my collegues installed our first 2008 EBS
>>> server(s) at our office location. Whilst doing this they used the DNS
>>> servers for our ISP, as well as probably some other settings they had to
>>> change to make it fit the network here.
>>> Currently the network layout is as follows:
>>> Internet <ext ip> FortiGate Firewall <10.10.1.1> <-> <10.10.1.254> TMG
>>> Server <10.1.1.254> <-> LAN (10.1.x.x/16).
>>> By now I finally got the outgoing e-mail working. Several things I find
>>> *extremely* peculiar.
>>> I have reset all the firewalls rules back to default on the TMG server,
>>> enabling everything as it was. As there is an internal subnet between
>>> the external gateway and the TMG I have changed TMG to do routing (and
>>> thus not NAT) on the external IP. Changed the security level to
>>> medium-high and added a rule to allow all traffic out (otherwise only
>>> HTTP/HTTPS gets out from clients).
>>> First thing I noticed is that in the default rules SMTP is published,
>>> but this is not reachable on the external IP of the TMG (10.10.1.254).
>>> Telnetting to 10.10.1.254 25 from the fortigate (from 10.10.1.1 thus)
>>> results in no connection. Forwarding 25 from the external IP on the
>>> fortigate to the 10.10.1.254 IP (external TMG) results again in no
>>> connection. This I find very peculiar, as if there was no additional
>>> firewall the 10.10.1.254 should be considered external and thus SMTP
>>> traffic should work on it, otherwise one can not receive email at all.
>>> Forwarding to 10.1.1.254 works though. Which I find very peculiar (I did
>>> add a route on the fortigate that 10.1.0.0/16 is behind 10.10.1.254 oc)
>>> and scary as it's forwarding to an internal IP behind another firewall
>>> and that firewall should be routing/accepting or nat'ing/forwarding it,
>>> and I think something is seriously borked because of this.
>>> Mail now enters the queue on the TMG/Edge Transport. There the first
>>> thing I see in message tracking is it entering from external client IP
>>> to 10.1.1.254. And after that things start to get really strange.
>>> I see the same e-mail message tens of times after that, only now it
>>> comes from the internal IP of the fortigate (10.10.1.1) going to
>>> 10.1.1.254 (internal TMG) (I think it is source NAT'ed because the
>>> source was internal and then going to external IP (because of DNS lookup
>>> resulting in MX records pointing at external IP) and because then after
>>> port forward it would look like 10.1.1.254 -> 10.1.1.254 it is source
>>> nat'ed by the fortigate to keep it working). After that it will show up
>>> as going from 10.10.1.254 (external TMG) going to x.y.200.1 (where our
>>> external IP is x.y.200.125/29, so not in our subnet but definitely
>>> close). I don't know what the modem uses as gateway, our gateway is
>>> x.y.200.126 (which is the modem thus) and I am guessing it's the gateway
>>> behind the modem.
>>> These 2 lines repeat over and over. There is no mailserver on the
>>> x.y.200.1, there is no smarthost configured either (all mail should be
>>> routed through DNS), so why it hits that IP is beyond me. I don't find
>>> the tracking center very informative. In 2003 one could see states, etc,
>>> all you see now are some ID's, IP's and that's about it. Can I see more?
>>> It seems that although the edge server recognizes the domains for
>>> incoming as accepted locally, it doesn't know how to route them to the
>>> exchange server. What's also strange is that recipient filtering is on,
>>> it still accepts nonexistant@newsgroup which it then
>>> obviously would need to bounce afterwards.
>>> Earlier I didn't get any mail out either. It all got stuck in the
>>> outgoing queue with a 451 DNS lookup failure. Removed the DNS servers
>>> (externally) that were entered in the external interface. Besides the
>>> fact they aren't from the ISP the customer uses (and thus won't respond)
>>> the default TMG settings actually do *not* allow the TMG server to
>>> access DNS on the internet. So I'm just using the internal DC's DNS
>>> servers now which is fine. Still didn't work as the Edge Transport was
>>> still trying to use DNS servers from the external interface, which were
>>> none.... So set them manually in the edge transport config. Outgoing
>>> mail is fine now.
>>> On 2003 SBS one would probably easily solve this by running the internet
>>> and e-mail wizard again, but I see nothing of the likes.
>>> I'm somewhat reluctant to continue troubleshooting with my default
>>> methods as these are non-EBS/SBS oriented. With 2003 this frequently
>>> resulted in the very fine wizards biting us in the ass when they were
>>> ran again and so I'd like to do this as much through the official EBS
>>> wizards/toolies as possible.
>>> Any help is greatly appreciated.