Portal Home > Knowledgebase > Articles Database > Webmin Becoming Inaccessible
Webmin Becoming Inaccessible
| Posted by ssj4gogeta, 01-21-2007, 12:55 PM |
| Can any one help me with this problem I am having, every now and again Webmin seems to become inaccessible eg. when I go to http://mydomain.com:10000 it just sits there and eventually times out with a "The connection has timed out" error.
But if I use lynx from the server to access http://mydomain.com:10000 it works fine, does any one have any ideas what could be causing this, if I restart the server it then starts working fine again.
|
| Posted by FirmbIT, 01-21-2007, 01:28 PM |
| Do you have a firewall running on the server? Also, is the daemon running at these time?:
ps aux | grep webmin
|
| Posted by ssj4gogeta, 01-21-2007, 01:52 PM |
| I am quite sure that there is not a firewall running on the webserver unless webmin installs and configs one automatically I have defiantly not set one up.
The result of ps aux | grep webmin is
root 2695 0.0 0.4 7840 5148 ? Ss Jan20 0:00 /usr/bin/perl /usr/libexec/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 14085 0.0 0.0 5460 652 pts/1 R+ 11:49 0:00 grep webmin
so yea it is running I have tried restarting webmin but it makes no difference.
|
| Posted by FirmbIT, 01-21-2007, 01:57 PM |
| Any messages in the logs regarding webmin?
tail -300 /var/log/messages | grep webmin
tail -300 /usr/local/apache/logs/error_log | grep webmin
|
| Posted by ssj4gogeta, 01-21-2007, 02:13 PM |
| nope nothing in the logs about webmin.
I think I might have found what the problem is there is a log file called apf_log.1
Jan 21 04:02:25 ares apf(8852): {glob} opening inbound icmp type 11 on 0/0
Jan 21 04:02:25 ares apf(8852): {glob} opening inbound icmp type 0 on 0/0
Jan 21 04:02:25 ares apf(8852): {glob} opening inbound icmp type 30 on 0/0
Jan 21 04:02:25 ares apf(8852): {glob} opening inbound icmp type 8 on 0/0
Jan 21 04:02:25 ares apf(8852): {glob} resolv dns discovery for 10.0.80.11
Jan 21 04:02:25 ares apf(8852): {glob} resolv dns discovery for 10.0.80.12
Jan 21 04:02:25 ares apf(8852): {glob} loading postroute.rules
Jan 21 04:02:25 ares apf(8852): {glob} default (egress) output accept
Jan 21 04:02:25 ares apf(8852): {glob} default (ingress) input drop
Jan 21 04:02:25 ares apf(8816): firewall initalized
would that be causing the problem.
Last edited by ssj4gogeta; 01-21-2007 at 02:26 PM.
|
| Posted by wikki, 03-15-2012, 12:36 PM |
| Hello,
I was having the same problem; I did everything by the book, opened the port 10000 but was still seeing connection timeouts whenever I tried to access webmin externally on the WAN; (and offcourse it was working fine with iptables being stopped.
I finally nailed the issue, the problem was due to the exception rule being added after the deny-all rule; please check the output of the iptables -nL below;
====
Webmin NOT WORKINg
====
[root@dls ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:2049
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:137
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:138
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:139
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:445
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:23
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited =====
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000 state NEW ====== This was the problem.
[root@dlsq ~]# service iptables stop
Flushing firewall rules: [ OK ]
Setting chains to policy ACCEPT: nat mangle filter [ OK ]
Unloading iptables modules: [ OK ]
=========
WebMin WORKING Fine now
=========
[root@dlsq ~]# iptables -nL
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255
ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0
ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:25
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:2049
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:137
ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 state NEW udp dpt:138
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:139
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:445
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:23
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000 state NEW
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited => moved this rule to the END
Last edited by wikki; 03-15-2012 at 12:40 PM.
|
Add to Favourites 
Print this Article
Also Read
disable NDR (Views: 771)