Cannot telnet localhost 110 to Fedora 8 Server from PCs on LAN

Discussion in 'HOWTO-Related Questions' started by seahawkja, Mar 5, 2008.

  1. seahawkja

    seahawkja New Member

    I used Falco's article : Fedora 8 Server Setup: LAMP, Email, DNS, FTP, ISPConfig (a.k.a. The Perfect Server) to setup a server for a client. Everything went well and works fine.

    The server is online and behind a firewall/router with the neccessary ports open.

    We can retrieve webmail and MUA mail from the internet, but trying to MUA (Eudora 7.1) from a windows xp pc on the internal LAN times out.

    On the xp pc I tried telnet to localhost 110 and telnet 192.168.0.128 110 but it never connects. I can telnet on the server itself and it responds correctly.

    I figure it has something to do with dovecot.conf but not sure as I have not used dovecot before.

    Any ideas/suggestions appreciated.

    seahawkja
     
  2. topdog

    topdog Active Member

    You cannot telnet localhost 110 on the windows xp machine because localhost refers to the machine on which you are working. Are you able to ping the server from your xp client ? Please provide the output of

    Code:
    netstat -ntlp
     
  3. seahawkja

    seahawkja New Member

    RE: Cannot telnet to email server on LAN

    Thanks for the response.

    I can ping the server no problem.

    From the xp m/c telnet 192.168.0.128 110 times out waiting on connection.
    I can telnet localhost 110 & telnet 192.168.0.128 110 on the server ok.

    The setup of the mail is dovecot - postfix - amavisd - spamassassin & clamav - squirrelmail.

    All of the above are working - just can't MUA inside LAN.

    Results of netstat:

    Active Internet connections (only servers)
    Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
    tcp 0 0 0.0.0.0:993 0.0.0.0:* LISTEN 2217/dovecot
    tcp 0 0 0.0.0.0:995 0.0.0.0:* LISTEN 2217/dovecot
    tcp 0 0 127.0.0.1:10024 0.0.0.0:* LISTEN 2242/amavisd (maste
    tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN 2298/master
    tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 2189/mysqld
    tcp 0 0 0.0.0.0:110 0.0.0.0:* LISTEN 2217/dovecot
    tcp 0 0 0.0.0.0:143 0.0.0.0:* LISTEN 2217/dovecot
    tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1873/rpcbind
    tcp 0 0 192.168.0.128:80 0.0.0.0:* LISTEN 2309/httpd
    tcp 0 0 0.0.0.0:57937 0.0.0.0:* LISTEN 1892/rpc.statd
    tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 2103/vsftpd
    tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 2432/cupsd
    tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2298/master
    tcp 0 0 :::22 :::* LISTEN 2077/sshd
    tcp 0 0 :::443 :::* LISTEN 2309/httpd
     
  4. topdog

    topdog Active Member

    Do you have antivirus running on the windows xp machine ? Some AV's are know to block port access redirecting everything to a proxy for scanning.

    It's also possible that your desktop firewall could be blocking the outbound connection.

    Also double check you iptables firewall on the server it self it could be accepting connections only from your router.
     
  5. seahawkja

    seahawkja New Member

    RE: Cannot telnet

    Thanks for your response.

    Not on-site at present so I cannot check A/V or local firewall on xp m/c.

    To the best of my knowlege the xp firewall is off but would need to check on the A/V (TrendMicro2007). Note: This xp m/c was using the same Eudora 7.1 to pickup mail previously from an off-site email server without any problems.

    Output below for iptables -L

    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    RH-Firewall-1-INPUT all -- anywhere anywhere

    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

    Chain RH-Firewall-1-INPUT (1 references)
    target prot opt source destination
    ACCEPT all -- anywhere anywhere
    ACCEPT icmp -- anywhere anywhere icmp any
    ACCEPT esp -- anywhere anywhere
    ACCEPT ah -- anywhere anywhere
    ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
    ACCEPT udp -- anywhere anywhere udp dpt:ipp
    ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
    ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
    ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp
    ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:smtp
    ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
    ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-ns
    ACCEPT udp -- anywhere anywhere state NEW udp dpt:netbios-dgm
    ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:netbios-ssn
    ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:microsoft-ds
    ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https
    ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
    REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
     
  6. topdog

    topdog Active Member

    Your iptables is not configured to allow port 110. Thats the problem
     
  7. seahawkja

    seahawkja New Member

    RE: Cannot telnet...

    Thanks for the response.

    I noticed that when I ran the iptables so I edited them.

    /etc/sysconfig/iptables

    then restarted:

    /etc/rc.d/init.d/iptables restart

    I had previously sent an email to the account from which the xp m/c should pickup mail - hoping that after fixing the iptables we would have success.

    However, after tailing /var/log/maillog I saw the following entry:

    Mar 6 00:40:03 ws1 dovecot: pop3-login: Disconnected: rip=192.168.0.33, lip=192.168.0.128, TLS handshake

    192.168.0.33 is the xp m/c and 192.168.0.128 is the server. It seems as though it is getting disconnected upon login.

    Below is the updated iptables results:

    [root@ws1 /]# iptables -nL -t filter
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0

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

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    Chain RH-Firewall-1-INPUT (1 references)
    target prot opt source destination
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
    ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353
    ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:21
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:110
    ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:137
    ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:138
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:139
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:445
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
    REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

    So there is still a problem here.
    I went on-site and checked:
    Windows firewall is OFF, TrendMicro firewall is OFF and no ports being blocked.

    I am researching the "Disconnected...TLS handshake"
    Any insight would be appreciated.

    SeaHawkJa
     
    Last edited: Mar 6, 2008
  8. topdog

    topdog Active Member

    I think your mail client is trying to talk to the server using TLS, and the session is failing possibly because the certificate is self signed. Try making a normal connection with out encryption.
     
  9. seahawkja

    seahawkja New Member

    RE: Cannot telnet...

    Thanks topdog.

    I tried retrieving with Eudora from outside the LAN and got the same "TLS handshake" message in the maillog (different rip=).

    I think I have found the source of the problem:

    1. The original self-signed cert was genned when I first setup the server.
    2. This was copied to /etc/pki/dovecot/certs/dovecot.pem
    3. Subsequently a CSR was genned for a CA SSL cert and that cert was installed later.
    4. The original self-signed cert is still sitting as dovecot.pem and was never updated.

    When accessing the email account from the internet with Eudora, it gave the following:

    SSL Negotiation Failed: Certificate Error: Unknown and unprovided root certificate.
    Certificate bad: Destination Host name does not match host name in certificate
    But ignoring this error because Certificate is trusted
    The connection with the server has been lost.
    Cause: (207)

    It also popped a window with the following:

    Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    bd:5d:8c:b6:25:2b:69:83
    Signature Algorithm: sha1WithRSAEncryption
    Issuer: OU=IMAP server, CN=imap.example.com/[email protected]
    Validity
    Not Before: Jan 16 21:55:55 2008 GMT
    Not After : Jan 15 21:55:55 2009 GMT
    Subject: OU=IMAP server, CN=imap.example.com/[email protected]
    Subject Public Key Info:
    Public Key Algorithm: rsaEncryption
    RSA Public Key: (1024 bit)
    Modulus (1024 bit):
    etc, etc, etc.

    From the date I could tell taht this was prior to the CA SSL cert being installed.

    Now I have to update the dovecot configs to recognize the new cert.

    Have to do a little more reading, but I will let you know of the outcome.

    SeaHawkJa
     
  10. topdog

    topdog Active Member

    The certificate needs to match the hostname.
     
  11. seahawkja

    seahawkja New Member

    RE: Cannot telnet...

    All systems go!

    In the event that you purchase and install a SSL certificate after the initial server build where you had a self-signed one:

    1. Using openssl you must create a certificate and key in the PEM format for dovecot.

    2. cp cert servername.pem file to /etc/pki/dovecot/servername.pem

    3. cp key servername.pem file to /etc/pki/dovecot/private/servername.pem

    4. Restart dovecot /etc/init.d/dovecot restart

    5. Test from external m/c using telnet yourhost.com 110

    6. Test from your MUA on external m/c

    If your username / passoword are correct you should be in.

    Thanks topdog for your help
     

Share This Page