Virtualmin Behind a Firewall?

16 posts / 0 new
Last post
#1 Fri, 07/06/2007 - 02:18
Johnny Stork

Virtualmin Behind a Firewall?

I currently have a server running behind a netgear fvs124G firewall and its running a single web site, which I port forward port 80 traffic at the firewall, internally to the server, which has an internal ip of 192.168.1.2. What would be the suggested way in which to assign one of my public ip address to this internal server, so that it can remain behind the firewall, but receive all traffic coming in to the public IP? Or do I need to place this server in front of the firewall and connect it directly to the internet connection and run its own firewall? I would rather keep it behind the firewall somehow, if this is possible

Fri, 07/06/2007 - 02:20
Joe
Joe's picture

Hey Johnny,

Virtualmin has quite a few nice features for running in a NATted network like you have.

First thing would be to get the DNS records using the public IP while also getting the Apache to use the private address. You could also use the Dynamic DNS feature, if you don't want to run local DNS.

So, let's answer the first one: No, you don't need to have the Virtualmin server on the public IP, though it does make several things easier.

For the specifics of how to go about it, let's figure out the best way for you to set things up. Is this a dynamic IP (i.e. does you ISP issue a new one every time you connect?) or are you using a static public IP?

That'll determine whether you should use the dyndns feature or a local BIND instance.

If the local BIND, you'll want to edit the Module Configuration and set the "Default IP address for DNS records" in the "Other server settings" section to the public IP, and save it.

--

Check out the forum guidelines!

Fri, 07/06/2007 - 02:26 (Reply to #2)
Johnny Stork

Hey thanks for the reply. I do have a couple of static IPs and will be using one for VirtualMin Hosts. I went into the Bind configuration in Webmin, but could not locate a section for "Other Server Settings", Maybe I am looking in the wrong place. There is a "Other DNS Servers" but this does nto have a setting for "Default IP address..."

"If the local BIND, you'll want to edit the Module Configuration and set the "Default IP address for DNS records" in the "Other server settings" section to the public IP, and save it."

Fri, 07/06/2007 - 02:35 (Reply to #3)
Johnny Stork

Ah, found it. Ok I set the "Default Ip Address for DNS Records" to my primary static IP (207.216.240.xx) which port forwards all traffic to the internal Virtualmin Server on 192.168.1.2

Fri, 07/06/2007 - 03:06 (Reply to #4)
Johnny Stork

Ok I created test virtual host with one of my domains, helpingyouth.ca. Everything was created fine, and using dig on the same host as the Virtualmin server I get the correct external IP

;; QUESTION SECTION:
;www.helpingyouth.ca. IN A

;; ANSWER SECTION:
www.helpingyouth.ca. 38400 IN A 207.216.240.xx

However, when trying to get to the site I ended up at the default web site at that IP, but when I changed the virtual host setting from *:80 to the internal IP in httpd.conf, I was then able to get to the doc root of the new host.

But I do get some errors from apache when it starts (there are other virtual hosts not imported into Virtualmin, and with the same "Virtualhost 192.168.1.2" setting:

#<VirtualHost *:80>
<VirtualHost 192.168.1.2>
SuexecUserGroup "#511" "#511"
ServerName helpingyouth.ca
ServerAlias www.helpingyouth.ca
DocumentRoot /home/helpingyouth/public_html
ErrorLog /home/helpingyouth/logs/error_log
CustomLog /home/helpingyouth/logs/access_log common
ScriptAlias /cgi-bin/ /home/helpingyouth/cgi-bin/
<Directory /home/helpingyouth/public_html>
Options Indexes IncludesNOEXEC FollowSymLinks
allow from all
</Directory>
</VirtualHost>

Apache errors when starting:

Starting httpd: [Thu Jul 05 17:50:40 2007] [error] VirtualHost 192.168.1.2:0 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results
[Thu Jul 05 17:50:40 2007] [error] VirtualHost 192.168.1.2:0 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results
[Thu Jul 05 17:50:40 2007] [error] VirtualHost 192.168.1.2:0 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results
[Thu Jul 05 17:50:40 2007] [error] VirtualHost 192.168.1.2:0 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results

Fri, 07/06/2007 - 06:29 (Reply to #5)
Joe
Joe's picture

Your NameVirtualHost and VirtualHost entries must match. I suggest making them both 192.168.1.2:80.

--

Check out the forum guidelines!

Fri, 07/06/2007 - 20:30 (Reply to #6)
Johnny Stork

Ok, great, making progress here. I am now having problems with DNS. I can dig the internal server so long as I use its internal address of 192.168.1.2, but I am unable to DIG if I use the external address which is port forwarding port 53 tcp/udp to the internal virtualmin server at 192.168.1.2?

Is there a way to obtain more info to determine where/what is failing in the name server query?

I left the full ip in there so you might be able to try yourself from your end.

; <<>> DiG 9.2.4 <<>> @207.216.240.22 www.helpingyouth.ca
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 48610
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Fri, 07/06/2007 - 22:09 (Reply to #7)
Joe
Joe's picture

It looks like it's denying queries from outside your private, though it is listening. So, the firewall and port forwarding is right, but the BIND configuration isn't. Have you added any "allow-query" rules in the named.conf?

--

Check out the forum guidelines!

Sun, 06/07/2009 - 07:13 (Reply to #8)
Johnny Stork

Ahhaa...this is whats in named.conf

allow-query { 127.0.0.1; 192.168.1.0/24; };

Should I be adding the external IP?

Sun, 06/07/2009 - 07:13 (Reply to #9)
Johnny Stork

Ok, I commented out the allow_query line and it seems to have fixed it. Is that directive optional and only used if I want to restrict who can query the name server? Also, can you try www.helpingyouth.ca form you end....you should get a test page with the text "Helping Youth Home Page" if everything resolved and loaded properly.

Hopefully not too many more questions, but where can I find some docs on making the name server a complete name server and not just for the domains I host? Or is this even an appropriate question? Right now I am using it as a caching name server locally with the following options:

listen-on { 127.0.0.1; 192.168.1.2; };
// allow-query { 127.0.0.1; 192.168.1.0/24; 207.216.240.22; };
forward first;
forwarders { 192.168.1.1; 154.11.128.59; 154.11.128.187; 216.220.40.243; 205.210.42.19; };

Sun, 06/07/2009 - 07:13 (Reply to #10)
Johnny Stork

Ahhaa...this is whats in named.conf

allow-query { 127.0.0.1; 192.168.1.0/24; };

Should I be adding the external IP?

Sun, 06/07/2009 - 07:13 (Reply to #11)
Johnny Stork

Ok, I commented out the allow_query line and it seems to have fixed it. Is that directive optional and only used if I want to restrict who can query the name server? Also, can you try www.helpingyouth.ca form you end....you should get a test page with the text "Helping Youth Home Page" if everything resolved and loaded properly.

Hopefully not too many more questions, but where can I find some docs on making the name server a complete name server and not just for the domains I host? Or is this even an appropriate question? Right now I am using it as a caching name server locally with the following options:

listen-on { 127.0.0.1; 192.168.1.2; };
// allow-query { 127.0.0.1; 192.168.1.0/24; 207.216.240.22; };
forward first;
forwarders { 192.168.1.1; 154.11.128.59; 154.11.128.187; 216.220.40.243; 205.210.42.19; };

Fri, 07/06/2007 - 06:34
Joe
Joe's picture

<b>JohnnyStork wrote:</b>
<div class='quote'>Oops, wrong forum, sorry. Couldnt see how to delete the post</div>

No big deal. I moved it.

--

Check out the forum guidelines!

Fri, 07/06/2007 - 08:47
mike

well, there are 2 ways that you can accomplish your task, both without having to re-arrange your hardware.

1:) portforward more ports to the server
ftp = 21tcp
ssh = 22tcp
telnet = 23tcp
smtp = 25tcp
DNS = 53tcp/udp
http = 80tcp
pop3 = 110tcp
imap = 143tcp
https = 443tcp
webmin/virtualmin = 10000tcp
usermin = 20000tcp

open only the ones you have running and would like to be available access to the public.

2:) if you have the firewall module enabled on your server you can place the servers IP addy under DMZ on your router, DMZ stands for &quot;De-Militarized Zone&quot; in simple this is the equivelent of placeing the server in front of the firewall and connecting it directly to the internet connection and running its own firewall.

The choice between the 2 is completely up to you, but both work nicely and there is no need to unplug and plug the cable to reposition its connection in comparison to the rest of the hardware.

Fri, 07/06/2007 - 22:46
Joe
Joe's picture

Hehehe...Actually, you should be removing that line altogether, if you want everyone to be able to ask questions of your name server. queries are different from recursive lookups (which you probably do want to restrict). A query is when someone asks your nameserver, &quot;hey, do you know who this is?&quot; You want it to answer &quot;yes, it's 207.216.240.22, thanks for asking&quot;, rather than &quot;go away!&quot;

;-)

--

Check out the forum guidelines!

Fri, 07/06/2007 - 22:54
Joe
Joe's picture

There's quite a bit of documentation about BIND in the Webmin documentation wiki, here:

http://doxfer.com/Webmin/BINDDNSServer

And here:

http://doxfer.com/Webmin/CachingNameserver

And here:

http://doxfer.com/Webmin/ResolutionForVirtualHosts

And here:

http://doxfer.com/Webmin/BINDTroubleshootingTools

Of course, in your case, being a recursive name server is BIND's native habitat, so enabling it is breezy. There's a single option in the BIND module in the Miscellaneous section called &quot;Do full recursive lookups for clients?&quot; that turns it on. But forwarders, plus allowing direct lookups if the forwarders fail, is probably the right thing to do in your case. It'll probably be faster, and it'll certainly be easier on the root name servers.

--

Check out the forum guidelines!