NAT rule best practice for a mail server?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

NAT rule best practice for a mail server?

L4 Transporter

Hello folks,

 

We changed our public ips recently and we have a few recipeints that are blocking our new mail IP.  I am suspecting has something to do with either our TXT (SPF) record or the fact that we are using a destination NAT rule instead of bi-directional.

 

I've included a diagram and notes below, but trying to get some feedback on what the problem might be and if there is a general best practice based on experience.

 

In general: I am thinking that we should make our NAT rule bi-directional so that it's source IP when initating to internet from mail server is the assigned IP rather than the general NAT IP/Port to the firewall interface.  

 

Any comments or feedback?

 

mail3.jpg

 

mail2.jpg

 

mail.jpg

Using nslookup MX record return correctly as assigned IP: 96.68.102.139.

Also trying to get feedback from technet.

https://social.technet.microsoft.com/Forums/office/en-US/2e3def39-3f37-4883-a21a-182fc57dfa6f/exchan...

 

1 accepted solution

Accepted Solutions

Set up your SNAT and DNAT rules so that incoming and outgoing email would go out from same public IP.

Or set up SNAT as bi-directional.

 

Neither of those IPs you mentioned resolve to anything reasonable.

You have to ask your ISP to update reverse DNS record for the IP where emails are going out from.

Reverse DNS has to resolve to email domain.

 

C:\>ping -a 96.68.102.139

Pinging 96-68-102-139-static.hfc.comcastbusiness.net [96.68.102.139] with 32 bytes of data:

 

C:\>ping -a 96.68.102.140

Pinging 96-68-102-140-static.hfc.comcastbusiness.net [96.68.102.140] with 32 bytes of data:

 

 

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

View solution in original post

7 REPLIES 7

Cyber Elite
Cyber Elite

@OMatlock,

While I would generally run SMTP servers with a bi-directional, this is far from a requirement. It really looks like you got assigned a bad IP. Go through Office's IP Delist process and get your IP removed from the Anti-Spam list; I bet when it gets removed you'll find everything works fine. 

Many spam filters do reverse dns lookup and if IP does not resolve back to correct domain then they flag email as spam.

Ask ISP to update reverse dns information.

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

L2 Linker

Bi-directional NAT would be simpler. Your HELO should match DNS in both directions, in additional be listed in your SPF record. It is also possible that your IP is blacklisted.

Thanks for the feedback.

Yea, in our Exchange server there is a message:

"Client host rejected: cannot find your reverse hostanme [96.68.102.140]"

 

The Client here is one of our customers that is rejected our email.  The IP shown above is the outbound source IP based on our general internet access IP and port address, not the mail assigned IP of .139.

 

Does it still sound like just an ISP/DNS update problem?

 

I am trying to determine if our firewall rule needs to change, TXT record, or other.

 

 

Set up your SNAT and DNAT rules so that incoming and outgoing email would go out from same public IP.

Or set up SNAT as bi-directional.

 

Neither of those IPs you mentioned resolve to anything reasonable.

You have to ask your ISP to update reverse DNS record for the IP where emails are going out from.

Reverse DNS has to resolve to email domain.

 

C:\>ping -a 96.68.102.139

Pinging 96-68-102-139-static.hfc.comcastbusiness.net [96.68.102.139] with 32 bytes of data:

 

C:\>ping -a 96.68.102.140

Pinging 96-68-102-140-static.hfc.comcastbusiness.net [96.68.102.140] with 32 bytes of data:

 

 

Enterprise Architect, Security @ Cloud Carib Ltd
Palo Alto Networks certified from 2011

Thank you for that @Raido_Rattameister

I should have mentioned that I am using example IPs so not to disclose our real ones.

Sorry about that...

 

Thanks again, I will follow up with your suggestions.

@Raido_Rattameister

@khsieh

@BPry

 

Y'all were right.  Needed to create new PTR records with new ISP.  Once I did that, our TXT (SFP) is passing.

I also did change our Mail server NAT rule to bi-directional.

 

I learn so much for you all, thank you!!!

  • 1 accepted solution
  • 6447 Views
  • 7 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!