1

Topic: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

==== Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.7
- Linux/BSD distribution name and version: Debian 8
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): LDAP
- Web server (Apache or Nginx): Apache
- Manage mail accounts with iRedAdmin-Pro? Yes
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====

Hello,

since i upgraded to 0.9.7 and Rondcube 1.3, randomly after hours or days of normal use, users can't login into Roundcube anymore and this error occurs in /var/log/syslog:

IMAP Error: Login failed for demo@example.com from xxx.xxx.xxx.xxx. Could not connect to 127.0.0.1:143: connection refused in /opt/www/roundcubemail-1.2.0/program/lib/Roundcube/rcube_imap.php on line 196 (POST /mail/?_task=login&_action=login)

Dovecote is alive, IMAP-connections with external clients like thunderbird etc. are working. telnet localhost 143 works fine, too.
Searching for s solution sometimes the localhost entry in /etc/hosts seems to be the problem, but this doesn't work for me. Rebooting the system helps, restarting apache or dovecot on it's own doesn't.
Anyone, any ideas ?

Regards

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

How many IMAP users do you have? Is it possible that it reaches the max IMAP connections?

3 (edited by jobu 2017-08-09 22:37:37)

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

308 connections on port 143, 108 on port 993 currently (rc works fine right now).
I already adjusted dovecot.conf to:

protocol imap {
    mail_max_userip_connections = 30
}

service imap-login {
    process_min_avail = 3
    process_limit = 1200
}

dovecot -F tells:

Warning: service auth { client_limit=1000 } is lower than required under max. load (3200)
Warning: service anvil { client_limit=1000 } is lower than required under max. load (2703)

cat /proc/sys/fs/inotify/max_user_instances ... shows 2048.
Normaly a specific error message shows up, when max connections are reached. this is not happening at that moment.

4

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

jobu wrote:

Warning: service auth { client_limit=1000 } is lower than required under max. load (3200)
Warning: service anvil { client_limit=1000 } is lower than required under max. load (2703)

Just do as it says: increase 'client_limit' for these 2 services. If you don't have them in dovecot.conf, add them manually. For example:

service auth {
    client_limit = 1300
}

service anvil {
    client_limit = 1300
}

Adjust the numbers until Dovecot stops the complain.

5

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

In the last days there was only once again this problem - i could resolve it by restarting fail2ban. I missed checking all the jails, will do this next time and set the logtarget for fail2ban to file with debug level then.

6

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

It happend again, but i didn't found anything on /var/log/fai2ban.log (info-level, since debug is to much output  for an unforeseeable event) or in the jails using fail2ban-client status. Does anyone have another idea what to search for in debug mode or by fail2ban-client e.g.?
Restarting fail2ban solved the problem again, so it should be the problem.
In the upgrade manual 0.9.6 to 0.9.7 there is a change for fail2ban - i downloaded the new confs for dovecot.iredmail and roundcube.iredmail as proposed. Looking into the files, It seems like there is a syntax-change, is it may working only for a newer version of fail2ban (i know there are changes for stretch)?

Regards

7

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

jobu wrote:

Does anyone have another idea what to search for in debug mode or by fail2ban-client e.g.?

Did you check /var/log/syslog?

8

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

It seems my changes to dovecot.conf (anvil / auth) hadn't been saved ... so i can't say if this would had helped, sorry for that. But now it is set.
/var/log/syslog shows this two messages for each login attempt:

roundcube: PHP Warning:  stream_socket_client(): unable to connect to 127.0.0.1:143 (connection refused) in /opt/www/roundcubemail-1.3.0/program/lib/Roundcube/rcube_imap_generic.php on line 959
roundcube: <vt0k3cmt> IMAP Error: Login failed for demo@example.com from xxx.xxx.xxx.xxx. Could not connect to 127.0.0.1:143: connection refused in /opt/www/roundcubemail-1.3.0/program/lib/Roundcube/rcube_imap.php on line 196 (GET /mail/?_task=mail&_action=compose&_id=56284306259918d106ef5e)

9

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

*) Again, check whether Dovecot is running. Port 143 is accessible (e.g. "telnet localhost 143")
*) Please show us IMAP server related settings in Roundcube config file.

$config['default_host'] =
$config['default_port'] =
$config['imap_auth_type'] =
$config['imap_conn_options'] =

10

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

Hmmm ...

#telnet localhost 143
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

Actually a lot of prozesses are running and

#dovecot -F
Fatal: Dovecot is already running with PID 13897 (read from /var/run/dovecot/master.pid)

/opt/www/roundcubemail/config/config.inc.php settings

$config['default_host'] = '127.0.0.1';
$config['imap_auth_type'] = 'LOGIN';
$config['imap_conn_options'] = array (
  'ssl' => 
  array (
    'verify_peer' => false,
    'verify_peer_name' => false,
  ),
);

$config['default_port'] = is not set.

11

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

jobu wrote:

#telnet localhost 143
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused

This means Dovecot is running running or listening on port 143. Please try to stop it first, (make sure no dovecot processes running), then start it again.

Pay close attention to Dovecot log files under /var/log/dovecot/.

12

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

Thank you for all the hints so far, Zhang!
I did increase dovecote's debug level and right now i'm waiting for the next incident ...

Regards

13 (edited by jobu 2017-08-24 19:44:07)

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

Dear Zhang and community,

it happend again ...
I stoped dovecot.socket and dovecot.service and all processes were gone, restarted it, but it didn't help. Only restarting fail2ban did it again. 
Donig a "telnet myserver.example.com 143" works by the way, "telnet localhost 143" doesn't.
I remembered a workaround for PHP > 5.6 for Roundcube (Debian incomptibility, online anymore) and changed the following in /opt/www/roundcubemail/config/config.inc.php:

 // SMTP
//$config['smtp_server'] = 'tls://127.0.0.1';
// changed to
$config['smtp_server'] = 'tls://myserver.example.com';
...
// Required if you're running PHP 5.6
//$config['smtp_conn_options'] = array (
//  'ssl' => 
//  array (
//    'verify_peer' => false,
//    'verify_peer_name' => false,
//  ),
//);
// changed to
$config['smtp_conn_options'] = array(
    'ssl'
    => array(
        'verify_peer'     => true,
        'verify_depth'    => 3, 
        'cafile'          => '/etc/ssl/certs/my-chain.pem'
    )
);

I cannot say if this helped, had to make it work before again
roll

Checking my 860MBs of dovecot.log in debug-mode (mail & auth) for further errors only shows:

imap-login: Info: Login: user=<demo@example.com>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=14298, secured, session=<VxRbFX5XzgB/AAAB>
imap(demo@example.com): Info: Disconnected: Logged out in=82 out=730

Regards

14

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

Setting the FQDN for $config['smtp_server'] didn't help either.
Right now my workaround is a cronjob restarting fail2ban each hour ... OMG

Regards

15

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

Does your Fail2ban block 127.0.0.1? Please check.

16

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

I didn't find anything like localhost in the jails when it happens and the config has active ignoreip settings
jail.conf:

ignoreip=127.0.0.1

jail.local

ignoreip  = 127.0.0.1 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16

Regards and thanks for not giving up!

17

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

jobu wrote:

I stoped dovecot.socket and dovecot.service and all processes were gone, restarted it, but it didn't help. Only restarting fail2ban did it again. 

Fail2ban blocks bad clients, if only restarting fail2ban works, that means some IP was blocked by Fail2ban.
You need to check iptables firewall when this issue occurs:

iptables -L -n

18 (edited by jobu 2018-06-13 18:46:18)

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

It worked for me a long while (restarted fail2ban hourly) until now. In the meanwhile i upgraded my system to Debian 9.4, but iRM is still at 0.9.7. This morning i installed updates for perl (https://www.debian.org/security/2018/dsa-4226) and since then no webmail-login is possible.
The error messages are the same and this time i can come up with a block-message from fail2ban:

Chain f2b-postfix (1 references)
REJECT     all  --  127.0.0.1            0.0.0.0/0            reject-with icmp-port-unreachable

Restarting fail2ban doesn't work anymore, i have to shut it down to make logins work again. Could you please provide me an original version of the fail2ban-configs for Debian9, iRM v0.9.7, so i could compare it with mine or do you see another solution?

Regards

Jobu

19

Re: Users can't login into Roundcube - Could not connect to 127.0.0.1:143

I added 127.0.0.1 to /etc/fail2ban/jail.local even if there already was a DEFAULT entry with ignoreip for localhost:

[postfix-iredmail]
enabled     = true
filter      = postfix.iredmail
action      = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp]
logpath     = /var/log/mail.log
ignoreip    = 127.0.0.1 127.0.0.0/8 

It works again.