LAN-only without SSL mattermost setup causing CORS errors

Troubleshooting
1

Summary
Deploy went smooth, but I get the red banner “Please check connection, Mattermost unreachable. If issue persists, ask administrator to check WebSocket port.”

Steps to reproduce
Fresh new installation through docker, deployed without NGINX. In the following I report my .env. Docker compose yml untouched, as I followed instructions here: Deploy Mattermost using Containers - Mattermost documentation, steps 1,2,3,5 (only the part without nginx). Notice that, since I want a LAN-only deploy without SSL (I’m doing some quick tests to see if mattermost fullfills my needs), I am putting the IP as domain. Not sure if this is compromising the deploy (I also tried to put “localhost”, but I obtain the same behaviour).
No certificate generated / used.

.env file:

# Domain of service
DOMAIN=<IP> # same of the one in the logs, public IP of the ubuntu VM hosting mattermost on docker

# Container settings
## Timezone inside the containers. The value needs to be in the form 'Europe/Berlin'.
## A list of these tz database names can be looked up at Wikipedia
## https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
TZ=UTC
RESTART_POLICY=unless-stopped

# Postgres settings
## Documentation for this image and available settings can be found on hub.docker.com
## https://hub.docker.com/_/postgres
## Please keep in mind this will create a superuser and it's recommended to use a less privileged
## user to connect to the database.
## A guide on how to change the database user to a nonsuperuser can be found in docs/creation-of-nonsuperuser.md
POSTGRES_IMAGE_TAG=13-alpine
POSTGRES_DATA_PATH=./volumes/db/var/lib/postgresql/data

POSTGRES_USER=username_chosen
POSTGRES_PASSWORD=chosen_passwd
POSTGRES_DB=chosen_name

# Nginx
## The nginx container will use a configuration found at the NGINX_MATTERMOST_CONFIG. The config aims
## to be secure and uses a catch-all server vhost which will work out-of-the-box. For additional settings
## or changes ones can edit it or provide another config. Important note: inside the container, nginx sources
## every config file inside */etc/nginx/conf.d* ending with a *.conf* file extension.

## Inside the container the uid and gid is 101. The folder owner can be set with
## `sudo chown -R 101:101 ./nginx` if needed.
## Note that this repository requires nginx version 1.25.1 or later
NGINX_IMAGE_TAG=alpine

## The folder containing server blocks and any additional config to nginx.conf
NGINX_CONFIG_PATH=./nginx/conf.d
NGINX_DHPARAMS_FILE=./nginx/dhparams4096.pem

CERT_PATH=./volumes/web/cert/cert.pem
KEY_PATH=./volumes/web/cert/key-no-password.pem
#GITLAB_PKI_CHAIN_PATH=<path_to_your_gitlab_pki>/pki_chain.pem
#CERT_PATH=./certs/etc/letsencrypt/live/${DOMAIN}/fullchain.pem
#KEY_PATH=./certs/etc/letsencrypt/live/${DOMAIN}/privkey.pem

## Exposed ports to the host. Inside the container 80, 443 and 8443 will be used
HTTPS_PORT=443
HTTP_PORT=80
CALLS_PORT=8443

# Mattermost settings
## Inside the container the uid and gid is 2000. The folder owner can be set with
## `sudo chown -R 2000:2000 ./volumes/app/mattermost`.
MATTERMOST_CONFIG_PATH=./volumes/app/mattermost/config
MATTERMOST_DATA_PATH=./volumes/app/mattermost/data
MATTERMOST_LOGS_PATH=./volumes/app/mattermost/logs
MATTERMOST_PLUGINS_PATH=./volumes/app/mattermost/plugins
MATTERMOST_CLIENT_PLUGINS_PATH=./volumes/app/mattermost/client/plugins
MATTERMOST_BLEVE_INDEXES_PATH=./volumes/app/mattermost/bleve-indexes

## Bleve index (inside the container)
MM_BLEVESETTINGS_INDEXDIR=/mattermost/bleve-indexes

## This will be 'mattermost-enterprise-edition' or 'mattermost-team-edition' based on the version of Mattermost you're installing.
MATTERMOST_IMAGE=mattermost-team-edition
## Update the image tag if you want to upgrade your Mattermost version. You may also upgrade to the latest one. The example is based on the latest Mattermost ESR version.
MATTERMOST_IMAGE_TAG=10.5.2

## Make Mattermost container readonly. This interferes with the regeneration of root.html inside the container. Only use
## it if you know what you're doing.
## See https://github.com/mattermost/docker/issues/18
MATTERMOST_CONTAINER_READONLY=false

## The app port is only relevant for using Mattermost without the nginx container as reverse proxy. This is not meant
## to be used with the internal HTTP server exposed but rather in case one wants to host several services on one host
## or for using it behind another existing reverse proxy.
APP_PORT=8065

## Configuration settings for Mattermost. Documentation on the variables and the settings itself can be found at
## https://docs.mattermost.com/administration/config-settings.html
## Keep in mind that variables set here will take precedence over the same setting in config.json. This includes
## the system console as well and settings set with env variables will be greyed out.

## Below one can find necessary settings to spin up the Mattermost container
MM_SQLSETTINGS_DRIVERNAME=postgres
MM_SQLSETTINGS_DATASOURCE=postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable&connect_timeout=10

## Example settings (any additional setting added here also needs to be introduced in the docker-compose.yml)
MM_SERVICESETTINGS_SITEURL=http://${DOMAIN}

Moreover, ufw is disabled.

Expected behavior
No banner appearing

Observed behavior

Once logged in, after a while the red banner about the connection appears, and the logs of the container show:
{"timestamp":"2025-05-28 15:12:19.438 Z","level":"debug","msg":"URL Blocked because of CORS. Url: http://<IP>:8065","caller":"web/context.go:119","path":"/api/v4/websocket","request_id":"<ID>","ip_addr":"<CLIENT_IP>","user_id":"<ID>","method":"GET","err_where":"connect","http_code":400,"error":"connect: URL Blocked because of CORS. Url: http://<IP>:8065, websocket: request origin not allowed by Upgrader.CheckOrigin"}
{"timestamp":"2025-05-28 15:12:19.438 Z","level":"debug","msg":"Received HTTP request","caller":"web/handlers.go:185","method":"GET","url":"/api/v4/websocket","request_id":"<ID>","user_id":"<ID>","status_code":"400"}

Where:

  • <IP> is the ubuntu VM public IP,
  • <CLIENT_IP> is my client address.
2

Did you reference the variable in your docker-compose file, too?

If so, setting AllowCORS From to “*” works reliably. Probably not ideal from a security standpoint, but gives you a working baseline to fall back to. I remember looking into this about a year ago, trying to find out more about the parameters of what constitutes a valid statement in there (IP, mask, space or comma delimited, etc.)

3

First, thanks a lot for the quick answer!
Yes, as this environment variable:

is passed in the compose (attached, the environment variables of the mattermost service):

    environment:
      # timezone inside container
      - TZ

      # necessary Mattermost options/variables (see env.example)
      - MM_SQLSETTINGS_DRIVERNAME
      - MM_SQLSETTINGS_DATASOURCE

      # necessary for bleve
      - MM_BLEVESETTINGS_INDEXDIR

      # additional settings
      - MM_SERVICESETTINGS_SITEURL

I have two questions:

  1. What would be the implications of setting AllowCORS From?
  2. Can it be due to the fact that I am not deploying the version with SSL?
4

Essentially, it’s a list of domains your Mattermost server will accept cross-origin requests from. Integrations configuration settings - Mattermost documentation

And, no, this has nothing to do with TLS (I know lots of people say SSL, but SSL as a protocol was deprecated a very long time ago, and even TLS 1.0 and 1.1 are considered insecure now)

5

Thanks a lot, again!

So, if I have some IPs I know I can trust (of my clients), I could potentially accept only those?

Like "192.168.1.2,192.168.1.3,..." instead of *?

6

A qualified yes. The docs say to use spaces, and the last time this came up I recall there being some ambiguity about it. Please let us know what recipe winds up working for you!