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.



-Cliff


"Freaky" <wontsay@newsgroup> wrote in message
news:#L#8w4KiKHA.1652@newsgroup

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

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.

-Cliff


"Freaky" <wontsay@newsgroup> wrote in message
news:uZN2DkSiKHA.3964@newsgroup

> 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.
>>
>> -Cliff
>>
>>
>> "Freaky" <wontsay@newsgroup> wrote in message
>> news:#L#8w4KiKHA.1652@newsgroup

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

>>

>