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

Question

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 · Answer

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.

Sign up

Login with SSO

Login to the community

Login with SSO