SMTP Servers see Firewall IP rather than Sending Domain' s IP

[Don_Draper]

We have an interesting problem we recently uncovered. While I do not think the problem is with the Fortigate 200A at this time, I was hoping someone could give me some insight on what conditions could cause the firewall to send its own aministrative public IP address rather than the public IP of the virtual IP for the sending domain to another email server. We have two MDaemon email servers behind a single Fortigate 200A. We use NAT mode and virtual IP' s to translate internal, non-routable IP' s to public IPs. Each mail server hosts a couple of domains. There is only one single outbound policy on the Fortigate. Each domain has its own virtual IP so there is the internal as external IPs for each. We recently noticed that some outbound SMTP transactions were getting rejected by the receiving email server due to the absence of a DNS PTR record for the IP. However all of the domains have PTR records. We then realized the receiving server was seeing the Fortigate' s public admin IP and not the virtual public IP of the sending domain as it should. There is no PTR record for the firewall admin IP so of course the email is rejected. Only of the MDaemon email servers is experiencing this problem so this makes us think the Fortigate is not the source. Also, all the domains (and thus multiple virtual IPs) are affected on the MDaemon server that is experiencing the problem. The bad MDaemon email server was upgraded to version 10 a few weeks back and everything so far seems to point to it as the source of the issue. We will be moving the MD v10 email server back to a previous version to match the one that is currently ok. My question is what would the email server have to do in order for the Fortigate to use its own public admin IP rather than the public virtual IP? My simple guess is that the email server is not binding to any internal IP that the Fortigate recognizes and thus its having to use its own IP. I am not a network engineer so this is an uneducated guess. Could someone provide some inside to what might be causing this issue? A different but somewhat related question is I noticed I have NAT checked on the single outbound policy but not on any of the inbound ones. Should the outbound policy have NAT checked? Thanks so much in advance. Don

[Don_Draper]

Thanks for prompt reply.

Create an IP Pool with the virtual public IP. On your outbound policy that handles the SMTP traffic, set the NAT to use the IP Pool.

I have never had to do this before so can you elaborate on why I would do this. My other mail server behind the same Fortigate is working fine such that the outbound emails have the correct public IP of the sending domain (VIP) and not the fortigate. Also, I have only one outbound policy for all services. Perhaps I need to create service specific outbound policies but this may be outside the scope of my current issue.

To your second question. You mentioned that you " translate internal, non routable IP' s to public IPs." that' s already the answer: When you do not NAT on your outbound policies, your non routable internal IP' s are set as Source Address. The packets from the target will not find it' s way back to you.

So if understand what you are saying here...I have to have the NAT checked on my outbound policy. Correct? Thanks again. Your assistance is very much appreciated.

[abelio]

I have never had to do this before so can you elaborate on why I would do this.

exactly following Maik´s advice. Within VirtualIP menu, you´ll find IP pool menu; create a new one with just one IP in this range (IP public you want visible for your mailserver), interface, the outbund one. Now, your outbound firewall policies will have an extra dropbox to choose your ip pool.

My other mail server behind the same Fortigate is working fine such that the outbound emails have the correct public IP of the sending domain (VIP) and not the fortigate.

this can only happen when your external public address matches mailserver public IP. (and VIP external IP logically)

Also, I have only one outbound policy for all services. Perhaps I need to create service specific outbound policies but this may be outside the scope of my current issue.

exactly. Define a new outbound policy just for outgoing email, use it your IP pool as Maik pointed, and put the policy above other with same src/destination and that´s all. regards

[Don_Draper]

Thanks very much for the prompt replies. I found the problem. We had changed one of our VIPs to accomodate a new web site but had failed to make the same change in the email server. I guess since the Fortigate did not recognize the email servers internal IP (that was changed in VIP change), it had to use its own. We had looked at that multiple times so I guess it was a case of just being too close. Each of our hosted domains (just a handful) each have their own public IP so we use VIPs for each one. In other words, a direct 1 to 1 internal to public IP translation. So we have never had to use pools in the past. I will read up on this more however as I sure this would be helpful in the future. Thanks again.

[abelio]

I guess since the Fortigate did not recognize the email servers internal IP (that was changed in VIP change), it had to use its own. We had looked at that multiple times so I guess it was a case of just being too close.

not exactly; from administration guide: Enable or disable Network Address Translation (NAT) of the source address and port of packets accepted by the policy. When NAT is enabled, you can also configure Dynamic IP Pool and Fixed Port. If this option is not selected, but a virtual IP is selected as the Destination Address, the FortiGate unit performs destination NAT (DNAT) rather than full NAT. Source NAT (SNAT) is not performed. regards