Postfix configuration - Red Hat Linux 6.4

[Raja_b02]

Hi All,

I have configured postfix on a Red Hat Linux 6.4. I am trying to send an email from one server in the same domain to other server.

For eg:

From root@servername.example.com to root@servername2.example.com

$ mail -s "test" root@servername2.example.com < /tmp/file

I am getting "No route to host" error while trying this.

Nov 20 18:38:43 servername postfix/qmgr[7797]: 9CC97336: from=<root@servername.example.com>, size=1863, nrcpt=1 (queue active)
Nov 20 18:38:43 servername postfix/smtp[8449]: connect to servername.example.com:25: No route to host
Nov 20 18:38:43 servername postfix/smtp[8449]: 9CC97336: to=<root@servername.example.com>, relay=none, delay=2409, delays=2409/0.01/0/0, dsn=4.4.1, status=deferred (connect to servername2.example.com[10.XXX.XX.XX]:25 No route to host)

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
default_privs = nobody
html_directory = no
inet_interfaces = $myhostname, localhost
inet_protocols = all
mail_owner = postfix
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
mydestination = $myhostname, localhost.$mydomain, localhost
mydomain = example.com

myhostname = servername.example.com
mynetworks = 10.XXX.XX.0/28, 127.0.0.0/8
myorigin = $mydomain
newaliases_path = /usr/bin/newaliases.postfix
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
unknown_local_recipient_reject_code = 550

Please let me know what could be the issue. I am not trying to send any email to an external domain. I just want to send email between same domain and between TWO servers which are on the same subnet.

telnet is disabled and hence I cannot try telnet <remote host> 25.

Regards,

Raja 

[Matti_Kurkela]

When the error message is "No route to host", the problem is usually at the IP routing level.

A TCP traceroute might be helpful: run "traceroute -T -p 25 servername2.example.com".

If your "mynetworks" setting of 10.XXX.XX.0/28 is correct for your local network segment, then there are three possible situations:

• If the IP address of servername2.example.com is between 10.XXX.XX.[1 .. 14], then servername2 should be directly reachable by your server, and "No route to host" error would mean a serious error with your routing table or some mistake with iptables rules. The outputs of "route -n", "iptables -L -nv" and "iptables -L -nv -t nat" should be checked. If you find any settings that don't make sense for your network, they should be changed.
• If the last part of the IP address of servername2.example.com is higher than .15, or the 10.XXX.XX part is different, then the connection must go through your gateway/router, and the "No route to host" error means that the router is telling you it does not know how to pass IP packets from your server to servername2.example.com. You would need to check the configuration of the router in that case.
• the comedy option: if the last part of the IP address of servername2.example.com is exactly .15, you're trying to use the broadcast IP address of your local network segment as a regular host address, which is not a good idea.

"Disabling telnet" usually means disabling telnet servers and/or blocking the TCP port 23, to make any normal telnet connection attempts fail. Disabling a telnet client is usually futile, since a minimal telnet client can probably be implemented with a small Perl script: an evil person can memorize the script and just type (or copy&paste) it to any system where the standard telnet client has been disabled.

When the telnet client is used with a different port number, it is usually used to test other TCP-based network services: in this case, it does not need the telnet server at all. The basic telnet protocol is so simple that it can be used to test the basic connectivity and even functionality of many TCP-based protocols like SMTP.

If you have the netcat command (nc) available, you can use it for basic connectivity testing much like the telnet command: netcat is actually much more flexible for that purpose than the telnet client, as it has much more options useful for testing purposes. But if the telnet client has been disabled because of a security policy, then I would expect that netcat is forbidden too... assuming that the security policy is consistent, which may be too much to ask sometimes :-/

[Raja_b02]

Thank you MK, the issue is resolved now. I had to  ADD few IPTABLE entries for SMTP to make this work. This is what I have implemented on Red Hat 6.4

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:smtp state NEW,ESTABLISHED
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp spt:smtp state NEW,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:smtp state NEW,ESTABLISHED

[Raja_b02]

Thanks Steven, this is resolved now. I had to add few iptable entries in order to accept smtp connections

[Matti_Kurkela]

Just a few comments regarding your iptables.

***

"iptables -L" gives incomplete information, so it's better to use "iptables -L -vn" instead.

For example, the third entry in your INPUT chain: in "iptables -L" listing, it looks like it would accept all traffic, causing the rest of the entries in that chain to be ignored.

But if your iptables ruleset is based on RHEL 6.x default iptables rules, the third entry is actually accepting traffic on loopback interface (lo) only. "iptables -L -vn" listing will indicate this, but "iptables -L" will not.

***

Because the first entry in the INPUT chain is accepting all traffic with state RELATED or ESTABLISHED, there is no need to specify ESTABLISHED state on further entries in the INPUT chain. It is not harmful, just superfluous.

The idea is to process the first packet of each new connection using the full ruleset, then use the "RELATED,ESTABLISHED" rule as a short cut to accept all the subsequent packets in the same connection. That will minimize the amount of processing required, making your iptables more efficient.

***

Since your OUTPUT chain has ACCEPT as its default policy and no REJECT or DROP entries anywhere in it, your OUTPUT rules for smtp traffic are effectively just traffic counters: the "spt:smtp" line will measure the data sent out as a response to incoming smtp connections, and the "dpt:smtp" line will measure the amount of data sent in outgoing connections to other SMTP servers. If you don't need to track the amount of smtp traffic this way, you could remove the last two entries.