Passbolt timing out (Oracle cloud, iptables)

ubuntu@passbolt2:/usr/share/nginx$ sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
1 Like

If there is still no response from your client browser, try getting a response with the command line on the server again:

Okay, now we’re getting the passbolt page.:

ubuntu@passbolt2:/usr/share/nginx$ curl -L
<!doctype html>
<html class="passbolt no-js version launching no-passboltplugin" lang="en">
    <meta charset="utf-8"/>
    <title>Passbolt | Open source password manager for teams</title>

        ____                  __          ____
       / __ \____  _____ ____/ /_  ____  / / /_
      / /_/ / __ `/ ___/ ___/ __ \/ __ \/ / __/
     / ____/ /_/ (__  )__  ) /_/ / /_/ / / /_
    /_/    \__,_/____/____/_.___/\____/_/\__/

    Open source password manager for teams
    Copyright (c) Passbolt SA (

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU Affero General Public License as
    published by the Free Software Foundation, either version 3 of the
    License, or (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    GNU Affero General Public License for more details.

    You should have received a copy of the GNU Affero General Public License
    along with this program. If not, see

    <meta name="description" content="Open source password manager for teams">
    <meta name="keywords" content="Passbolt, password manager, online password manager, open source password manager">
    <meta name="robots" content="noindex, nofollow">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <link rel="shortcut icon" type="image/x-icon" href="" />
    <link rel="icon" href="" sizes="32x32" />
    <link rel="icon" href="" sizes="57x57" />
    <link rel="icon" href="" sizes="76x76" />
    <link rel="icon" href="" sizes="96x96" />
    <link rel="icon" href="" sizes="128x128" />
    <link rel="icon" href="" sizes="192x192" />
    <link rel="icon" href="" sizes="228x228" />
    <base href="">
        <script src="" id="stylesheet-manager" data-file="api_authentication.min.css" cache-version="3.7.1"></script></head>
<!-- main -->
<div id="container" class="page ">
<script src="" cache-version="3.7.1"></script><script src="" cache-version="3.7.1"></script></body>
1 Like

@unboostedvtak So if you still cannot access via the browser, I would look at the firewall settings or something like a fail2ban service that might be running and blocking your client ip due to too many failures, etc.

You could check the /var/log/ufw for errors, if you have ufw enabled.

Sometimes I run tcptrack -i <interfacename> to see what activity is coming in. But if there is no activity on the server at all, it appears there is something else in the network that has changed.

I’ve tried accessing it through a different IP, phone, over browser, on mobile data, and getting Address Unreachable.
Never used tcptrack before, it seems pretty neat.

I ran a tcpdump as well during that, and that’s what I’m getting…

Other public organizations are clearly hitting your NGINX logs with searches, so is there a rule somewhere that blocks internal network ip access? Or does your client machine have a block on returned responses maybe?

I should have clarified, the previous, is coming from the IP I am accessing from.
Same when I used my phone’s browser, from the IP of the phone.

It does look like the traffic is hitting the server.

That is what it looks like when something is getting blocked, in my opinion. When the traffic is getting through it looks like:

My only established state there is my SSH connection to the server, any other attempts at connecting I get the “SYN_SENT”

I’ll be honest, I’m now a bit out of my element here…

Interestingly enough though, if I leave the page open, this pops up periodically:

Local IP over what looks like an APIPA address over 80 established?

Is there a management system handling this particular VM/server? Like cpanel or Virtualmin? Or, is this a plain-vanilla Ubuntu 22 install? It seems like there are overriding processes occurring.

It’s a VM up in Oracle cloud. Vanilla Ubuntu as far as I can tell. Never used Virtualmin or CPanel before, but have used Webmin, if it’s a similar thing I don’t see what’s stopping me from getting that put onto there.

No, we would prefer plain vanilla. @AnatomicJC any ideas?

1 Like

Server is running IPtables. It was working fine before I changed SMTP details, I don’t see the relation between the issues we’re having now from changing SMTP credentials :joy::sob:

Only rules I’ve explicitly added, on top of what Oracle pre-loads is to allow 80 and 443 in, it should allow everything out of itself by default from my understanding.
With the rules added, it was working. It all went wrong changing credentials…

When I ran nginx -t explicitly on the config file, it was looking for that config in /usr/share/nginx but it wasn’t in there, do you think that may have anything to do with it maybe? Missing copy or symlink maybe?

Typically, nginx.conf will reference the location of the other config files. You could check that: /etc/nginx/nginx.conf

The nginx test command is going to by default check the entire configuration - I think when you specified a file, you inadvertantly pointed it to a non-existing config file in the /etc/nginx folder. I think the issue is resolved regarding passbolt. Something is blocking external requests.

Check other logs. syslog, etc.

Pretty much the only thing in syslog is

ubuntu@passbolt2:/var/log$ tail -f /var/log/syslog
Sep 13 16:05:01 passbolt2 CRON[32298]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:06:01 passbolt2 CRON[32315]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:07:01 passbolt2 CRON[32333]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:08:01 passbolt2 CRON[32350]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:09:01 passbolt2 systemd[1]: Starting Clean php session files...
Sep 13 16:09:01 passbolt2 systemd[1]: phpsessionclean.service: Deactivated successfully.
Sep 13 16:09:01 passbolt2 systemd[1]: Finished Clean php session files.
Sep 13 16:09:01 passbolt2 CRON[32441]: (root) CMD (  [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi)
Sep 13 16:09:01 passbolt2 CRON[32442]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:10:01 passbolt2 CRON[32484]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:11:01 passbolt2 CRON[32502]: (www-data) CMD ($PASSBOLT_BASE_DIR/bin/cron)
Sep 13 16:11:41 passbolt2 systemd[1]: Starting Cleanup of Temporary Directories...
Sep 13 16:11:41 passbolt2 systemd[1]: systemd-tmpfiles-clean.service: Deactivated successfully.
Sep 13 16:11:41 passbolt2 systemd[1]: Finished Cleanup of Temporary Directories.

I tried to access it again while running the tail command to see if it populated anything… Other than that in syslog looks like a cron job every minute or so.

Passbolt seems to be running according to curl now, which is good I guess.

I know you said you added rules to iptables, can we verify?

sudo iptables -L INPUT


No route to host” and ERR_CONNECTION_TIMED_OUT in the browser: each time I encountered this, it was a firewall issue. There is for sure a firewall rule who is blocking connection, a rule on the server, or somewhere else in your Oracle cloud network. :confused:

1 Like

This is what the output is:

ubuntu@passbolt2:~$ sudo iptables -L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     udp  --  anywhere             anywhere             udp spt:ntp
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:http
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
ACCEPT     icmp --  anywhere             anywhere

I can’t lie, I don’t see my 443 rule appearing on there…

Here’s a reference where they explain why they don’t use ufw.

Mentions iptables steps. I saw you saved the rules but maybe they don’t respect that netfilter command.


You two are ***ing legends.

Got it back up, thank you very much.

I’m guessing the netfilter save actually did nothing. – though, i have rebooted before, but hey, linux…

I’ve gone into the file for iptables, as suggested in the article you sent, manually entered it in, reloaded the iptables service, nothing, rebooted, it’s back up.


Odd that changing smtp details broke it in the first place, but I can confirm that is working with an app password too now.

Thank you!