I’m glad it’s not just me. I tried the update-grub and reboot. Didn’t work for me.
The grub/kernel thing is a total red herring. It cannot be related to your Webmin problem.
OK, you’ve proven, beyond shadow of a doubt, it is a network layer issue. It absolutely cannot be Webmin that is the source of the trouble…Webmin is listening and responding to requests.
Until there’s a solution, I’ll try whatever is offered less than a complete reinstall. Plus, you’ve resigned to the fact that its not a Webmin issue, so any issues not related to Webmin should be explored too, correct?
Then why does every other application on the server listening and responding to requests from outside the network? Only Webmin doesn’t.
I’m not trying to be dismissive, just trying to prevent you from wasting time on unrelated stuff.
I honestly have no idea how to help at this point, though. It has to be network, either firewall or some routing or port forwarding issue. The problem is probably outside of the system itself, if you’re sure you’ve either stopped the firewall or allowed port 10000.
I think I remember you saying you’d ruled out the local firewall on the system being the problem, so I’ll trust you’ve done that.
Has to be outside, I think?
Trying ANYTHING isn’t a waste of time for me if there’s the most slightest chance it works.
I disabled UFW completely. I’ve never had it enabled but I double checked it being disabled. Several times.
So if someone has a possible solution, I’m all open for it.
Is this a Virtualmin system? If you used our installer, you wouldn’t have ufw, you’d have firewalld.
Edit: But, of course, if you have the firewall we configured during install, you’d have port 10000 open, no matter what.
Can I see a screenshot of a browser page, when you’re trying to visit Webmin localhost:10000 address?
Also:
- Have you tried accessing it using IP address, e.g.:
1.2.3.4:10000? - Do you have
allowdirective set in/etc/webmin/miniserv.conf, i.e. if runninggrep allow /etc/webmin/miniserv.confoutputs anything? - What is the output of
dpkg -l | grep ufwcommand? - What is the output of
firewall-cmd --list-allandip acommands?
Didn’t install virtualmin. The host configures the base VPS with just Webmin. I did do a check to see if firewalld was install. It wasn’t.
How do I add a screenshot to my replies? I can’t find that option.
- Yes
- No
- ii ufw 0.36-6ubuntu1 all program for managing a Netfilter firewall
- Command ‘firewall-cmd’ not found, but can be installed with:
apt install firewalld
Then what is the output of ufw status command?
No need.
How do I add a screenshot to my replies? I can’t find that option.
Simply copy/paste the screenshot from the clipboard (using Ctrl+C/Ctrl+V hotkeys) or drag-and-drop to the editor’s field…
Something is blocking connection to your Webmin server.
Try to start ufw and check the status instead, as not running doesn’t mean not blocking. The rules in iptables can still be active.
Also, is Webmin running and listening on the expected port? Try checking it by running:
ss -tnlp | grep miniserv
Enabled UFW. No change. this is the status:
Status: active
To Action From
10000 ALLOW Anywhere
10000/tcp ALLOW Anywhere
10000 (v6) ALLOW Anywhere (v6)
10000/tcp (v6) ALLOW Anywhere (v6)
ss returns this:
LISTEN 0 4096 0.0.0.0:10000 0.0.0.0:* users:((“miniserv.pl”,pid=1024,fd=5))
Hello. I believe there is a firewall somewhere along the way. Ping to 62.171.154.199 works correctly, but traceroute no longer. Wget from remote machine has no response:
rony@ares:~$ wget --connect-timeout=60 https://62.171.154.199:10000
–2023-05-06 15:15:11-- https://62.171.154.199:10000/
Pripájanie k 62.171.154.199:10000… zlyhalo: Časový limit pre spojenie vypršal.
Skúša sa znova.
–2023-05-06 15:16:12-- (pokus: 2) https://62.171.154.199:10000/
Pripájanie k 62.171.154.199:10000… ^C
rony@ares:~$ wget --connect-timeout=60 http://62.171.154.199:10000
–2023-05-06 15:16:25-- http://62.171.154.199:10000/
Pripájanie k 62.171.154.199:10000… zlyhalo: Časový limit pre spojenie vypršal.
Skúša sa znova.
–2023-05-06 15:17:26-- (pokus: 2) http://62.171.154.199:10000/
Pripájanie k 62.171.154.199:10000… ^C
Sorry for Slovak locales. Connection over http and https to port 10000 on machine 62.171.154.199 is timed out. Time out in wget is set to 60 seconds.
But connection to port 80 is OK. Apparently port 10000 is blocked somewhere along the way.
Scan remotely machine 62.171.154.199 with nmap.
2 Likes
Hi. Not just update grub, but:
0. Check all disks for errors
- Install newest canonical Ubuntu kernel 5.19.0.1 (was 5.15.) and grub-update (5.19.0.1 now is latest official kernel for 22.04.2 ubuntu)
- Purge UFW firewall (just do not use it, because i use FirewalD)
- Again (just in case) manualy enabled webmin port
firewall-cmd --permanent --add-port=10000/tcp
(in my case i use non default port) - Reboot
- Purge all old kernels (some 10 pcs was) and grub-update (some kernels i removed manualy, to leave only newest). Also + 1 gb free disk space.
- grub-update again.
Why kernel – in my case it helps, but why exactly – i do not know, may be disk was damaged and reinstal kernel fix it. Hard to told.
And after all this finaly Webmin loaded good, and works fine, for test purposes i try to restart webmin some times, works all ok now.
root@main:~# tcptraceroute 62.171.154.199
Running:
traceroute -T -O info 62.171.154.199
traceroute to 62.171.154.199 (62.171.154.199), 30 hops max, 60 byte packets
10 * anonymous-ic-359969.ip.twelve99-cust.net (62.115.33.119) 125.602 ms anonymous-ic-359930.ip.twelve99-cust.net (62.115.171.181) 136.024 ms
11 vmi495036.contaboserver.net (62.171.154.199) <syn,ack> 124.501 ms 124.178 ms 124.482 ms
root@main:~# tcptraceroute 62.171.154.199 10000
Running:
traceroute -T -O info -p 10000 62.171.154.199
9 nug-b1-link.ip.twelve99.net (62.115.113.175) 140.221 ms 140.185 ms *
10 anonymous-ic-359930.ip.twelve99-cust.net (62.115.171.181) 136.352 ms 136.198 ms 136.061 ms
11 * * nug-b1-link.ip.twelve99.net (62.115.113.175) 150.919 ms
12 * * *
13 * * *
14 * * *^C
62.115.171.181 seems to send port 10000 back to 61.115.113.175.
Hello @Chaiyo
While ufw can be disabled, iptables can still be running in the background.
What is the output for:
sudo iptables -L --line-numbers
The only thing I can think of is that the allow rule for tcp port 10000 is sitting below a DROP ALL or REJECT
which is normally placed at the end of the rules in iptables.
If this is the case?
You would need to remove or move the line number that port 10000 is place on, so the rule is at the top of the table above DROP and REJECT.
There are a couple ways to do this. One is to remove the port entry and re-enter it with a line number above the DROP and REJECT
The easiest way to do it, is by creating a txt file to edit the rules order:
sudo iptables-save > /tmp/iptables.txt
Edit this file with a text editor, move whichever lines you want to clean it up.
Save and reload the file:
sudo iptables-restore < /tmp/iptables.txt
I hope this resolves your issue…
Regards,
Slightly different response now. I wondered about this earlier.
7 * * *
8 * * *
9 nug-b1-link.ip.twelve99.net (62.115.113.175) 140.102 ms * 140.174 ms
10 anonymous-ic-359930.ip.twelve99-cust.net (62.115.171.181) 136.176 ms 136.092 ms anonymous-ic-359969.ip.twelve99-cust.net (62.115.33.119) 125.687 ms
11 nug-b1-link.ip.twelve99.net (62.115.113.175) 150.757 ms * *
12 * * anonymous-ic-359969.ip.twelve99-cust.net (62.115.33.119) 136.356 ms
13 * * *
14 * * *
You can do packet logging of rejected packets to see if the request ever even touches your machine or have your provider check their logs. But, a rejected packet shouldn’t cause a network loop. It should just be a dead end. There could be a load balancer artifact.
I’ve seen load balancers cause security protocol issues. Hmmm… Worth asking your provider if they added or changed some load balancing in the past 2 weeks.