Webmin Access Unresponsive Even After Restart

13 posts / 0 new
Last post
#1 Sun, 02/09/2014 - 21:06
katir

Webmin Access Unresponsive Even After Restart

Attempts to access the control panel at https://our.hostmachine.org:10000

are failing.

I restarted webmin on the box via ssh: /etc/init.d/webmin restart

I got the prompt back with no errors reported and no status reported. I assume it restarted (but I don't know enough to investigate further. But if I run top, I see the occasional python process kicking off mailman... I believe this is Virtual min (not sure really as we don't use mailman at all)

In Fire fox I simply get this (see below). Perhaps it is a DNS issue?

What are the next step to trouble shoot this?

The connection was interrupted

The connection to sat.gurudeva.org:10000 was interrupted while the page was loading.

The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer's network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.
Mon, 02/10/2014 - 09:03
andreychek

Howdy,

The Mailman/Python processes you're seeing aren't related to Virtualmin... that's all part of the Mailman service, which is one of the Virtualmin dependencies that's installed during the Virtualmin installation process. But seeing that running doesn't mean Virtualmin is running.

One way to tell if Virtualmin is running is to use netstat to see if anything is listening on port 10000:

netstat -anlp | grep :10000

Try accessing port 10000 in your browser by using the IP address, rather than a domain name, and see if that does the trick.

-Eric

Mon, 02/10/2014 - 12:04
katir

Netstat returns:

[root@sat ~]# netstat -anlp | grep :10000 tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 1781/perl
udp 0 0 0.0.0.0:10000 0.0.0.0:* 1781/perl

So, since I think VirtualMin is written in perl that means at least it is listening on port 10000.

using the IP I gets the same behavior: no response.

What next?

Mon, 02/10/2014 - 12:21
andreychek

Yeah, that definitely appears to be listening.

Is your server on a LAN, and are you also accessing it from the same LAN? That kind of setup could cause the issue you're seeing -- if that's the case you may want to use your server's internal IP address.

Also, is there a firewall setup on your server that might be blocking it? You can determine that by running "iptables -L -n".

-Eric

Mon, 02/10/2014 - 13:56
katir

It's not on our LAN here here in Hawaii, its in GoGrid's data center in San Francisco (Formerly "ServePath)

IPtables are showing

ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:10000 ACCEPT tcp -- 72.253.171.24 0.0.0.0/0 tcp dpt:10000 ACCEPT tcp -- 75.109.138.39 0.0.0.0/0 tcp dpt:10000

hmmm... we just got a new internet connection and the above IP's are from our old gateway here... But this doesn't make sense.. my developer in Brazil has authorization to use our control panel and he's always roaming down there, so his IP is always changing. But we are not block 10000 explicitly in the firewall/iptables.

Mon, 02/10/2014 - 14:25
andreychek

Hmm, could you show the full output of "iptables -L -n"?

It sounds like you may be dealing with a firewall issue of some sort, seeing the full output would help with the troubleshooting of that.

-Eric

Mon, 02/10/2014 - 14:42
katir

Full output below... but I changed nothing recently... other than to run yum updates. I will put a ticket into ServePath/GoGrid and see if they implemented anything farther out from our box...

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:20
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:21
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8333
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8444
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:20
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:53
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
DROP       all  --  0.0.0.0/0            0.0.0.0/0           state INVALID
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0          
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:443
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:8080
ACCEPT     tcp  --  67.52.81.242         0.0.0.0/0           tcp dpt:25
ACCEPT     tcp  --  72.253.171.24        0.0.0.0/0           tcp dpt:25
ACCEPT     tcp  --  67.52.81.242         0.0.0.0/0           tcp dpt:21
ACCEPT     tcp  --  72.253.171.24        0.0.0.0/0           tcp dpt:21
ACCEPT     tcp  --  67.52.81.242         0.0.0.0/0           tcp dpt:587
ACCEPT     tcp  --  72.253.171.24        0.0.0.0/0           tcp dpt:587
ACCEPT     tcp  --  67.52.81.242         0.0.0.0/0           tcp dpt:10000
ACCEPT     tcp  --  72.253.171.24        0.0.0.0/0           tcp dpt:10000
ACCEPT     tcp  --  75.109.138.39        0.0.0.0/0           tcp dpt:10000
ACCEPT     tcp  --  67.52.81.242         0.0.0.0/0           tcp dpt:20000
ACCEPT     tcp  --  72.253.171.24        0.0.0.0/0           tcp dpt:20000
ACCEPT     tcp  --  67.52.81.242         0.0.0.0/0           tcp dpt:5432
ACCEPT     tcp  --  72.253.171.24        0.0.0.0/0           tcp dpt:5432
ACCEPT     tcp  --  67.52.81.242         0.0.0.0/0           tcp dpt:3306
ACCEPT     tcp  --  72.253.171.24        0.0.0.0/0           tcp dpt:3306
ACCEPT     tcp  --  174.59.203.162       0.0.0.0/0           tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:30000
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpts:1:65535
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:1:65535
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0          

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination  
Mon, 02/10/2014 - 15:21
andreychek

Howdy,

Well, I can't speak to why your developer from Brazil is able to access the system... but I can offer that, according to the firewall rules you're using above, all access to Webmin/Virtualmin is being blocked, unless it's coming from one of three IP addresses.

There's fancy SSH tunnels and such that your developer could by using to bypass the firewalling you have there.

My recommendation would be to make sure there's a firewall rule on your system explicitly allowing your IP address.

Or, to allow all access to port 10000.

-Eric

Mon, 02/10/2014 - 16:19
katir

OK, this makes sense now... we recently got a shiny brand new internet connection and I suspect the IP's changed for outgoing and our local net/LAN admin did not tell me.

so what is the proper way to edit the iptables by hand via terminal? Can I just VIM on some file and save it?

Mon, 02/10/2014 - 16:32
katir

OK that was easy... I did a look up for our domain from outside, got the IP...

nano iptables,

changed it then ran

service iptables restart

and I'm in.

thanks!

Odd.. when I edited the table I see my comments right there:

for access from to webmin from our gateway:

ACCEPT tcp -- 67.52.81.242 0.0.0.0/0 tcp dpt:10000

but when I did

iptables -L -n

it does not show comments..

Case closed....

Mon, 02/10/2014 - 19:54
Locutus

Iptables itself does not retain those comments, they're only in the configuration script you've been editing.

Mon, 02/10/2014 - 20:41
katir

That would explain it -- not that I really understand how "nano iptables" is not actually editing "iptables" unless the latter is some binary thing that is not actually exposed in /etc/sysconfig (just guessing)

Tue, 02/11/2014 - 04:26
Locutus

Yeah I can't really tell how the nano command knew what file to edit. But what I know is that "nano" is a text editor, and "iptables" indeed is a binary (which you therefore cannot edit per se), which usually has a startup script to configure it.

Topic locked