Solved

Exchange 2007 SPF showing SonicWall X1 public IP.

Posted on 2013-06-20
8
753 Views
Last Modified: 2013-07-02
Sorry if this is a long one, but here it goes. I have Exchange 2007 that was running on Server 2003 x64. Powershell got removed, and since my option at that point wasn't simply to reinstall powershell; I moved the database over to a new Server 2008 machine and synced IIS across. After a long weekend of working out the bugs and getting our BES 10 to work with it again, I finally got everything working. That is until I noticed we were getting more delivery failed notifications than usual.
   I started sending test emails to my outside accounts and noticed Yahoo shows Received-SPF: fail (domain of mydomain.org does not designate xx.xxx.xxx.xx as permitted sender). The ip address it showed was from my SonicWall public IP. Most people would say I'm OK since this didn't have an error code, but other sites like Hotmail are flagging my emails as spam. Now is when it gets into the crazy workings of our setup, I hop you can bear with me.
   So, I have a public IP set up for our Exchange server, It is registered with our ISP as mail.mydomain.org. That IP is NATed to our internal Exchange IP address in our SonicWall. Our internal domain lets say is mydomain.local, not .org. So the Exchange server is Exchange.mydomain.local. I have a DNS pointer to exchange.mydomain.local with the internal IP, and a MX record for exchange.mydomain.local. In our Exchange Management Console, every place that asked for FQDN for ehlo or helo response I put exchange.mydomain.local. I noticed the txt files we had for spf info in our DNS server were outdated from our last mail server (which was called mail.mydomain.org) so I changed it to reflect the new server.
   So my big problem is when I check the header info from my test emails, no matter what I change it is still showing that Public IP address from our Sonicwall. Is this a routing issue within our SonicWall? Or is there somewhere else I should be looking? Any help is greatly appreciated!!! Thanks!
0
Comment
Question by:rmayo
  • 5
  • 2
8 Comments
 
LVL 34

Assisted Solution

by:Seth Simmons
Seth Simmons earned 80 total points
ID: 39262513
i'm not really familiar with sonic wall, but from a general firewall standpoint, it sounds as though the original mail server was going out configured to use a different public IP than  your gateway, specifically the address in the public spf/mx records and now with a different machine it doesn't have that so it uses the gateway address which is different causing the SPF check to fail.

for example, if your public gateway address was 100.100.100.1 external and 192.168.1.1 internal and your exchange server public address was 100.100.100.2 with internal address 192.168.1.2, there could have been a sonic wall rule that says for traffic going out from 192.168.1.2 set source IP as 100.100.100.2 but now your new server you just configured might be internal 192.168.1.3 with no source IP configured for outgoing traffic on the firewall so it appears to the outside to have a source of 100.100.100.1 which doesn't match SPF record.  it isn't a routing issue, sounds as though traffic from that new server needs to be configured to have the correct public address matching spf/mx records for outgoing traffic.  hope that makes sense.
0
 

Author Comment

by:rmayo
ID: 39262531
I see what you're saying. I'll specify a little more. My local exchange server IP adress lets call it 192.168.1.1 was taken from the the old send mail server when it was taken out of production. I never set up a public gateway address. It just has the internal gateway that it has always had. We are using a NAT in our SonicWall that says anything sending to our public exchange IP will NAT to 192.168.1.1.
0
 

Author Comment

by:rmayo
ID: 39263037
Anyone?
0
 
LVL 14

Assisted Solution

by:Kaffiend
Kaffiend earned 160 total points
ID: 39264699
I think seth2740 may be on the right track - it is definitely worth checking out (unless you were the only person to have ever configured that Sonicwall, and absolutely do not remember ever setting up an NAT statement that applies to *outgoing* traffic from the old mail server)

Look at your firewall, and see if you have a NAT policy that looks something like this:
(In the firewall, the stuff below is laid out horizontally, and we are looking for the first 2 fields)

------------------------------------ Sonicwall > Network > NAT Policies ---------------------------------------
Source
Original: old email server's private IP address (you may need to hover your mouse over a field to discover the actual IP address associated with a named object)
Translated: the public IP address you need the mail server to use


-----------------------------------------------------------------------------------------------------------------------------

If you see a NAT Policy in the Sonicwall config where the beginning of that policy looks like that, then that is the line you will need to modify.  It should be pretty obvious what to change once you spot this line

If you don't, then that is a policy you will need to create, which will make outgoing communication from the mail server use the public IP address you want it to use
0
Do email signature updates give you a headache?

Constantly trying to correctly format email signatures? Spending all of your time at every user’s desk to make updates? Want high-quality HTML signatures on all devices, including on mobiles and Macs? Then, let Exclaimer solve all your email signature problems today!

 

Author Comment

by:rmayo
ID: 39264802
After spending all day investigating, I am now thinking it isn't the sonicwall. We had mail sending last week fine before we migrated our Exchange over to a Windows 8 server. (And no, it isn't SBS) We had server 2003 before. I searched through some outgoing emails last week and found the header included the correct Public IP address for our mail server. Also, I don't think it could be our DNS. Even though we have the same spf txt files, ptr, and mx records that we had way back when we had sendmail, the ip addresses and server name has always stayed the same. Besides, it worked with our 2003 server. Sorry my parameters for my question seem to keep changing, but I'm learning as I dig into the issue. The only problem we had with the migration to server 2008 was a few hiccups going from IIS 6 to IIS 7.  Is there anything in IIS that could cause these problems? I appreciate everyone's feedback to far.
0
 
LVL 14

Assisted Solution

by:Kaffiend
Kaffiend earned 160 total points
ID: 39267392
If you want the mail server to use an IP address different from your firewall, you need to have (or create) a NAT policy on the Sonicwall that makes that server's communication use that particular IP address.  Doesn't really matter if you are using a Sonicwall, a Cisco device, or anything else - you need to have some kind of rule/policy on the firewall that makes traffic from the server use a different IP address than the default.  

Actually, I'm afraid I am not sure what the question is anymore :)  
If I read correctly, you want email sent from your mail server to look like it comes from a particular, specified IP address, and not from the IP address of the Sonicwall.  If that is the case, then see above.  If it's not, then please re-frame the question to let us know more specifically what you feel the problem is, so that we can try and help you to a solution.
0
 

Accepted Solution

by:
rmayo earned 0 total points
ID: 39281466
We finally got it figured out. Our new Exchange server is a virtual, and it has 2 NIC cards assigned to it. The server was sending on the secondary NIC that was setup on the server so the NAT wasn’t applying to it.  We adjusted the NAT and server to ensure that both NIC’s were capable of sending out of the NAT so these SPF issues would not arise again.
0
 

Author Closing Comment

by:rmayo
ID: 39292537
As with any network, no one can possibly understand your setup like you can. Understandably it is difficult to give someone else from the outside a full picture of your network. I took the solutions from everyone else and used them to rule out all other possible causes. This led me to trace further down the line of outgoing mail and eventually to the server's NICs themselves.
0

Featured Post

Better Security Awareness With Threat Intelligence

See how one of the leading financial services organizations uses Recorded Future as part of a holistic threat intelligence program to promote security awareness and proactively and efficiently identify threats.

Join & Write a Comment

Suggested Solutions

Easy CSR creation in Exchange 2007,2010 and 2013
This article explains in simple steps how to renew expiring Exchange Server Internal Transport Certificate.
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

747 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now