Postfix: relay denied from a different subnet

_MD_ · 05-11-2007, 12:50 PM

Yes, you're right, it looks like the problem is with my DNS server.
After playing with it a bit, here's what I ended up having in my DNS -> Forward Lookup Zone - mydomain.com (among other things like ftp, www, etc):

Code:

Name            Type      Data
mailserver      A         192.168.1.99
mailserver      MX        [5] mailserver.mydomain.com

I just added this today so when I still do dig mailserver.mydomain.com MX I get webmail.mydomain.com -> that's what was there before. If I'm not mistaken it take like 48 hours for the top level DNS servers to update their info, right? So it should say mailserver.mydomain.com tomorrow... But only if the actual local DNS configuration is correct, is it?

farslayer · 05-11-2007, 11:26 PM

Code:

Name            Type      Data
mailserver.mydomain.com      A         192.168.1.99
mydomain.com                 MX        [5] mailserver.mydomain.com

MX is for a domain not a hostname..

BUT

Quote:

If I'm not mistaken it take like 48 hours for the top level DNS servers to update their info, right? So it should say mailserver.mydomain.com tomorrow..

You internal DNS should have ZERO affect on External Internet DNS settings. I hope you didn't put that private non-routable IP address in your Public DNS settings.. no-one would be able to reach your mail server from the outside.

let me try and explain...

I have my domain registered with NetworkSolutions (I know, sorry about my luck)
so I configure the DNS settings hosted by network solutions like so..

Code:

Name            Type      Data
mail.mydomain.com   A        68.168.78.104
mydomain.com        MX  [10] mail.mydomain.com

Then on my Internal DNS server that the clients on my network use to resolve DNS I have it configured like this..

Code:

Name            Type      Data
mail.mydomain.com   A        172.16.1.10
mydomain.com        MX  [10] mail.mydomain.com

Clients on my internal network that want to send mail are directed to the mailserver at 172.16.1.10 which is an IP address in the DMZ of my firewall, the Clients all have 192.168.1.x addresses.

I have a Static NAT translation defined in the firewall that says traffic destined for the public Internet IP address 68.168.78.104 will be directed through the firewall to the 172.16.1.10 address. that allows my mail server to receive mail from the Internet as well as send it.

hmmmm.. they say a picture is worth 1000 words so here, maybe this will explain it better..
http://www.argconline.org/files/DNS_Example.pdf

_MD_ · 06-05-2007, 02:54 PM

Hey guys, it's me again.
Well our company got a new email server, so for the past month I've been configuring it. It is now running Fedora Core 6 - 64bit. At an early stage when only postfix (raw) and dovecot was up, I tested the relaying from that other subnet, and it was working! I was happy that by getting a new server, we solved the problem. But then I installed all kinds of other stuff like mailscanner, clamav, squirrelmail, enhanced postfix security (smtpd_recipient_restrictions), etc. So now I'm at a point when absolutely everything works and I've made the server migration and now we are on the new server. But I didn't take into account the other subnet (as it is not a primary goal but vial for future operations, nonetheless) and as you may have guessed, it doesn't relay messages from there again.

Now to sum up what we've concluded in our last discussion:

postconf -n

Code:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
debug_peer_level = 2
hash_queue_names = incoming,active,deferred,bounce,defer,flush,hold
html_directory = no
inet_interfaces = $myhostname, localhost
mailbox_command = /usr/bin/procmail -t
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
masquerade_domains = mydomain.com
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, mydomain2.com
myhostname = mailserver.mydomain.com
mynetworks = 192.168.1.0/24, 192.168.2.0/24, 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
readme_directory = /usr/share/doc/postfix-2.3.3/README_FILES
relay_domains = $mydestination
sample_directory = /usr/share/doc/postfix-2.3.3/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_banner = Welcome to MyDomain.
smtpd_recipient_restrictions = permit_mynetworks,   reject_non_fqdn_recipient,   reject_non_fqdn_sender,   reject_unknown_sender_domain, reject_unknown_recipient_domain,   reject_unauth_destination,   reject_non_fqdn_hostname,   reject_invalid_hostname,   reject_rhsbl_sender dsn.rfc-ignorant.org,   permit
unknown_local_recipient_reject_code = 550

dig goproduce.com MX

Code:

; <<>> DiG 9.3.2 <<>> mydomain.com MX
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50724
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;mydomain.com.                 IN      MX

;; ANSWER SECTION:
mydomain.com.          3594    IN      MX      10 webmail.mydomain.com.

;; ADDITIONAL SECTION:
webmail.mydomain.com.  3594    IN      A       64.23.10.81

;; Query time: 1 msec
;; SERVER: 192.168.1.30#53(192.168.1.30)
;; WHEN: Tue Jun  5 15:28:34 2007
;; MSG SIZE  rcvd: 71

64.23.10.81 our external address
192.168.1.30 winsvr1 - windows DNS

Now, I know that the DNS records on our provider still show webmail.mydomain.com but my true email server name is mailserver with the ip 192.168.1.99 and if we all agree that that is definitely the problem, then I would go through the hassle of contacting our provider and changing this info (many positions have been changed since this domain was registered including me, so I have no clue what the credentials are to modify this info). But everything works the way it is now for our primary location - users can send/receive external and internal mail 100%. So I sense that it has something to with the postfix itself, not so much with DNS. As you can see from postconf, I've explicitly set permit_mynetworks first so that none of the filtering would be applied to the 192.168.2.0 network, but it still doesn't go through. I even tried commenting out the smtpd_recipient_restrictions but still to no avail.

So any suggestions? I know this community is very good at helping people (and in details for the most part) for which I am very very grateful. =)

farslayer · 06-05-2007, 03:31 PM

webmail.goproduce.com but my true email server name is emailsrv
Well this shouldn't affect your ability to relay from the other subnet, but it surely can land your mailserver on a blacklist.. ( I can attest to this one first hand my hostname was mail1 and I had mail in the public DNS. )

Make sure the Server HOSTNAME matches what you put in the public DNS
http://www.cpqlinux.com/hostname.html

is the server itself aware of the other subnet ? fire off the route -n command and post the output..
I'm assuming your server is sitting inside your actual network and is not connected to a physical Firewall DMZ.

_MD_ · 06-06-2007, 01:35 PM

Quote:

Well this shouldn't affect your ability to relay from the other subnet but it surely can land your mailserver on a blacklist...

How?

Also, to add to this webmail issue, on my external DNS, webmail is pointing to my 192.168.1.99 address thus I can send emails using @webmail.mydomain.com

Quote:

Make sure the Server HOSTNAME matches what you put in the public DNS
http://www.cpqlinux.com/hostname.html

I have my hostname setup correctly on the new server:

Code:

127.0.0.1       localhost.localdomain   localhost
192.168.1.99    mailserver.mydomain.com  mailserver

So I don't even know whether I should do any changes on my external DNS... because everything works, right?

Quote:

is the server itself aware of the other subnet ? fire off the route -n command and post the output..

The server is behind a firewall/router which is connected to a remote site via VPN. Pings go through from one subnet to another without a glitch, but route -n doesn't have any routes to 192.168.2.0 network...

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 eth0

I was playing around with Postfix smtpd_recipient_restrictions and out of 9 that I had before (from an online guide) I left only three:
permit_mynetworks, reject_unauth_destination, reject_non_fqdn_recipient

That kind of solved some of the internal returned mail... but the relaying from the second subnet is still a hot issue.

farslayer · 06-06-2007, 10:13 PM

HOW ? you ask..

Well it surprised me as well.. it seems that when your mail server talks to another mail server in the initial HELO exchange your mail server passes it's fqdn hostname to the other mail server. What your server passes the other mail server SHOULD match what the other mail server sees when it does a reverse lookup on the IP address of your mail server. if it's different some mail servers will automatically report you to one of the black lists because your server is mis-configured, appears to NOT be hwho it says it is... then next thing you know your server is on a half dozen black lists because some of them corss populate from others..

so your Mail server can PING hosts on the other subnet and traceroute to them fine ?

hrm

do you have some log snippets of clients from 192.168.2.0 subnet trying to send mail to the outside ?
maybe the failure in the logs will provide another clue.

_MD_ · 06-07-2007, 02:24 PM

Quote:

so your Mail server can PING hosts on the other subnet and traceroute to them fine ?

Yes

Quote:

do you have some log snippets of clients from 192.168.2.0 subnet trying to send mail to the outside ?

/var/log/maillog

Code:

Jun  7 14:44:08 mailserver postfix/smtpd[11562]: NOQUEUE: reject: RCPT from unknown[64.23.10.81]: 554 5.7.1 <outside@gmail.com>: Relay access denied; from=<chris@mydomain.com> to=<outside@gmail.com> proto=ESMTP helo=<ws050>
Jun  7 14:44:32 mailserver postfix/qmgr[7848]: CA75B516273: from=<chris@mydomain.com>, size=6969, nrcpt=1 (queue active)
Jun  7 14:45:14 mailserver dovecot: IMAP(chris): Disconnected: Logged out

I just noticed that my Windows file sharing doesn't work over VPN too... maybe it has something to do with my VPN/firewall config?!

farslayer · 06-07-2007, 06:32 PM

Code:

Jun  7 14:44:08 emailsrv postfix/smtpd[11562]: NOQUEUE: reject: RCPT from unknown[68.179.24.90]: 554 5.7.1 <outside@gmail.com>: Relay access denied; from=<chris@goproduce.com> to=<outside@gmail.com> proto=ESMTP helo=<dwightws050>

why does it look like your client connected to your mailserver via the Internet instead of through the VPN tunnel ?

The part highlighted in RED is the queue ID number which is assigned to each mail transaction as it enters the system.. the log snippet you posted has maybe only one line for that transaction, were there no other lines with that same queue number ? they are often NOT in order.. you may have to skip several lines to follow an entire transaction.

Code:

Jun  8 10:42:11 localhost postfix/smtpd[10087]: 14CA34F92B: client=unknown[192.168.0.220]
Jun  8 10:42:11 localhost postfix/cleanup[10093]: 14CA34F92B: message-id=<NIEBIKCIIILIINMJALAFCEMLEFAA.wnovak@services.com>
Jun  8 10:42:11 localhost postfix/qmgr[9063]: 14CA34F92B: from=<wnovak@services.com>, size=735, nrcpt=2 (queue active)
Jun  8 10:42:11 localhost postfix/local[10098]: 14CA34F92B: to=<jyackin@services.com>, relay=local, delay=0, status=sent (delivered to command: /usr/bin/maildrop)
Jun  8 10:42:11 localhost postfix/local[10099]: 14CA34F92B: to=<scvelbar@services.com>, orig_to=<sue@services.com>, relay=local, delay=0, status=sent (delivered to command: /usr/bin/maildrop)
Jun  8 10:42:11 localhost postfix/qmgr[9063]: 14CA34F92B: removed
J

look at a good transaction from your local subnet, then view a bad transaction from the other subnet.. what do you notice right off that is different ?

_MD_ · 06-11-2007, 10:45 AM

Quote:

why does it look like your client connected to your mailserver via the Internet instead of through the VPN tunnel ?

To me, that's a mystery as well... I mean, that address is the external address for my router A where I'm running VPN through IPSec with PSK to router B... hmmm.... maybe the router doesn't allow relay? I actually went into configuration and added email services to the allowed networks for SMTP proxy. Still doesn't work. But that's not the reason for sure because as I've mentioned before, when I was just configuring emailsrv with raw postfix installation, I was successfully able to relay mail from the other subnet.

Quote:

the log snippet you posted has maybe only one line for that transaction, were there no other lines with that same queue number ? they are often NOT in order.. you may have to skip several lines to follow an entire transaction.

Well, here's the full log for that user chris. But again, it still shows that the connection was made from the remote IP rather than from subnet.

Code:

Jun 11 10:33:30 mailserver dovecot: imap-login: Login: user=<chris>, method=PLAIN, rip=64.23.10.81, lip=192.168.1.15
Jun 11 10:34:02 mailserver postfix/smtpd[15894]: connect from unknown[64.23.10.81]
Jun 11 10:34:02 mailserver postfix/smtpd[15894]: NOQUEUE: reject: RCPT from unknown[64.23.10.81]: 554 5.7.1 <outside@gmail.com>: Relay access denied; from=<chris@mydomain.com> to=<outside@gmail.com> proto=ESMTP helo=<ws050>
Jun 11 10:34:05 mailserver postfix/smtpd[15894]: disconnect from unknown[64.23.10.81]
Jun 11 10:34:45 mailserver postfix/smtpd[15894]: connect from unknown[64.23.10.81]
Jun 11 10:34:46 mailserver postfix/smtpd[15894]: 4FFBE516269: client=unknown[64.23.10.81]
Jun 11 10:34:46 mailserver postfix/cleanup[15910]: 4FFBE516269: message-id=<20070611143446.4FFBE516269@mailserver.mydomain.com>
Jun 11 10:34:46 mailserver postfix/qmgr[7848]: 4FFBE516269: from=<>, size=2088, nrcpt=1 (queue active)
Jun 11 10:34:46 mailserver postfix/local[15915]: 4FFBE516269: to=<dan@mydomain.com>, relay=local, delay=0.67, delays=0.66/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -t)
Jun 11 10:34:46 mailserver postfix/qmgr[7848]: 4FFBE516269: removed
Jun 11 10:34:46 mailserver postfix/smtpd[15894]: disconnect from unknown[64.23.10.81]
Jun 11 10:35:49 mailserver dovecot: imap-login: Login: user=<chris>, method=PLAIN, rip=192.168.1.15, lip=192.168.1.15, secured
Jun 11 10:35:49 mailserver dovecot: IMAP(chris): Disconnected: Logged out

Quote:

look at a good transaction from your local subnet, then view a bad transaction from the other subnet.. what do you notice right off that is different ?

Different... hmm... maybe that the relay is local?!

Code:

Jun 11 10:30:08 mailserver postfix/local[15828]: 3A93E516269: to=<dan@mydomain.com>, relay=local, delay=0.02, delays=0.01/0/0/0.01, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -t)

How can I test different settings of postfix filtering (or security or what not) to test if it will allow relaying? Note that this server is now live and I don't want any interruptions in service. Because, let me repeat myself, it was working with the default config. Maybe it's all that spam features I've installed? or AV? Also I've disabled SElinux but that surely just made it more permissive...

hmmm =[

farslayer · 06-11-2007, 03:56 PM

Quote:

postfix/smtpd[15894]: 4FFBE516269: client=unknown[68.179.24.90]

That still bothers me.. I don't understand why it would be identifying users from another subnet as connecting to the external IP..
I'm SURE your mail server isn't setup to relay mail from outside (nor should it be unless you setup other security measures) but those clients should show up with their 192.168.2.x address when talking to your mail server otherwise it will deny the mail relay (as it should).

it appears there is another problem in your network somewhere..

If you do a DNS lookup from the other segment for your mail server does the private IP come back or the public one ? it looks to me like they are looking for your mail server getting a response for he public IP and going over hte internet to connect to that public IP rather than through your VPN tunnel to connect to the Private IP of that same server..

but i can only speculate, you'll need to do the troubleshooting.

_MD_ · 06-14-2007, 09:58 AM

Alright, i got it FIXED!!! Thanks a lot farslayer for all the help. You pointed me in the right direction. After analyzing that postfix sees my other subnet as an external address, I ran across this resource and configured Smtp Auth for my server. Now users on the .2.0 network use sasl and can send external messages w/o problems... Now I just have to figure out why my windows sharing doesn't work over VPN and I'm off to use the other subnet to it's full potential :]

Thanks again.

farslayer · 06-15-2007, 11:00 PM

Glad I could help

Windows sharing..

Can you connect to the share using the IP address of the server ?

Using START -> RUN
\\servername\share - doesn't work
\\192.168.1.10\share - works !!

That would most likely point again to a DNS issue.. the remote subnet is not getting the proper DNS results in order to locate the resources it needs on the network.

from the windows cmd line
nslookup servername.mydomain.com

that should check to see if the clients can resolve the proper IP address for the server it is trying to connect to. do this for the same names from a PC on both subnets.. you should get the SAME result from both.

This could also be a good time to learn how to use wireshark for troubleshooting. you could install it on a laptop or PC, attempt the connection and view the packets to see what is occurring during the transaction.

_MD_ · 06-18-2007, 07:26 AM

Code:

The Ethereal network protocol analyzer has changed its name to Wireshark.

I see... I'm still using ethereal... Thanks for the update.

As for the window sharing, it turned out to be a very simple issue. I had a local software firewall on two of the servers that I was testing windows sharing on and it was blocking it... Oh man, you can't imagine how many hair was torn off my head when i was playing with all the different ports on the main routers... :@

Lol... but now it's all good and everybody's happy. Thanks again mate. Appreciate it. :]

farslayer · 06-18-2007, 09:57 AM

Ah those darned firewalls

Glad you got it all worked out.