Slave Server for my virtualmin

Submitted by technicaladmin on Tue, 10/20/2009 - 17:52

I have setup a Webmin Server for a slave DNS server to my Virtual min. When I go to the Webmin Servers Index and add the server its says: Server status Timeout connecting. When i go to the Webmin Log file on my Virtualmin Server it says: Error: Failed to connect to ns3.edatactr.com:10000 : Connection timed out This does not make any sense because the are on the same network and they can both ping each other throught both the DNS name and the ip address.

Status: 
Closed (fixed)

Comments

Submitted by JamieCameron on Tue, 10/20/2009 - 20:05

Check that there is no firewall on the slave system blocking ports 10000 to 10010 , or blocking connections from the master system's IP address. Virtualmin uses that port range for the RPC calls for setting up slaves..

Submitted by technicaladmin on Wed, 10/21/2009 - 07:32

I have checked that too. I have added a rule for 10000 to 10010 and even added a temporary rule for everything from the Masters IP address.

Submitted by JamieCameron on Wed, 10/21/2009 - 12:16

If you SSH into the master system and run a command like :

telnet slaveserver 10001

what output do you get?

Submitted by technicaladmin on Wed, 10/21/2009 - 13:34

This is what i get

Trying XX.XX.XX.XX... telnet: connect to address XX.XX.XX.XX: Connection timed out telnet: Unable to connect to remote host: Connection timed out

Submitted by JamieCameron on Wed, 10/21/2009 - 13:39

Ok, that timed-out message means some kind of firewall is blocking the connection. Assuming there is nothing on the slave system blocking port 10001, could there perhaps be a firewall or router on the network that is doing it?

Submitted by technicaladmin on Wed, 10/21/2009 - 13:46

That does not make any sense when they are on the same subnet on the same switch with the same VLAN. If I do a telnet localhost 10001 on the slave I get: Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused telnet: Unable to connect to remote host: Connection refused Could something not be running on the slave?

Submitted by JamieCameron on Wed, 10/21/2009 - 13:48

The "connection refused" is expected, as the slave Webmin doesn't open port 10001 until need ..

What is the output from iptables -L on the slave system?

Submitted by technicaladmin on Thu, 10/22/2009 - 12:20

here is the output

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere            icmp any
ACCEPT     esp  --  anywhere             anywhere
ACCEPT     ah   --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere            udp dpt:domain
ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTAB                                                 LISHED
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:f                                                 tp
ACCEPT     tcp  --  208.91.88.0/21       anywhere            tcp dpt:ssh state N                                                 EW
ACCEPT     tcp  --  c-98-251-25-238.hsd1.ga.comcast.net  anywhere            tcp                                                  dpt:ssh state NEW
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:h                                                 ttps
ACCEPT     tcp  --  anywhere             anywhere            tcp dpts:ndmp:10010                                                  state NEW
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:5                                                 900
ACCEPT     all  --  noc03.edatactr.com   anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:rxmon state                                                  NEW
REJECT     all  --  anywhere             anywhere            reject-with icmp-ho                                                 st-prohibited
ACCEPT     all  --  anywhere             anywhere

Submitted by JamieCameron on Thu, 10/22/2009 - 12:33

That almost looks OK .. but I see that the rule to allow ports 10000:10010 only accepts NEW connections. Make sure that when you edit that rule in the Linux Firewall module, the "Connection states" is set to "Ignored".

Then click "Apply Configuration"..

Submitted by technicaladmin on Thu, 10/22/2009 - 13:57

I have changed the Connection State to Ignored and applied the firewall. That did not make a difference.

Submitted by JamieCameron on Thu, 10/22/2009 - 14:58

Could you attach the output of the iptables-save command? It displays more than iptables -L ..

Submitted by technicaladmin on Thu, 10/22/2009 - 17:33

here is the iptables -L output

Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp
ACCEPT tcp -- 208.91.88.0/21 anywhere tcp dpt:ssh state NEW
ACCEPT tcp -- c-98-251-25-238.hsd1.ga.comcast.net anywhere tcp dpt:ssh state NEW
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https
ACCEPT tcp -- anywhere anywhere tcp dpts:ndmp:10010
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:5900
ACCEPT all -- noc03.edatactr.com anywhere
ACCEPT tcp -- anywhere anywhere tcp dpt:rxmon state NEW
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT all -- anywhere anywhere

Submitted by JamieCameron on Thu, 10/22/2009 - 18:37

Ok, so ports 1000 to 10010 are now clearly allowed..

If you try running telnet slavesystem 10001 again now, what output do you get?

Submitted by technicaladmin on Fri, 10/23/2009 - 08:08

Still no connection :(

telnet xx.xx.xx.xx 10001 Trying xx.xx.xx.xx... telnet: connect to address xx.xx.xx.xx: Connection timed out telnet: Unable to connect to remote host: Connection timed out

Submitted by JamieCameron on Fri, 10/23/2009 - 11:27

That's really odd..

At this point, I'd have to login to the master and slave systems myself to see what is going.

If that is possible, email me at jcameron@virtualmin.com

Submitted by technicaladmin on Fri, 10/23/2009 - 11:55

Well I have installed another duplicate server with the same configuration and it seems to not have any issues of the other. I can give you acces to the server having the issues or we can just close the case based on the fact that I have created a new server that does not have any issues.

Submitted by JamieCameron on Fri, 10/23/2009 - 15:26

I'd be happy to login to the problem server .. or if everything is working for you now, we could just close the issue..

Submitted by technicaladmin on Mon, 10/26/2009 - 09:52

I have reinstalled the server and it is fine. Lets just close the case. Thanks for all your help.

Submitted by Issues on Mon, 11/09/2009 - 17:19

Automatically closed -- issue fixed for 2 weeks with no activity.