Server URL in Client software changes to Internal IP:Port

Troubleshooting
1

Hi Mattermost forums, I hope you can help me with this.

Summary
In the most recent client software (v5.2.0) when I put the “Server URL” I have always used to connect to our On Premise Mattermost Server from external It keeps changing to an internal access IP:Port (http://192.168.1.20:8065)

Steps to reproduce
I am unsure how you would reproduce this error. I am using Client v5.2.0 and Server v6.3.9

Expected behavior
I would expect an external client not to have its configured “Server URL” over written with an internal IP:Port url.

Observed behavior
The client eventualy times out and asks me to verify things including that:

The Mattermost URL http://192.168.1.20:8065 is correct

I know that isn’t correct for external access to the server. But every time I try to reset it in the Mattermost client configuration window it reverts back to internal IP:Port.

Everything still works fine in a regular browser and on iPhone apps. It is only the Mattermost client that seems to have these issues.

Thanks Everybody.

Chris

2

As an extra note… I rolled back to client version 5.0.4 and things are working as expected. The “Server URL” does not try to overwrite its self with an internal IP:Port entry.

Is there a link to find old versions? I had to go searching my old downloads to find an older copy of the client installer.

Thanks,

Chris

3

Hi Number41 and welcome to the Mattermost forums!

The issue you mentioned is actually a feature introduced with the 5.2.0 release, you can read about it here:

In a nutshell, the client reads the configured SiteUrl value of your Mattermost server and uses it for the connection, so if you change the SiteUrl in your config.jsonand restart the Mattermost server, this problem should be fixed.

You can find the binaries for all older releases directly on GitHub:

The previous version was 5.1.1 which you can download directly from here:

4

Hi, thank you very much for your patient reply. One of my concerns is whether it makes sense to force clients to use SiteURL set up on the server side.

Firstly, this feature is confusing to users who don’t specifically set up SiteURL on the server.

Secondly, this feature creates obvious limitations. In the past, if an administrator wanted to set different SiteURLs for different groups of users, he/she could simply have them fill in their own SiteURLs on the client side. But with this feature, all users are forced to use the same SiteURL (that is, the unique SiteURL configured on the server side).

I understand that this feature may be for security and administrative convenience, but it does cause confusion. I think this feature should be introduced on the server side, not the client side. For example, an administrator can configure on the server whether to force clients to use SiteURL provided on the server. After all, new features should give more convenience than they give more limitation and confusion.

5

Thank you,

Adjusting the setting on the server side did fix the issue I was experiencing.

But I must agree with bfygoaah. This feature does seem to reduce flexibility. Is there somewhere I can read about the reasoning behind this change?

Thanks,

Chris

6

As a sysadmin, I cannot think of a situation where I would want my users to choose the SiteURL.
Can you provide an example where an administrator would want to provide different SiteURLs for different user groups?

Unfortunately, I cannot answer the questions with regards to the reasoning and the decision behind that, I was looking for that too, but to no avail as of yet, so I’m interested in your examples on why this reduces flexibility or prevents current workflows so I could initiate another discussion about that with the developers.

Thanks!

7

I wouldn’t necessarily be users choosing their own URLs to access MatterMost. I’d see it more as the administrator giving the users the URL to use depending on whether they are accessing from External or from an internal subnet within an organization for example.

Naming conventions may be different for different network segments, and External vs. Internal, that all may need to get to the MatterMost server. Depending on routing and/or proxying if a single URL (DNS Name) is forced the ability to use different names depending on communication origin is lost.

In our case not only did I change SiteURL on the server (Thanks for that of course) but am having to do some quick split DNS work so that naming for MatterMost on our internal network will now match what it is accessed with from External through proxy.

In the end this works fine for our case but I still can’t help but view it as reduced flexibility.

Cheers,

Chris

1 Like
8

Oh… One more though from a trouble shooting perspective.

If trying to trouble shoot an issue with one remote user who can’t connect it is much easier to have them initially test access using an IP Address to start checking if name resolution is the issue for example.

I’ve found this is sometimes the simplest way with some users to determine name resolution related connection issues. While lots of staff are great at what they do things like nslookups in CMD (or possibly Terminal on a Mac) and/or adding host file entries are not always that easy to walk them through.

Now granted I could change the SiteURL in MatterMost to the IP address to match for testing but that would affect anyone that is using MatterMost from network segments that are not coming from the external network (this trouble shooting session being for a remote user).

I’m thinking the change of SiteURL in this example case to the external IP address (and eventual change back to DNS name) would go unnoticed by all other remote workers but am not fully certain of that.

1 Like
9

This doesn’t work out of the box, I guess. You will have to set up the respective reverse proxy configurations and will have to set up multiple SSL certificates in order to support more than just one domain. Also a lot of plugins (especially the calls plugin) does also only support to specify one entry point for the call streams, so I think such a configuration is generally not really supported by Mattermost at all and the latest change to the desktop app just reminds us about that.

I think working with internal DNS overrides then or some kind of u-turn NAT is what should be done here, at the end of the day, it’s also easier for the sysadmin not having to ask where the user is coming from and to be sure that everyone is accessing the server using the same domain and the same route.

In a default, secure Mattermost setup, this should not be possible at all, given the fact that there should be SSL and HSTS enabled. Whenever you try to access the IP address directly, you would get an error message and the client would not connect anyways.
For connection debugging purposes, you can always send them via the webbrowser to your Mattermost domain and with regards to further troubleshooting options I’ve read that there will be a feature in one of the next desktop app versions to run some connection diagnostics directly inside the app, which might also help with situations like these.

The SiteUrl is also being used for several other things, like links in e-mails, OAuth integrations, etc., so while accessing the Mattermost server with basic functionality itself might work when using the IP address or alternative domain names, the best practice is to use just one SiteURL and make sure all your clients access the server using the same name:

https://docs.mattermost.com/configure/web-server-configuration-settings.html#site-url

10

Thank you agriesser for your thoughts on this.

Yes, when thinking about this wasn’t considering the other places that SiteURL is used.

Cheers,

Chris

11

Many thanks to agriesser for the explanation. I can now better understand the reasoning behind introducing this new feature.

However, I still think this feature does cause some trouble.

First, not all Mattermost-server administrators have public IP and high public bandwidth. Many Mattermost server administrators are self-hosters. Typically, Mattermost-server is deployed within an institution. For users inside the institution, they can access through the internal ip. For the users outside the institution, they need to use the NAT traversal technology to access through the external ip. Internal ip access can provide high quality services with high bandwidth and low latency. External ip access ensures high accessibility of the service. Without extra work, forcing every client program to use Mattermost-server’s unique SiteURL can cause a lot of trouble. Using only internal urls makes it completely inaccessible to external users. If only external urls are used, the quality of service for internal users will be severely degraded.

Second, to implement the same flexible service scheme as before requires a significant amount of additional work for both administrators and users. Administrators need to reconfigure domain names and DNS services for different user groups. Users will also need to add different DNS configurations for their devices with the help of their administrator. The configuration cost of all this extra work can be extremely high.

Therefore, I would still recommend implementing this new feature on the server side instead of the desktop/mobile app side. I think one possible solution is to let the server decide which SiteURLs the client can access its service through. The new feature is great for alerting administrators and users about how to securely setup Mattermost, but I hope it puts the choice in the hands of the administrators of Mattermost services, rather than adding restrictions directly.

In addition, my other suggestion is that it might make more sense to implement such new administration-related features on the server side. When implemented on the client side, there are several problems. First, changes on the user side are not easily notified to administrators, so administrators are unaware of the problems and are harder to diagnose. Second, the user’s own diagnostic ability is generally weaker and they are at a loss in the face of service interruption. This can lead to user complaints and distrust of Mattermost. Third, the devices and systems of users are diverse, and the workload and difficulty in diagnosis are greater.

All in all, after reading your explanation, I believe this new feature is quite good but misplaced. I hope you will think about my suggestions. Of course, my suggestions are based on the perspective of part of users, and may be not to the point. If there is somewhere unreasonable, you are always welcome to criticize.

Thank you sincerely!

12

I don’t think that this is really a problem for everyone working in a rather large institution or corporation. All you’d have to do is to override the domain name on your internal DNS resolvers. There are also technologies available like DNS inspection or DNS doctoring on SOHO firewalls that will rewrite the request for you or allow inside-out access to the service without having to work on the NAT rules at all, so even in smaller SOHO networks as well as in corporate networks, you can still use one single domain name for accessing the service with just a small configuration need in your internal network (like DNS override settings, DNS doctoring or u-turn/hairpin NAT rules).

Please do not forget that the setup you used to have was unsupported by design and all implementation documents as well as setup guides always ask you to set the SiteURL and talk about this option to be a mandatory setting. The fact that it worked for you was maybe just because you did not make use of all the features Mattermost offers or were just lucky that you did not hit the limitations when the SiteURL is not set or does not match the URL people are accessing the server with (this also includes e-mails, permalink generation and all the other things I mentioned in my previous post).

The feature should have been made more prominent in the changelog that’s for sure, but on the otherhand, the developers most likely assumed that everyone followed the instructions when setting up a Mattermost server and this would include setting up the SiteURL properly - maybe that’s the reason why this change in behaviour was not thought of being a problem at all, but as a community member, I do not have any insight into the decision process here and can only make assumptions here.

I still think of it as an improvement in order to make the deployments more stable in the future and if it would be my decision, I would not let the server start with an unconfigured SiteURL to avoid such issues right from the start, but it’s also possible to start it without a configured SiteURL for maybe some valid reason which I also do not know…