Cloudflare 524 Error with Roudcube

[peaceharborco]

There is an issue between the Cloudflare DNS proxy of the webmail record (either A or CNAME) and accessing the Roundcube Inbox directly. When trying to reach a client's mailbox via https://webmail.domain.com, the page will load with SSL as it should. Whenever you try to log in, the page will try to load until it eventually gives a Cloudflare 524 timeout.

If you just set up a new mailbox account and log in for the first time, you can access the mail account configuration page, but once you try to enter the Roundcube mailbox, you will encounter the same issue as above.

On the other hand, if accessing the same mail account through WHM, which is not proxied via Cloudflare, Roundcube loads without issue. I have spent several days working with the tech team at my data center (LiquidWeb), and they are also seeing the same problem. They have ruled out conflicts except those between Cloudflare and Roundcube playing nicely.

This issue has also reached the Cloudflare forums, but a resolution has yet to be brought to light. https://community.cloudflare.com/t/roundcube-524-a-timeout-occurred/485616/6 https://community.cloudflare.com/t/webmail-time-out/369911/4 https://community.cloudflare.com/t/mail-timeout-after-activated-cloudflare/325753 https://community.cloudflare.com/t/cpanel-webmail-after-login-does-not-load-and-gives-error-524/523763 https://community.cloudflare.com/t/cpanel-webmail-fatal-error-or-timeout-occurred-while-processing-this-directive/631322

Hopefully, you can fix this issue, as the only option is to disable the proxy on the A or CNAME record. Here's a short video showing this in further detail that I sent to my data center as well. https://share.peaceharbor.com/NQuAdEod

[TTMTT]

Yes, I also have this exact problem. I tried changing the SSL and also the DNS. I updated the server and the hostname for a whole day, trying to solve this problem, and it turned out that this problem is not only with me

[troglodyne]

If anything I doubt the roundcube project will be able to do much about this. cPanel is tracking the case for now as CPANEL-44118. We have a support article on it and will update it as soon as we've got a resolution or better workaround for it.

[TTMTT]

@peaceharborco @troglodyne Hey guys, I don't think the problem from Roundcube. I believe the issue is in Cloudflare. I created a subdomain on another website that exist on cloudflare and linked it to the same server IP where the problem exists, and the webmail worked fine without any issues. I'm not exactly sure where the problem is, but I suspect that it might be related to the SSL certificates on Cloudflare.

Today, I will try to change the SSL certificate on my website from Google Trust to Universal or Let's Encrypt, or any available option in Cloudflare, to see if the issue is related to SSL. If all the solutions don't work for me, I will downgrade cPanel to the previous version.

[TTMTT]

Alright, I've solved the problem, and indeed it was caused by Roundcube. I performed a downgrade of Roundcube from version 1.6.6 to 1.6.0, and the issue was resolved.

Here's how I did it: I navigated to the following path:

/usr/local/cpanel/base/3rdparty

and renamed the Roundcube folder to roundcube_bak. Then, I pulled files from another website for Roundcube version 1.6.0 and uploaded them to the same path on my server.

[peaceharborco]

Alright, I've solved the problem, and indeed it was caused by Roundcube. I performed a downgrade of Roundcube from version 1.6.6 to 1.6.0, and the issue was resolved.

Here's how I did it: I navigated to the following path:

/usr/local/cpanel/base/3rdparty

and renamed the Roundcube folder to roundcube_bak. Then, I pulled files from another website for Roundcube version 1.6.0 and uploaded them to the same path on my server.

Thanks for digging into this. I know several folks have debated whether it's a Cloudflare, cPanel, or Roundcube problem. From what you've done here, it appears to be localized to Roundcube.

[troglodyne]

I'm somewhat unconvinced this is entirely a roundcube issue. cPanel bundles several plugins with RoundCube (Kolab, etc.), and replacing the directory with upstream roundcube 1.6 will get rid of the plugins we ship with it. One of the plugins may in fact be to blame for the issue of a timing out PHP process.

If anyone knows in particular what PHP process winds up timing out here to cause the 514 to trigger on cloudflare, that'd probably point to the actual issue, I would think. I may have time to dig into this more next week.

[TTMTT]

@peaceharborco Yes, the issue is from roundcube with cpanel.. if there were a loop, another message from Cloudflare would have appeared. However, this confirms that the issue is related to SSL security or tokens in cPanel and Roundcube. I've tried searching through both old and latest files of Roundcube for the modified codes, but there are many, and it takes time to pinpoint exactly where the issue lies in the code.

@troglodyne I took the files from another website that also uses cPanel because I know cPanel has additional files within Roundcube. That's why I pulled an older version of Roundcube from a website using cPanel. This is a temporary solution. Roundcube and cPanel are aware of this issue and will resolve it soon in upcoming releases. you can download my files to try it .. backup your roundcube files!! roundcube.tar.gz

[TTMTT]

@troglodyne @peaceharborco @johndoh Ok guys.. Finally, I found where the problem lies. The issue is not with Roundcube, it's with the cPanel plugin, specifically CardDAV. You'll find it in this path:

/usr/local/cpanel/base/3rdparty/roundcube/plugins/carddav

The exact problem is in the config.inc.php file. An "if" condition should be added to the code to check if /var/cpanel/calendarserver exists on the server or not because it will use port 2080, which is not supported by Cloudflare.

Solution: Replace the following code in the /usr/local/cpanel/base/3rdparty/roundcube/plugins/carddav/config.inc.php file, and the webmail will work:

<?php
$prefs['_GLOBAL']['suppress_version_warning'] = false;
$prefs['_GLOBAL']['sync_collection_workaround'] = false;
if(file_exists('/var/cpanel/calendarserver')) {
    $domain = getenv('HTTP_HOST');
    if( empty($domain) ) $domain = getenv('DOMAIN');
    // Figure out the expected formatting based on username 
    $userName = (string) $_SERVER['_RCUBE'];
    $userFormat = (string) '%l@%d'; 
    if( strpos($userName, '/') === false) { 
        $userFormat = '%l'; 
    }

    $prefs['cPCardDAV'] = array( 
       'name'     => 'cPanel CardDAV', 
       'username' => $userFormat, 
       'password' => '%p', 
       'url'      => 'https://' . $domain . ':2080/addressbooks/' . $userFormat . '/addressbook/', 
       'active'   => true, 
       'fixed'    => array( 'name', 'username', 'password' ), 
       'hide'     => false, 
    );
}

?>

[troglodyne]

Interesting. This seems to match the findings some of my colleagues had. Cloudflare indeed doesn't support https on port 2080.

Certainly doing what you have done here will stop the issue, but it also will prevent users from access to CALDAV services (which are delivered over port 2080). In v120 we enabled this by default, so that is why this would be showing up now. You could alternatively disable cpdavd in WHM's service manager (if you happen to administrate the server) and it would stop the problem, but that also would mean no WebDAV in case you used that.

Anyways, at this point you've provided convincing detail that this is not an upstream roundcube bug, so this issue can likely be closed in favor of whatever fix we work up at cPanel. I'm not sure whether we ultimately ask CF to fix this, or we do something else. Certainly we could patch SABRE DAV's client to just read over a local socket to get around this as one example of a way to fix the problem without just disabling CALDAV/CARDDAV for users.

[TTMTT]

@troglodyne Even if CALDAV is enabled by default in version v120, the same file doesn't exist in /var/cpanel/calendarserver. This means you also need to install it separately.

I think there's another solution, but it might be a bit cumbersome, which is modifying port 2080 to any port supported by Cloudflare. However, I believe this can only be done by cPanel inc to change the port.

Nevertheless, if someone is using Cloudflare, they wouldn't be using CALDAV because it also previously used port 2080, which is not supported by Cloudflare.