Outbound mail fails - reverse dns lookup

[admin_2]

We have recently gone from a single WAN address in our NAT pool to multiple IPs. Reassigned our mail server IP to one of the new addresses and changed the MX with our ISP and also had them setup reverse DNS lookup. Some sites are refusing our mail due to failed reverse DNS lookup. The IP being returned is the first IP in our NAT pool rather than the WAN IP of our mail server. What am I missing?

[dbellazetin]

Can you post a sample configuration of your NAT set up and just replace the real address's with fake address's etc.

Daniel

[travis-dennis_2]

I wold check with the ISP to make sure that have an updated PTR record that reflects the IP address of the one the reverse DNS is failing on. If the recipients systems see your NAT pool address as the originating address (as it would seem since the IP address being returned is in the NAT pool) then as far as the recipient s concerned that NAT pool address is the sending e-mail server and not your public IP on the e-mail server itself.

Hope this helps.

Please remember to rate all replies.

[#4]

The ISP has a PTR setup on the x.x.x.186 address in the config above, and doing DNS and reverse DNS lookups from the net reveal the .186 number and resolve to the mail.domainname.com server. However the mails are showing they come from the .161 number listed in the NAT above.

[#5]

Here is the config from the interfaces through the NAT and access-lists.

interface Ethernet0

description connected to ISP

no ip address

no keepalive

half-duplex

pppoe enable

pppoe-client dial-pool-number 1

!

interface FastEthernet0

description connected to EthernetLAN

ip address 192.168.0.1 255.255.255.0

ip access-group 100 in

ip nat inside

ip inspect FastEthernet_0 in

speed auto

!

interface Dialer1

description connected to ISP

ip address x.x.57.234 255.255.255.252

ip access-group 101 in

ip mtu 1492

ip nat outside

ip inspect Dialer_1 in

encapsulation ppp

dialer pool 1

dialer-group 2

ppp authentication chap pap callin

ppp chap hostname host@isp.com

ppp chap password 7 xxxxxxxxxx

ppp pap sent-username host@isp.com password 7 xxxxxxxxxx

!

!

ip nat pool natmain x.x.252.161 x.x.252.190 netmask 255.255.255.224

ip nat inside source list 1 pool natmain overload

ip nat inside source static tcp 192.168.0.2 25 x.x.252.186 25 extendable

ip nat inside source static tcp 192.168.0.2 80 x.x.252.186 80 extendable

ip nat inside source static tcp 192.168.0.2 110 x.x.252.186 110 extendable

ip nat inside source static tcp 192.168.0.2 143 x.x.252.186 143 extendable

ip nat inside source static tcp 192.168.0.2 443 x.x.252.186 443 extendable

!

ip classless

ip route 0.0.0.0 0.0.0.0 Dialer1

no ip http server

ip pim bidir-enable

!

!

access-list 1 permit 192.168.0.0 0.0.0.255

access-list 100 permit ip any any

access-list 101 permit tcp any host x.x.252.186 eq www

access-list 101 permit tcp any host x.x.252.186 eq 443

access-list 101 permit tcp any host x.x.252.186 eq 143

access-list 101 permit tcp any host x.x.252.186 eq pop3

access-list 101 permit tcp any host x.x.252.186 eq smtp

!

[sachin]

Is your Mail server Microsoft Exchange ? Are you doing clustering for Exchange server ? If , yes then this is not a problem but it works like that only.

Because while sending mails it will take actual physical IP of the mail server not the virtual IP and that IP is not statically mapped so it will go out with your NATted IP.

[#7]

We are using Exchange. We are not doing clustering. I thought the static mapping for the mail server on .186 would return on that IP also.

[sachin]

Ok,if you are not doing clustering then it should take .186 when going out in internet.

Just check once --

1) your mail server is not configure with multiple private IPs.

2) After changing the static enteries you have to clear ip translations by "clear ip nat translations *" on router.

and you can check what pubilc ip is ur Mail server is taking by browsing http://my-ip-address.com site from you mail server.

[jamey]

I think the problem may be your static translation is included in the range of the nat pool.

A quick test would verify this. change the NAT pool to:

ip nat pool natmain x.x.252.187 x.x.252.190 netmask 255.255.255.224

do a clear ip nat trans *

and try again...

-HTH