Where did my Virtual Servers go?

Let’s start back a day or so ago. I attempted to set up a firewall using the Linux Firewall module. I started out with the option to block all but the ports needed for virtual hosting as I have several virtual servers set up.

All seemed to go pretty smooth there, but then I attempted to access the website on one of them. No go. I checked port 80 and it showed open,same with 443 and 53 was good to go too. I had some other business to attend to so I just reset to open all ports for the time being.

Today I get back to it and attempt it once again. Still no joy. So I attempted again, this time using a different option and was going to manually set the ports up that I needed open. I got it all set up (or so I thought) and clicked apply and suddenly remembered I had not opened port 10000 for Webmin, and stupidly clicked to stop the browser. Too late, it had closed all ports. I contacted my host and got the iptables flushed.

I thought all was good, but now I cannot access any virtual servers nor the FQDN. I can only access the doc root using the IP addy. I checked to be sure etc/hosts is still intact and it is. A peek at the apache error log says NameVirtualHost *:0 has no VirtualHosts. I look in the sites_enabled folder at the default and it shows NameVirtualHost with the correct IP:80 and it matches the <VirtualHost IP:80>. All the virtual servers are listed in there as well.

What am I missing here?

I think you host may have flushed a little more than just the IP tables…

Sounds like now is the time to pat yourself on the back for making use of Virtualmin’s Backup and Restore features.

You do have backups, right? I hope?

in addition, a firewall on a virtual server is rather pointless as your host is taking care of that part.

per haps if the virtual server is Xen based you could make some of it work for you.

Oh the files for the virtual servers are there and I do have backups anyway, but they just don’t show up when I try to access them thru the domain names. I seems to me to just be a mapping problem, but I can’t figure out where the problem lies.

The host is not firewalling my server, that’s why I wanted to set this one up on my end. It just never worked properly from the start. Anyway, it’s not a firewall problem as I can nmap from my home pc and it shows the ports open. Further, I can run tcpdump on port 80 using the IP addy and see the 3-way handshake happening just fine. It’s only when I use bricohosts.com (or any other domain name) on port 80 that I get nothing.

Actually, firewalls are generally altogether pointless in a virtual hosting environment, except for very specific purposes. The ports that have services running on them (HTTP, DNS, SMTP) can’t be firewalled…if it could, you’d just turn off the service.

So, the specific reasons you’d want a firewall:

Preventing access to a database that has to be network accessible for some of your other servers. So, you lock it down to only those IPs in your cluster.

Block problem IPs. If you get constant scans from a particular IP, shut it down. There are tools to automated this…fail2ban, etc.

And, maybe, protect services that expose potentially serious issues…like ssh. If you have users that don’t use strong passwords, it may be worth implementing a set of stateful rules to help prevent brute force attacks. There was a great thread on this topic a couple of years ago here:


I just made it sticky, since it comes up quite a bit.

But that’s about it. No other reason to have a firewall on a hosting server…it doesn’t do anything. You can generically block all ports that don’t have anything running on them, which achieves exactly nothing. If the port has no service on it, why block it? There’s nothing there to attack.

But, anyway, back to the problem at hand:

Oh the files for the virtual servers are there and I do have backups anyway, but they just don't show up when I try to access them thru the domain names. I seems to me to just be a mapping problem, but I can't figure out where the problem lies.

Well, you mentioned this above:

A peek at the apache error log says NameVirtualHost *:0 has no VirtualHosts.

Which tells me that maybe there’s a rogue bit of configuration in there somewhere…you don’t want a “NameVirtualHost *:0” directive in a virtual hosting system. It’ll break everything (unless you really know what you’re doing, but it provides no benefits, so get rid of it).

I dunno where that configuration is sneaking in from…but it needs to go away. Use grep in the Apache configuration directory to see if you can find out where it’s coming from.

I found the culprit causing the NameVirtualHost *:0 in the log. It was in the default server configuration before the NameVirtualHost IP:80 entry as NameVirtualHost *. I deleted that and apache hasn’t logged it since.

I have come to the conclusion that the problem lies with the registrar formy FQDN. I contacted them and asked them to check why Dig shows it going to an unknown IP. They say they are looking into it. We’ll see.

Thanks for the replies. It’s good to know there’s help available even though my problem doesn’t actually relate directly to your fine product.

I’m baaack!

It now seems the problem does indeed lie with my server. I used DSN Report and it comes back with "Name Servers not responding."

Is there possibly a port blocked to BIND? What IS the port for the name server? What else might be causing the name server to be unreachable. The set up all looks fine.

Do you get this fixed?

Port 53 is used for DNS/Bind. However, UDP is the default, and TCP is rarely used. So you need to make sure you open port 53 UDP.


I did indeed get it fixed. I had several network gurus working on it and they worked all day to find out that I had a little old comma in a place where it was not supposed to be in the named.conf.options file. Removed it and all worked fine as long as I left the firewall down. For some reason when I set it up using the last option (block all ports but what is needed for virtual hosting…) it was not setting a rule for UDP/53. So, I made one using advice from a google search and it was wrong too cuz it said to restrict it to my IP. Bad move. When that didn’t work, I thought, well, I guess I shouldn’t open that port. It wasn’t until later that I used port ranging to narrow it down that I realized I do need to open it and NOT restrict it to my IP.

After a week of panic, and customers wearing my personal email box out, all is well again at bricohosts.com.