NC docker behind Linode cloud firewall. Connection dropped when active

I have been searching up and down the forums to find out what is happening but I still have no clue.

I got a fresh Linode. Installed docker compose, portainer, nginx proxy manager and some docker containers using all sorts of ports. NC uses 8080 which is mapped to 80.

I want to have my server protected by a firewall so I thought I’d go the easy way and use linode cloud firewall. 5 out of 6 dockers containers work fine. All but Nextcloud. And it doesn’t make sense to me. ports 80 en 443 are being used by npm, it sends traffic to 8080 internally. Turning off the firewall, everything works fine, turning on the firewall, connections are dropped. If i set outbound policy to accept I don’ t experience problems. This really doesn’t make sense to me. Only 80 en 443 should have to be open.

I did set

<?php
$CONFIG = array (
  'htaccess.RewriteBase' => '/',
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'overwritehost' => 'nextclouddomain.com',
  'overwriteprotocol' => 'https',
  'apps_paths' => 

my compose file is just the default one

version: '2'

volumes:
  nextcloud:
  db:

services:
  db:
    image: mariadb:10.5
    restart: always
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    volumes:
      - db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud
    restart: always
    ports:
      - 8080:80
    links:
      - db
    volumes:
      - nextcloud:/var/www/html
    environment:
      - MYSQL_PASSWORD=
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

I’m not familiar with Linode’s firewall, but I suppose it depends on how it works. One thing that can happen with Docker if you run for example UFW firewall on the Docker server is it can block internal communication on the Docker interface.

But this firewall is probably outside the box, right?

When the connection is dropping, is nginx reporting that it gets a timeout connecting to the other port, or are you unable to connect to nginx itself?

It is outside the box indeed. I tried ufw first but was unable to figure out how to configure that. None of my containers worked after ufw. So I thought let’s go the easy route :slight_smile:

It does time out yes

Maybe I should give this another go, is this what you would suggest as well?:

So I couldn’t get that working either. What a nightmare :slight_smile: I thought this would be really easy, clean server, just a handful of apps I use daily.

But specifically, is nginx reporting a timeout (it cannot connect to backend port 8080), or are you getting a timeout in your browser (you cannot connect to frontend port 443).

It makes a big difference in where the issue is.

I think that article you linked is talking about a different issue. He says UFW won’t properly block ports opened by Docker containers.

What I experienced (and I think you as well) is the opposite problem: UFW not only blocks the container ports, but also blocks internal communication to/from them on the docker interface (docker0 or whatever it is you see in ip link show).

As I recall, the fix is that you have to allow those ports internally, or just allow any communication between the real LAN IP and the Docker network or interface. This will mean using the advanced rule syntax outlined in the UFW manual.

I don’t remember the exact syntax so you may have to tinker a bit, but I think you can do something like this, if your LAN IP is for example 192.168.1.10:

ufw allow from 192.168.1.10 out on docker0 to any
ufw allow in on docker0 to 192.168.1.10

As we speak I am getting in my browser:

504 Gateway Time-out

openresty

But what you wrote makes sense (even to me) I will check the ufw manual and try you suggestion later today. Will report back.
Thanks for your patience and help, much appreciated!

Hmm… yeah… I don’t use nginx, but that sounds to me like it can’t make the backend connection.

I wonder if you went in the Linode firewall and allowed connections from its own public IP to port 8080 if it would work?

I checked this morning. Swtiched off Linode firewall, turned on UFW (allow openssh, http, https ports) and I experience both. publicip:8080 works while it shouldn’t ideally, https://domain.com doesn’t work while it should ideally :slight_smile:

So I also switched back on the outside firewall but ONLY with inbound rules, I allow all outbound connections. This time I don’t get any timeouts. Not sure if this is best practice though, although ufw enabled also allows outbound by default.

I will try your suggestion as well when I have a bit more time, because I should also implement the solution mentioned in the article at the same time. For now at least I am up and running and blocking inbound ports apart from 22,80,443

ps with outbound enabled I had a lot of problems opening /settings/admin/overview. Security check was impossible,.

Really there should not be any need for outbound rules unless you think your server will be up to no good.

Part of the issue with UFW may also change depending on whether you use a docker network in compose, etc. it doesn’t look like you used a docker network in your setup.

Outbound rules I created without giving it much thought I guess, they were there so I created them :). Afterwards I thought: why, is this really necessary?!

Did not created a network, I am kinda new to docker compose so something else to look into I suppose.

On the positive side, everything has been running very smoothly today with my outside firewall. For now it’s an easy solution to a potentially complex challenge

Ok, good deal. If you want to see an example with network config in Docker compose, I wrote a guide for an older version. I’m not really sure how that changes things with UFW, but I suspect having a separate internal network maybe changes the firewall landscape a bit. One of those things I’ll have to sit down and tinker with one day.

Thanks for that. I have set up Nextcloud many times (the regular way) but I am reading so much new stuff here. I will definitely dive a bit deeper into to the matter soon and try to understand this setup. Very nice!