whats with these apache servers?

[CentOS]

Check the ifcfg-eth0 settings and have them comment out the "NETWORK" entry if it exists.

Don't think it's an ifcfg issue because it works internally. It's more likely a NAT issue. And it's really easy to confirm if it is.. just put it outside your network, if it works, then they're really isn't any problem with your apache.

Since you can't access the server remotely, have someone send you the logs by email nalang. When I have server issues, the first thing I really look at are the logs, before I even touch other things.

[BeoR]

If you have the network directive under your network settings it will limit traffic only to that network. Put NETWORK=192.168.1.0. It will work on the internal network but it won't work externally. There are other possible causes and NAT is one of those, another would be IPTables config... there are a lot of possibilities. Logs would help I agree.

[r0mm3L]

so is this something that we need to concentrate on the linux side?

and we can safely say that there's no issue on the firewall?

[softtouch]

Just to make sure: Are the required ports opened?

[r0mm3L]

of course

i guess there's no problem with the confg on the firewall, naka lusot na gani, pero ang server it seems di mo tubag

mura sya windows desktop nga naka enable nga firewall nga software (for example trend micro), ang firewall (hardware) mo log nga naay packet na sent gikan sa gawas, but walay reply coz ang pc miss mo ni drop sa packet coz naka enable ang trend micro nga firewall

[MarkCuering]

Hoy!!! Rommel Alastra! Wala pa jud na bai? Hehehehe…

Bitaw, in your first post, you did mentioned that you can’t forward PORT from OUTSIDE to INSIDE. Is it correct to assume that you are at OUTSIDE (cebu) to INSDE (davao)? Primarily, two sites are involved here.
Moreover, you are trying to use the WEBSERVER from Davao in your location (Cebu) using the known Public IP ADDRESS /PORT in davao.

So to draft this one:

Cebu_Network -------- WAN -------- Davao Network (Webserver/Linux)

If the above assume data is correct, you have to deal first how the two networks being setup especially on the FIREWALL issues.
But knowing that the Websever ( Davao_Network) is up and running.

WAN ------ [ROUTER] -------- [LINUX (Apache Server installed)]

You can verify this without passing any NAT tables in your local network in accessing DAVAO (in case it’s already serving)

FIREWALL in Davao should not be an issue, especially if it is responding from its client (public), which unfortunately service to CEBU_NETWORK is failed.

Again I hope all my assumption is correct.
By the way, try to consider the loopback (Router settings) if it is ON. No matter how successfully you send from other network (WAN), still you won’t be able to communicate back to your PC, it may reach back to your NETWORK but not to the specific PC you’re using.

One thing, remote desktop you’ve mentioned here is operating locally, which does not need any translations,unless you have several networks (in CEBU).
lets say: you trying to remote 172.25.6.198 from 172.25.3.1 (need NAT)
remote 192.168.1.232 from 192.168.1.x (why need NAT?)

PM mo daw sakin mga IP’s (public) nito.
Back di ako makareply agad, sa YM nalang.

[CentOS]

If you have the network directive under your network settings it will limit traffic only to that network. Put NETWORK=192.168.1.0. It will work on the internal network but it won't work externally.

Hmm.. that's kinda weird, and it's actually the first time i've heard of that. I've had quite a few masqueraded boxes, and although the NETWORK directive has never been something I would bother looking at because it is normally deprecated, i've seen boxes wherein they're actually set (specially if your using static IP) and they've never been an issue. It's just a typical setting that NIC's have and in fact, we don't always see it because icalc automatically computes it.. and although we don't see it, it's still there (when you do a ifconfig). NETWORK only becomes an issue when you're using DHCP, you have to leave it blank or comment it. It's basically the same as the BROADCAST directive.

Anyway, that is something new to me. I'll see if I can tinker around with some of my boxes.. but I swear it's never been an issue.

so is this something that we need to concentrate on the linux side?

and we can safely say that there's no issue on the firewall?

Like we said, we can only tell from the logs on the apache.

[BeoR]

True, it is deprecated or it should be. Sometimes weird things happen plus the fact that we don't know the distribution and version of what they are using. Again it is a possibility and you can try it yourself. Tried it with iSTORYA to be sure as it is almost the same scenario (we are behind a firewall)... and as expected, it became inaccessible. I don't know with other distributions, but that's what happens with Redhat / CentOS.

Hmm.. that's kinda weird, and it's actually the first time i've heard of that. I've had quite a few masqueraded boxes, and although the NETWORK directive has never been something I would bother looking at because it is normally deprecated, i've seen boxes wherein they're actually set (specially if your using static IP) and they've never been an issue. It's just a typical setting that NIC's have and in fact, we don't always see it because icalc automatically computes it.. and although we don't see it, it's still there (when you do a ifconfig). NETWORK only becomes an issue when you're using DHCP, you have to leave it blank or comment it. It's basically the same as the BROADCAST directive.

Anyway, that is something new to me. I'll see if I can tinker around with some of my boxes.. but I swear it's never been an issue.



Like we said, we can only tell from the logs on the apache.

[sploy]

clarify lng pud ko.... unsa diay imo gamit na NATing? is it Static NAT gyud or PAT ra??

Kay ug Static NAT gyud, you should have no problems with the port forwarding since the router automatically forwards all traffic (regardless of port number) requested on its PUBLIC IP to the LOCAL SERVER (in this case is the Apache Server)...

while in PAT, mag specify man gyud ka ug port numbers...

[CentOS]

True, it is deprecated or it should be. Sometimes weird things happen plus the fact that we don't know the distribution and version of what they are using. Again it is a possibility and you can try it yourself. Tried it with iSTORYA to be sure as it is almost the same scenario (we are behind a firewall)... and as expected, it became inaccessible. I don't know with other distributions, but that's what happens with Redhat / CentOS.

Also tried it yesterday with one box, didn't actually make any difference. The distros I normally run are Redhat, CentOS (most of my servers), Slack and Fedora. And in the box I tested it on, it's a CentOS behind a Slack firewall using iptables and can't seem to replicate your problem.. well, weird. Anyway, it might be possible.. everything is

May I know what version of Cent you tried "ISTORYA" on? I'll do a ground up installation using the same version you have and see if I would have the same problem.