[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Issues w/ Exchange and NAT on a Cisco PIX 501

Posted on 2006-03-21
17
Medium Priority
?
6,237 Views
Last Modified: 2013-11-16
I recently deployed an exchange server, and am getting some messages kicked back from large ISP's like AOL and comcast. Whenever the message gets kicked back, I get a message from the System Administrator that includes the following:

<xxxx01.x.CORP #5.5.0 smtp;521-EHLO/HELO from sender xxx.xxx.xxx.122 does not map to xxxx01.x.corp in DNS>

I am assuming this means that AOL is doing a reverse DNS lookup of the originating ip address and finding that it does not match the reverse DNS entry, and is classifying it as spam. That is easy enough, but the problem is that my mail should be originating from .123 which matches the reverse DNS entry.

My network is configured with my exchange server on the inside of the PIX with a static translation from 10.0.1.11 to the .123 adress. I think the problems resides with another entry on my pix :

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

As far as I can tell, this entry is translating all of my private address to the interface address of .122, which conflicts with the static translation referenced above, but is consistent with my problem. My two servers reside at .10 and .11, and my workstations use the range .100 - .255. I think I need to remove the NAT entry above, and replace it with one that specifies translation of the workstation range to a few public ip's .125 and .126, but I don't know how to write that command. Any help?
0
Comment
Question by:brainbolt
  • 8
  • 5
14 Comments
 
LVL 20

Expert Comment

by:calvinetter
ID: 16254150
>nat (inside) 1 0.0.0.0 0.0.0.0 0 0
  This is fine - don't remove it or your internal hosts won't be able to access the Internet!

>...with a static translation from 10.0.1.11 to the .123 adress
   Hmm, doesn't appear to be, since you're getting the following:
>...from sender xxx.xxx.xxx.122 does not map to xxxx01.x.corp in DNS

Please post all "static (inside,outside)..." & "nat (inside)..." statements, with public IPs masked like so: x.x.x.123

cheers
0
 
LVL 51

Expert Comment

by:Keith Alabaster
ID: 16254866
Can you check that you have a reverse dns entry for your domain (the MX record)?
AOL performs a reverse dns lookup and if this does not resolve to you, they will block/reject your mails. This is a fairly popular method of trying to del with spoof emailing.
regards
Keith
0
 
LVL 2

Author Comment

by:brainbolt
ID: 16258661
calvinetter: here are the statements.

global (outside) 1 interface
nat (inside) 0 access-list VPN-nonat
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) tcp x.x.x.124 3389 10.0.1.10 3389 netmask 255.255.255.255 0 0
static (inside,outside) tcp x.x.x.123 www 10.0.1.11 www netmask 255.255.255.255 0 0
static (inside,outside) tcp x.x.x.123 smtp 10.0.1.11 smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp x.x.x.123 3389 10.0.1.11 3389 netmask 255.255.255.255 0 0
static (inside,outside) tcp x.x.x.123 pop3 10.0.1.11 pop3 netmask 255.255.255.255 0 0

-----

keith_alabaster: I had my isp setup a reverse dns entry for xxxx01.x.corp pointing to x.x.x.123. I believe that it is setup right because if I go to dnsstuff.com and do a reverse dns lookup for the .123 address, I get this response:

x.x.x.123 PTR record: xxxx01.x.corp. [TTL 3600s] [A=None] *ERROR* There is no A record (may be cached).
0
Automating Your MSP Business

The road to profitability.
Delivering superior services is key to ensuring customer satisfaction and the consequent long-term relationships that enable MSPs to lock in predictable, recurring revenue. What's the best way to deliver superior service? One word: automation.

 
LVL 51

Expert Comment

by:Keith Alabaster
ID: 16260000

PASS
Reverse DNS entries for MX records
OK. The IPs of all of your mail server(s) have reverse DNS (PTR) entries. RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry. Note that this information is cached, so if you changed it recently, it will not be reflected here (see the www.DNSstuff.com Reverse DNS Tool for the current data). The reverse DNS entries are:

226.119.50.208.in-addr.arpa lon-g2.caa.co.uk. [TTL=3600]
98.229.48.208.in-addr.arpa gat-g2.caa.co.uk. [TTL=3600]

The above is the result for my domain
 
Use the dnsstuff reporter. (www.dnsreport.com)
Put in your domain name in the left hand box and then scroll down the results. The above is what you should see (similar) for your MX records.

0
 
LVL 2

Author Comment

by:brainbolt
ID: 16260332
keith_alabaster: I'm not sure I understand. I have a reverse DNS entry setup for my mail server, as shown by the response I posted from the dnsstuff.com test (x.x.x.123 PTR record: xxxx01.x.corp. [TTL 3600s] [A=None] *ERROR* There is no A record (may be cached)). Am I missing something?

If I go to dnsreport.com and run the test you suggested, I get the folowing message:

[ERROR: corp doesn't have its own zone. I only handle domains with their own zone and a direct parent zone (just example.com or example.co.uk, not www.example.com or 192.0.2.25 or www.example.co.uk). Try running the test using corp instead.]

The name of my my internal domain is xxxx.CORP. When the domain was originally setup, it was named that way, so it does not match my company website domain name. Could this be causing the problem? How?
0
 
LVL 51

Expert Comment

by:Keith Alabaster
ID: 16261070
That is because corp is NOT a zone name.

Yes, the lookup you need to be performing in www.dnsreport.com needs to be based on the email addresses as far as the outside world see thems. So if your emails go out as you@whatever.com then whatever.com is the one you need to be looking up in dnsreport.com

For example. all my emails internally have me@internal.zone1 but anything I sent out for delivery to the internet goes out as me@caa.co.uk. If I do a lookup at caa.co.uk, I get the reverse entries as per my post above. Those entries resolve to my mail senders.

corp, as you state, is your internal name, not how the outside world sees you. It is this outside reverse lookup that I think you will find AOL cannot recognise.
0
 
LVL 51

Expert Comment

by:Keith Alabaster
ID: 16261834
The records are not correct.  If I do a dnslookup on your IP address, i get a name back ok. If I then do a search on the domain name it returns, it tells me that the domain does not exist. If the two are not 'tied' together, AOL (and others) will reject your mail.
To test the comparison,

do an nslookup on gat-g2.caa.co.uk. This will return 208.48.229.98 which is the ip address of my mail server.

now do an nslookup on that ip address. It will return the name of my mail server (gat-g2.caa.co.uk). Therefore AOL can prove that the emails have come from my domain and the IP address is assigned to me.  ie I am not spoofing the address.

Can you do the same on yours? I think you can't.

0
 
LVL 2

Author Comment

by:brainbolt
ID: 16262192
Correct, because it returns the xxxx01.x.corp address, which is not a zone name, as you mentioned before.

It looks to me like I have to change the name that it is returning when the ip address is looked up. My exchange server is broadcasting it's name as xxxx01.x.corp to the world, but the world cant get back to that name because it is not a zone name. Is that a fair statement? Do I have to rename my internal domain to match my website domain to be able to do that?
0
 
LVL 51

Expert Comment

by:Keith Alabaster
ID: 16262742
The external interface of the PIX, is this physical interace using the .122 address?

0
 
LVL 2

Author Comment

by:brainbolt
ID: 16276543
Sorry for the slow response. Yes, the external interface on the pix is set to x.x.x.122.
0
 
LVL 51

Expert Comment

by:Keith Alabaster
ID: 16283046
OK. So the NAT element is not working for traffic coming out of your SMTP server and leaving the PIX.

ie Your MX record says to find you on .123 but you are sending from the .122 record therefore your reverse dns does not tally. Your NAT command tells everything to go out with the external interface IP address (.122) so we need an additional NAT or you can change the MX record to point to .122.

I'll just get the NAT command for you but then its your call.

0
 
LVL 51

Accepted Solution

by:
Keith Alabaster earned 500 total points
ID: 16287370
Add a global and NAT combination so that mail leaving from the smtp server through the PIX leaves as the .123 address.
0
 
LVL 2

Author Comment

by:brainbolt
ID: 16301133
Added these two statements to my PIX config:

global (outside) 10 x.x.x.123
nat (inside) 10 10.0.1.11 255.255.255.255 0 0

Emails are now originating from the correct IP address, and are being accepted by AOL.

Thanks, keith_alabaster.
0
 
LVL 51

Expert Comment

by:Keith Alabaster
ID: 16302535
Thanks Brandon.

Good job
Regards
keith
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This past year has been one of great growth and performance for OnPage. We have added many features and integrations to the product, making 2016 an awesome year. We see these steps forward as the basis for future growth.
For months I had no idea how to 'discover' the IP address of the other end of a link (without asking someone who knows), and it drove me batty. Think about it. You can't use Cisco Discovery Protocol (CDP) because it's not implemented on the ASAs.…
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:   • Key questions to ask when considering a partnership to accelerate your business into the cloud • Pitfalls and mistakes other partners…
Suggested Courses
Course of the Month19 days, 7 hours left to enroll

873 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