IPTables firewall doesn't open ports

Hello all!

Setting up “Seafile” on my test server took me to a new problem with Hestia CP:

I opened two ports in the panel (8000 tcp and 8080 tcp) but connections are refused.

Both files /etc/iptables.rules and /usr/local/hestia/data/firewall/rules.conf seem to have been properly updated:

/etc/iptables.rules
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8000 -j ACCEPT

/usr/local/hestia/data/firewall/rules.conf
RULE=‘11’ ACTION=‘ACCEPT’ PROTOCOL=‘TCP’ PORT=‘8000’ IP=‘0.0.0.0/0’ COMMENT=‘Seafile’ SUSPENDED=‘no’ TIME=‘22:12:24’ DATE=‘2020-03-23’
RULE=‘12’ ACTION=‘ACCEPT’ PROTOCOL=‘TCP’ PORT=‘8080’ IP=‘0.0.0.0/0’ COMMENT=‘Seafdav’ SUSPENDED=‘no’ TIME=‘23:01:59’ DATE=‘2020-03-23’

root@test:~# iptables -L -v 
0     0 ACCEPT     tcp  --  any  any     anywhere    anywhere    tcp dpt:8080
2   104 ACCEPT   tcp   --  any  any     anywhere   anywhere    tcp dpt:8000

Everything seems to be o.k., but besides refused connections nmap doesn’t list the ports open:

root@test:~# nmap 116.203.xxx.xxx -p 8000-9000
Starting Nmap 7.70 ( https://nmap.org ) at 2020-03-23 23:40 CET
Nmap scan report for my.hostname.de (116.203.xxx.xxx)
Host is up (0.0000090s latency).
Not shown: 1000 closed ports
PORT     STATE SERVICE
8083/tcp open  us-srv
Nmap done: 1 IP address (1 host up) scanned in 1.63 seconds

Restarting iptables by the panel button had no effect, neither rebooting the server.

Any idea what I’m doing wrong?

Hestia Control Panel: v1.1.1
Debian 10.3 (x86_64)

Thanks,
Nifoco

Did you already run v-update-firewall once to load the rules? Even they are looking loaded in iptables. Are you sure that seafile is up and running?

Yes, Seafile is running:

root@test:~# sudo lsof -i:8000
COMMAND     PID    USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
python2.7 17034 seafile    7u  IPv4  63546      0t0  TCP localhost:8000 (LISTEN)
python2.7 17039 seafile    7u  IPv4  63546      0t0  TCP localhost:8000 (LISTEN)
python2.7 17040 seafile    7u  IPv4  63546      0t0  TCP localhost:8000 (LISTEN)
python2.7 17041 seafile    7u  IPv4  63546      0t0  TCP localhost:8000 (LISTEN)
python2.7 17042 seafile    7u  IPv4  63546      0t0  TCP localhost:8000 (LISTEN)
python2.7 17043 seafile    7u  IPv4  63546      0t0  TCP localhost:8000 (LISTEN)

Have tried v-update-firewall, no effect. Still no connection, nmap shows port 8000 as “not opened”.

root@test:~# nmap 116.203.xxx.xxx -p 8000
Starting Nmap 7.70 ( https://nmap.org ) at 2020-03-24 11:56 CET
Nmap scan report for my.hostname.de (116.203.xxx.xxx)
Host is up (0.000073s latency).

PORT     STATE  SERVICE
8000/tcp **closed** http-alt

Nmap done: 1 IP address (1 host up) scanned in 0.25 seconds

Update information:
Installed “Teamspeak3” and opened port 9987 UDP in the panel: WORKING.

Maybe you are right and it’s a problem with “Seafile” or special port 8000, not with firewall.

However, I have installed Seafile often before on other systems with other panels and I am doing exactly the same way here. Very strange…

1 Like

The problem is fully solved. Indeed it was NOT an issue of Hestia or firewall but of Seafile.

For those who are interested:

By default Seafile installation binds to “127.0.0.1:8000” in file gunicorn.conf which works with further configuration of Nginx as HTTP proxy but not with direct access via port 8000 (http://cloud.my-domain.xyz:8000).

However, accessing Seafile by port 8000 is the out-of-the-box configuration which is decribed in the documention as immediately working after installation.

In other words:

If you want to access Seafile by Nginx HTTP proxy (which is the best and common way, I admit, because you want to use secure https), than leave everthing in Seafile as it is and configure Nginx as proxy following the steps of the official documentation.

If you want to access Seafile directly by port 8000 (e.g. because you use VPN, like I do), than change file /seafile-install-path/seafile/haiwen/conf/gunicorn.conf like that:

[...]
# bind = "127.0.0.1:8000"
bind = "0.0.0.0:8000"
[...]

Since I have installed Seafile always with Apache proxy before it’s the first time I faced this issue. Seafile installation process should be changed or better documented.

1 Like

glad to see you found a solution :wink:

to add to that, even if you installed seafile as a seperate user in the system outside the scope of hestia, you can use hestia to add a web domain and then use a small additional custom config in /home/[user]/conf/web/[domain] to get the normal nginx/apache work as a proxy…

PS: just to clarify, don’t edit the conf files directly, as they might get overwritten, you can add your custom files instead so they get included :wink: thanks @ScIT for the reminder

1 Like