Mailing List CGatePro@mail.stalker.com Message #103712
From: James Roman <james.roman@ssaihq.com>
Subject: Re: Re: RDNS (Reverse lookup) failure
Date: Mon, 19 Nov 2012 06:46:35 -0800
To: <CGatePro>
This is a mis-configuration of either your CGP server or your firewall NAT configuration. Either you are not sending mail from the IP address 10.0.88.100 (NAT 194.209.14.253) or your firewall is only configured to perform the static NAT on your outside interface, but not on your internal interface.

Your firewall is probably configured to provide default NAT with the IP address of your firewall (Gateway IP). You probably have a static NAT entry for your mail server that translates traffic to and from your Mail server to the address 192.209.14.153. If your mail server is in your DMZ, then you would probably want a set-up like this I am speculating that your inside network uses 10.1.x.x)

Source (192.209.14.146) <= Outside Interface  <= Firewall <= Source (Default PAT 192.209.14.146) <= Inside Interface <= Source (10.1.x.x ) Inside host
Source (192.209.14.153) <= Outside Interface  <= Firewall <= Source (Static NAT 192.209.14.153) <= DMZ Interface <= Source (10.0.88.10 ) Mail Server

If the mail server sends mail out with an address that is not 10.0.88.10, you will get the default PAT address instead of the Static NAT address.
  1. In CommuniGate, under Setting -> Network -> LanIP, make sure your Server LAN IP Address is set to 10.0.88.10. Make sure your WAN IPv4 Address: is set to 192.209.14.153
  2. In Settings -> Mail -> SMTP, make sure your Source IP Address is set to 10.0.88.10.
  3. If you change any of these IP addresses on the underlying server, you may need to restart CommuniGate or reboot the server to see the new addresses in CGP.
  4. Use a traffic sniffer on your firewall to verify that when you send a message using the CGP web interface, that it is sent using the 10.0.88.10 address. Make sure that the source and destination interfaces match what is expected.

If your mail server routes out the Inside interface, you will get the default PAT address. If your firewall improperly routes DMZ traffic Inside first, back through your Inside interface to the Outside you will get the default PAT address instead.

  1. Use traceroute to a known external mail server. Your route should return your DMZ gateway IP address, followed by your upstream Internet provider's router. If it returns your Inside network gateway interface, then you have a routing problem. The default route configured in your firewall should be your new ISP's default gateway, not an internal router.
  2. Review the route configuration on your firewall.
  3. Make sure that your DMZ interface is performing NAT translation.
  4. Make sure your static NAT entry is configured properly. 
    1. On a Cisco ASA your NAT entry should look like:
      • object network mail.ems.ch
         host 10.0.88.10
      • object network mail.ems.ch
         nat (DMZInterface,outside) static 192.209.14.153 dns

These are for a basic set-up. If you changed routers when you migrated ISPs then there is room for all kinds of unexpected behavior. Make sure that routing is working right otherwise all kinds things can go wrong.


On 11/05/2012 01:05 PM, Urs Grützner wrote:
Thanks for your help

In fact 194.209.14.153 is inbound and outbound as well. 

Of course, as 194.209.14.146 is the Gateway of our LAN, every mail passes this IP as well. But its origin should be 194.209.14.153.


I do not understand the mechanism, when and how this Gateway IP  is attributed and sent with mail. And why not the mail servers IP???


The weird thing is: before we switched to our new provider this did not happen. Except that Router, IPs and DNS have changed, everything should work analogously.


At the moment I have a workaround, that I can send my SMTP in relay with the SMTP of our Provider Swisscom. This "whiteswashes" the fact, that our reverse is not correct.

But thats not a solution. I want that the 194.209.14.153 is sent with the mail. (The reverse lookup to 194.209.14.146 might help as well but I am not happy with that trick as soon as I did not understand the mechanism) ;-)



Thanks


Urs




From: Lyle Giese <lyle@lcrcomputer.net>
Subject: Re: RDNS (Reverse lookup) failure
Date: Mon, 05 Nov 2012 11:06:39 -0600
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
It looks to me like 194.209.14.153 is for inbound email, while outbound email is forwarded via 194.209.14.146.  

194.209.14.146 does not have a reverse lookup.  This ip address does not appear to be accepting inbound email so I can not verify the HELO/EHLO greeting it may be providing.  

I think you need to get a reverse installed for 194.209.14.146 with the greeting used by that machine.

Lyle Giese
LCR Computer Services, Inc.

On 11/5/2012 10:07 AM, Urs Grützner wrote:
We have changed our Internet provider, needed to change also the DNS authority and the IP's.

The new zone file on the Master DNS is ok, according to the rules.  

The name Server IPS on the Server are changed to the new provider.

Our server is behind a Firewall, with local IPs 10.0.88.100, 127.0.0.1,


The forward and reverse lookup for ems.chmail.ems.ch and the public IP 194.209.14.153 are OK (see lookups below)







Now we have the following problem:

When sending mails its not the IP of our server which is transmitted, but the IP of our Gateway. Of course the RDNS lookup will fail for servers, which perform this check. 


I do not know how this IP is forwarded with mail. How does the mail server get his own public IP? By checking the DNS?  I don't understand how the gateway IP is coming into the header


Any help is appreciated

Thanks

Urs


PS: Here is a mail I have sent from the concerned server ems.ch. One can see the gateway number as the origin, instead of the mail servers IP number



Von:  Urs Grützner <ugruetzner@ems.ch>

Betreff:  test WAN IP

Datum:  5. November 2012 12:47:33 MEZ

An:  Gruetzner Urs <ursg@mac.com>

Return-Path:  <ugruetzner@ems.ch>

Received:  from st11b01mm-smtpin208.mac.com ([17.172.48.39]) by ms02551.mac.com (Oracle Communications Messaging Server 7u4-26.01 (7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTP id <0MD0006J5JFCOZA1@ms02551.mac.com> for ursg@mac.com; Mon, 05 Nov 2012 11:47:36 +0000 (GMT)

Received:  from ems.ch ([194.209.14.146]) by st11b01mm-smtpin208.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MD00043QJFAL170@st11b01mm-smtpin208.mac.com> for ursg@mac.com (ORCPT ursg@mac.com); Mon, 05 Nov 2012 11:47:36 +0000 (GMT)

Received:  from [10.0.99.54] (account ugruetzner [10.0.99.54] verified) by ems.ch (CommuniGate Pro SMTP 5.1.16) with ESMTPSA id 4681822 for ursg@mac.com; Mon, 05 Nov 2012 12:47:33 +0100




„Lookup“ wurde gestartet …


; <<>> DiG 9.6-ESV-R4-P3 <<>> ems.ch any +multiline +nocomments +nocmd +noquestion +nostats +search
;; global options: +cmd
ems.ch. 3600 IN MX 10 mail.ems.ch.
ems.ch. 3600 IN A 194.209.14.153
2012103001 ; serial
10800      ; refresh (3 hours)
3600       ; retry (1 hour)
604800     ; expire (1 week)
21600      ; minimum (6 hours)
)
ems.ch. 687 IN NS ns2.ip-plus.net.
ems.ch. 687 IN NS ns1.ip-plus.net.
ems.ch. 687 IN NS ns2.ip-plus.net.
ems.ch. 687 IN NS ns1.ip-plus.net.
mail.ems.ch. 687 IN A 194.209.14.153
ns1.ip-plus.net. 19862 IN A 164.128.36.34
ns2.ip-plus.net. 1833 IN A 164.128.76.39



„Lookup“ wurde gestartet …


; <<>> DiG 9.6-ESV-R4-P3 <<>> mail.ems.ch any +multiline +nocomments +nocmd +noquestion +nostats +search
;; global options: +cmd
mail.ems.ch. 657 IN A 194.209.14.153
ems.ch. 657 IN NS ns1.ip-plus.net.
ems.ch. 657 IN NS ns2.ip-plus.net.
ns1.ip-plus.net. 19832 IN A 164.128.36.34
ns2.ip-plus.net. 1803 IN A 164.128.76.39


„Lookup“ wurde gestartet …


; <<>> DiG 9.6-ESV-R4-P3 <<>> -x 194.209.14.153 any +multiline +nocomments +nocmd +noquestion +nostats +search
;; global options: +cmd
153.14.209.194.in-addr.arpa. 86400 IN PTR mail.ems.ch.





--

James Roman | Network Manager

Terranet Inc., on contract to:
SSAI | 10210 Greenbelt Rd., Suite 600 | Lanham MD 20706


IT Helpdesk: 301-867-2100
IT Support Website

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster