I'm so close, yet so far: please help me with getting my server online! :)
 

Please note: this is a sort of follow-up thread to 4781298. It would be a good plan to read where things stand there, then continue on to reading this post.

---

Done? O.K. Here's the situation now:

I'm not well-versed enough in ping-ese (or perhaps traceroute-ese?) to be able to glean much information from that post re what I should do next to get the server online, so I thought I'd post it here (but in the right section this time!).

My question is simple: "Where do I go from here?"

I do have Xfce 4.8 (stock Xubuntu, more or less) installed on the server, so GUI diagnostic routes will work as well as anything requiring Terminal from a practical point of view.

Any further information that is needed, I will supply to the best of my ability.

*The primary access URL is 'rain.solitary.org'; I did some Apache tweaking, so rain.solitary.org's files should be being pulled from /home/usr01/public_html/rain.solitary.org/, if that helps.

Lets have a quick fact-check

- Ping shows that your IP is accessible from the internet. This is good.
- Traceroute bombs out, which I find is a depressingly common occurrence. From the output it looks like Cox is masking their network since that is the last visible hop.
- Browsers can't connect to your site.
- NMap isn't finding any open ports

So IF you are convinced the web server is running, and you've properly done any necessary port forwarding on your LAN (if needed), then the most likely explanation is that Cox is blocking port 80 and port 443. If they are doing that, the only option you've got is to run Apache on a higher port and see if that works.

O.K., I am sure the web server is running as I can still access the files via a browser from a computer on my home's wireless network (img).

*edit* The screen capture was sourced from a copy of the index.html page that had been up (on my screen) all night. Upon attempting to reload the page, I am suddenly greeted with:

I wonder why that could be? I don't recall doing anything with it overnight. I'll probably have to check that out.

Would it be worth it to ask someone from Cox if they're blocking 80 and 443? I called them before I undertook this project and the person I spoke with assured me it would be fine to run a web server using their service.

With regards to port forwarding, I honestly have no idea how to move Apache's ports to something other than 80 and 443 - is it a fairly easy task? I'm guessing it has something to do with httpd.conf, perhaps?

I blundered my way through setting up a static IP (current configuration) - DNS1 static listed here, but I'm unsure as to whether I set it up correctly as I have almost no experience with this sort of thing! I then proceeded to follow the guide from PortForward.com on port forwarding for Apache (link) and ended up with this as a result. Is there some obvious flaw in that area that could be causing problems

*a digression: I apologize for my complete lack of knowledge on anything relating to networking; I've never been in a situation where I needed to know how to properly forward ports before, so I'm pretty much learning as I go along.*

Now, if you'll excuse me, I am off to go through the joyous Cox Communications phone tree to attempt to establish whether they've blocked 80 and 443. Oh, the joy! :)

Thanks very much for your help thus far, Hangdog42. It is very much appreciated.

What fun it is to call technical support on a Sunday.

I spent approximately 45 minutes on hold calling my local Cox office, only to be told at the end that they were, in fact, closed.

:banghead:
:banghead:
:banghead:

The friendly mechanical on-hold lady transferred me to what I assume is/was Cox Communications Support Headquarters, which - she assured me in her warm robotic tone - would be able to help me soon.

Fifteen minutes later, I gave up - unwilling to spend any more of my Sunday morning listening to profound proclamations of the brilliance of the "Cox Interactive Billing Experience" (!!!)

So that's where things stand at the moment. ;)

How is your network at home setup? I noticed you said "wireless" network. Do you have a cable modem and then a wireless router?

The computer you have setup with the web server, is that have a wired connection?

Can you ping from the server out to say yahoo.com?

Is the web server plugged straight into the cable modem?

If it is plugged straight on the cable modem, sometimes you have to restet the cable modem to get it work with the new IP.

Try setting the webserver to use DHCP from the cable modem.

reset the web server and then reset the cable modem.

Hope that helps.

Report back.

The only reason that Cox would block these ports is to prevent someone from running a server. This isn't all that uncommon, if you check your TOS, there probably is a clause about not allowing a server. Cox will probably quite happily sell you a business level account if you want to be completely legit. Personally, I think it stinks when ISPs block ports, and if you call and ask, they'll tell you no (and then try to sell you the business account).

Actually, Apache has nothing to do with port forwarding, this is a function of your LAN. From your description, I'm assuming that you have a router and your server is attached to that router. If your setup is differernt, the following explanation won't make sense (and then please describe how your network is set up). Traffic coming in from the Intertubes is first hitting your router, and you have to tell your router to send packets attempting to get to port 80 to your web server. Different routers have different ways of doing this, but most have some way to do it via their GUI controls.

By the way, if your server is attached to your router and you haven't forwarded from your router to your server, that would also explain why nobody can access your server (and it is possible that Cox isn't blocking ports).

Thank you, both.

edit: my apologies for the slightly strange formatting of this post. In order to address your comments on a point-by-point basis, I relied on the CODE tag. It isn't a perfect approach, but it made sense at the time.

Oops, missed that you had addressed port forwarding. That looks right and should work (provided of course that you've locked down the LAN IP of your server). So I'm guessing we're back to Cox potentially blocking port 80. One test to try is to change the port forwarding on your router from 80 to a high port like 4080 or 10080. So on your router the external port would be 4080, but the internal port would remain 80. If that allows a connection (http://184.187.181.38:4080) then Cox is definitely blocking 80.

O.K., so you are recommending that the Externet Port be set to 4080 but the Internet Port be left at 80, like this? Or should they both be set to 4080?

The picture is right. You're not messing with Apache at all, so it should still be listening on 80.

So does this setup require those wanting to access files on the server to be directed to http://184.187.181.38:4080 as opposed to http://184.187.181.38? I am entirely fine with that, but want to make sure.

Yes, that would be right. Alternatively, you can use a DNS service like dyndns or no-ip, I think those allow you to set up a port so that users don't have to worry about it.

I use Cox. The Cox terms of service for home internet in my part of the world specifically state "no servers."

http://ww2.cox.com/aboutus/hamptonroads/policies.cox

See item 5.

I suggest you check your terms of service and I suspect they will say the same thing.

If you want to try to get around that, you could try using a non-standard port or upgrading to business class; Google will help you with the non-standard port thingee. But you do so at the risk of losing your connectivity.

Yes, this is the preferred way. And I think you get a dedicated IP with it, but it's been years since my adventures and arguments ("everything on the 'net is a 'server'). Non-standard ports are a common workaround. :)

Yes, the terms of service in my area do have an identical prohibition of servers. However, I am fairly sure that I am working with a business-class plan, as the service was purchased for use in a home office with multiple coworkers by my father. As I previously mentioned,

I'll consult Cox re the dedicated IP question when I can. That's an interesting tidbit.

I still haven't figured out why I suddenly cannot access the server within the network which the server is connected to. That issue only surfaced on Sunday morning, but I do not have physical access to the server and will not until Tuesday evening. Once I return, I will begin working to establish the cause of that problem. Until then, anyone with further thoughts: chime in! :)