I am currently setting up a HP ProLiant DL320 G3 with OpenSuSE 11.2. I have it hooked up to a network switch, and a machine attached to the switch as well. I installed and set up DHCP, DNS, Apache2, and got everything running fine. When I attach the machine to the switch, it gets a DHCP address, and seems to be connected fine, but if I open a web browser and go to the server’s IP address, it doesn’t find anything. It appears the client machine cannot talk to the DNS or Apache2 servers on the ProLiant. I tried SSH in the hopes that might work, and sure enough it does. I have tried disabling the firewall (its not on the internet at the moment, so this is not an issue) and that doesn’t help. I am guessing I am setting something up wrong, but I cannot figure out what is going wrong.
Is DNS working? Try with ‘dig server.domain.tld’ on the client.
I won’t have access to the server again until tomarrow afternoon, but I had tried nslookup, and it couldn’t find the dns server the dhcp specified, so I am assuming no. It is working, but the client cannot find it.
Lots of missing details there. Did you go to the IP address in the web browser rather than the domain name? How did you test DNS, with dig?
I hope you are not under the impression that just because you run a DNS service on a server, the server becomes visible to the whole world under its domain name.
I’m actually not even trying to use DNS at the moment, I’m just planning on using it in the future. I am going to the IP address. I need help figuring out why the server isn’t available on the network via IP address, not with DNS.
As I said before, if I navigate to the IP address of the server via HTTP or DNS ports, it cannot connect. But if I connect on port 22, SSH, it connects. I have the firewall disabled, and have no idea what else could be causing the issue.
Have you actually started Apache on it? Check using YaST? Unlike Debian, installing a package doesn’t automatically start a service.
And what do you mean DNS ports? Do you mean by domain name in the URL? Do you actually have a mapping from domain name to IP address, bearing in mind that it’s a dynamic IP.
Just please ignore the whole DNS thing. It is of absolutely no significance in this problem. It isn’t being used at all. I was simply saying that however DNS communicates, it is failing along with http on my network. Apache2 is running. I can get everything working locally on the server.
What happens if you use telnet to check?
telnet a.b.c.d 80
Do you get a Connection refused, or no response? Connection refused means not running, or not listening on that address+port. No response means the firewall is blocking.
Double check the IP address you are using since it’s dynamic. Also are you on the same subnet or separated by a router? Also what about the routing on the server, is it correct?
when i telnet to 80, I get no response, but the firewall is not the issue, seeing as it is disabled. The server has been assigned a dynamic IP on eth1 and has a static IP on eth0. I have tried both. There is no router. The server hosting DHCP is attached to a 3Com SuperStack 3 4400 switch, and the machine is attached to the same switch, and assigned the address by the server.
Why two interfaces? If on the same subnet you may have issues. Try having one static interface to avoid routing problems. What about the server’s routes, did you check those?
Absolutely certain the firewall is off? Try iptables -L -n.
If things get gnarly you might want to do a packet trace on the server to see if the HTTP packets really arrived.
I set up the second interface in hopes that the DHCP server listening on eth0 was the cause of the issue. I will remove it when I get a chance. How do I check the server’s routes? And yes, YaST2 reports it is diabled. Plus, even if it wasn’t, I have HTTP open.
Would a misconfigured DHCP server cause this issue? I don’t have any experience with ICS, and completely guessed as to the proper settings.
route -n
Do iptables -L -n just to double check.
I will try those when I get to the server tomarrow, and post my results then.
route -n produces
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.166.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
196.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
172.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.166.1 0.0.0.0 UG 0 0 0 eth0
iptables -L -n produces
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
I discovered it was an issue with the domain rules that the machine in question was using, and not an issue with the sever.