Mobile 2.0 "The server is not reachable" error

I was thinking about the same - seems like there is still an issue with TLS 1.3; let me see what I can find out.

Hi,

pretty much a longshot, but we experience no problems with a similar setup (nginx proxy) on mobile 2.0 apps (ios/android).

I compared the nginx config from above with the one we use and you might want to try the following changes:

server {
   ...
   http2_push_preload on; # Enable HTTP/2 Server Push
   ssl_protocols TLSv1.3 TLSv1.2;
   add_header X-Early-Data $tls1_3_early_data;
}
...
# This block is useful for debugging TLS v1.3. Please feel free to remove this
# and use the `$ssl_early_data` variable exposed by NGINX directly should you
# wish to do so.
map $ssl_early_data $tls1_3_early_data {
  "~." $ssl_early_data;
  default "";
}

Just an idea…

Thanks for the input - server still not reachable :confused:

But your Qualys Check shows TLS 1.2 support now?

The problem indeed is with TLS 1.3-only servers and a fix has been created already:

So if you enable TLS1.2 for the time being, you should be able to connect with the mobile client, (one of) the next release(s) will include the fix for TLS1.3.

Thanks for reporting!

1 Like

I finally fixed the TLSv1.2 problem! You need to manually edit the nginx ssl.conf and add TLSv1.2 to ssl_protocols

Instructions:

sudo nano /etc/nginx/conf.d/ssl.conf

Then, you should see something like:

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name XXX.XXX.XXX.XX;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
    ssl_prefer_server_ciphers on;
#    ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
    ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off; # Requires nginx >= 1.5.9
    ssl_stapling on; # Requires nginx >= 1.3.7
    ssl_stapling_verify on; # Requires nginx => 1.3.7
#    resolver $DNS-IP-1 $DNS-IP-2 valid=300s;
    resolver_timeout 5s;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
}

Finally, add TLSv1.2 to ssl_protocols:

server {
    listen 443 http2 ssl;
    listen [::]:443 http2 ssl;

    server_name XXX.XXX.XXX.XX;

    ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;
    ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    ssl_protocols TLSv1.3 TLSv1.2;# Requires nginx >= 1.13.0 else use TLSv1.2
    ssl_prefer_server_ciphers on;
#    ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
    ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
    ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
    ssl_session_timeout  10m;
    ssl_session_cache shared:SSL:10m;
    ssl_session_tickets off; # Requires nginx >= 1.5.9
    ssl_stapling on; # Requires nginx >= 1.3.7
    ssl_stapling_verify on; # Requires nginx => 1.3.7
#    resolver $DNS-IP-1 $DNS-IP-2 valid=300s;
    resolver_timeout 5s;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;
    add_header X-XSS-Protection "1; mode=block";
}

Done! TLSv1.2 should work!

Yes, that’s exactly what @jprusch1 wrote in his comment :slight_smile:

For now, TLS 1.3 only on iOS is broken in the mobile app, but a fix is on the way.

Hi, not exactly, you ALSO need to update the conf.d/ssl.conf in order to make it work :grinning:

Anyways, it works! Thanks guys for the effort!

That’s usually not necessary, since all the settings there are overwritten on a per server basis, but the default settings in your ssl.conf might contradict with the settings in your server config, so it could very well be, that some additional tweaking is necessary.

Glad to hear the workaround is working for you, I’ll update back here once the PR got merged into a release and the app is supporting TLS1.3.

1 Like

I have the same problem with 2.1.0, build 6000457, on Android 12. Force stop and restart did not help.

The troubleshooting docs says to erase the app and reinstall it, so now I get “Cannot connect to the server” in the first welcome screen instead. The docs also tells me to try demo.mattermost.com instead, but that instance has been removed, so I can’t check whether the app works with it.

The Mattermost server works just fine in Firefox on the same mobile phone, on the same wifi.

Feel free to check connectivity yourselves at https://mattermost.redpill-linpro.com (it currently supports TLS 1.2, but not 1.3.)

Hi @kjetilho and welcome to the Mattermost forums!

What docs do still refer to demo.mattermost.com? I’d like to get them updated, thanks!
You could try https://community.mattermost.com instead.

The mobile app prefers IPv6 connectivity and since your hostname also has an IPv6 address, it could very well be that there’s a problem with that, but only if your WiFi also supports IPv6. The encryption settings and certificate chains look good as far as I can tell, in order to run a connection test I would need a username on this server, so having the URL alone does not allow me to test it in the mobile app.

If you manage to login to the community server on your mobile app, you will be able to access the logs of the app and send them to you via e-mail, maybe they contain more relevant information then (once logged in, click on your profile picture in the bottom right → Settings → Report a problem) .

Thanks! Looks like you are right - I enabled Wireguard on my phone which provides me with IPv6 connectivity, and then the app works. So it seems like the app needs some “Happy Eyeballs” support? It’s a bit weird it continued working after I turned off Wireguard, too, but logging out and signing back in still had the problem (phew!).

The outdated docs are at Troubleshooting mobile apps — Mattermost documentation

Oh - and I should mention: https://community.mattermost.com causes the same problem for the app as my company server.

1 Like

Thanks, that’s very interesting and I’d still like to understand what happened here on your end. There seems to be an error with the detection of having IPv6 availabe.
When you’re not using Wireguard, does your phone have an IPv6 address assigned to it and are you able to build outbound IPv6 connections? You could try to visits sites like https://ipv6-test.com to see if this is working for you.

Hello guys,

I got the same connectivity issue of server is unreachable but for the cloud version of MM on iOS. Seems like everyone in my organization has trouble with notifications on Cloud MM.

I use:
App Version: 2.3.0 (Build 465)
Server Version: 7.10.0 (Build cloud-2023-04-21-1)
Database: postgres
Database schema version: 106

@agriesser were mentioning that the issue for iOS is known and the fix is coming. Could you share a link or any other means to track the progress?

Hey @gt443fsrsd and welcome to the Mattermost forums!

Cloud deployments also run on IPv6 so yes, this could be related.
I’m not sure if there’s a ticket on that topic, but it has been brought to the attention of the developers on the community server, but I’m not sure if there’s already work in progress on that topic. If you’re a cloud customer, I suggest you raise this ticket with cloud support and point them to this forum topic, I’m sure they know if there has been an internal ticket for this issue.

It turned out that the IPv6 settings of my wifi-router were broken. So the app is right to say “not reachable”, but it would be nice if it did a fallback to IPv4 in these cases (like Firefox did).

Yes, it should and it has already been voiced as a wish that the app either supports a feature called “happy eyeballs” (which is basically an implementation of a parallel v6 and v4 connection with an immediate fallback) or it fails over transparently to v4 if the v6 connection is not possible; not sure when this will make it into the app, but the problem is known and has been discussed with the developers.