0

I have quite a strange situation and hope you can help me figure it out.

I am running a student server that is hosted by my school. We have our own public IP address on the net, and I was told once that we are on the DMZ of their network. Our server runs Ubuntu 8.10 LTS with the standard LAMP packages.

My problem is that all requests addressed to those other servers the school owns and hosts systematically time out from our server. For instance; with wget, it resolves, tries to connect, and times out. Same thing with fopen() on php, or when I try to browse a website through a proxy configured on the server. However, all those resources (the one I try to retrieve with wget for example) work perfectly fine when accessed from home, which would rule out a firewall system on their side. And I also ruled out a firewall on our side since wget google.com works perfectly fine.

I know we've been experiencing some DNS issues, but resolving seems to work. So what could be the problem in your opinion? My guess is it has something to do with the network, but that's beyond my comprehension. I'd like to try everything I can on my side before bothering the sysadmins on the other side...

Thanks very much for any help!

EDIT:

  • dig and nslookup work fine
  • using ip instead of domain name makes no difference
  • I have no visibility over the other servers, but since they are fully accessible over the net, I should be able to do so as well, no? Furthermore, this problems seems new, as it used to work a year ago... Can I force access through a different route?

FIX:

  • Just to give you the heads up, after sending a mail to the sysadmins, it took them approximately 10mins to "do something" and inform me that their firewall rules had been wrongly implemented when migrating last summer. Everything works fine now.
Improve this question
3
  • Last year doesn't mean things weren't changed or upgraded over the summer (school = public school or college?) And no, just because it works over the internet doesn't mean it's not blocked from the DMZ block. routers/firewalls can be set to block specific blocks of IP's and someone may have just blocked the DMZ from getting into the school network on a lark while configuring things.
    – Bart Silverstrim
    Sep 14, 2010 at 11:58
  • yeah, it's a business school, and I know for a fact they did some rework to their NT this summer. I can't see why they would have blocked our internet IP block, though, but I just emailed a sysadmin, coz I do beleive that is the problem. Thanks for your help anyway!
    – damusnet
    Sep 14, 2010 at 12:04
  • I also edited my answer a little in case it didn't tell you with what it sounds like to me. And forcing through a different route is a band-aid that will cause more troubles in maintenance down the road. Don't do that. Instead work with your school sysadmins to get it taken care of properly. It should be something simple like changing some firewall rules if that's all it is.
    – Bart Silverstrim
    Sep 14, 2010 at 12:06

1 Answer 1

Reset to default
1

if dig and nslookup work, then you're resolving to your DNS server fine.

Are the other servers you mention also in the DMZ or are they being port-forwarded from their firewall inside the network?

Is there a difference between accessing them by name (involving their DNS servers) and accessing by IP (bypassing the DNS server)?

It's possible that they isolated your server in the DMZ to the point where it's not able to access their servers to help protect other systems in case your system was hacked.

It doesn't necessarily rule out the firewall. They may have firewall rules that are blocking your server's IP block while allowing internet-facing systems in (doesn't necessarily make sense, but doesn't mean that wasn't what was configured).

You'll need to talk to your school's sysadmins to see how things were configured. It sounds to me like a router or firewall configuration issue.

Improve this answer
1
  • thx for your answer! I edited my question to take it into account.
    – damusnet
    Sep 14, 2010 at 11:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .