Apache not directing to virtual ip addresses

22 posts / 0 new
Last post
#1 Thu, 03/01/2007 - 23:03
JohnFord

Apache not directing to virtual ip addresses

Do I have to have a public IP for the virtual domains?

Apache is directing everything to the /var/www/html if it is requested by the host name.

If I request the ip 192.168.1.111 it'll give me the domain.

Virtualmin creates a incorrect netmask in the virtual eth:0/1 setting. It uses the same as the public IP. I haven't manually changed it yet as I am just now working on this problem.

See... here's what happened... I have two public ip addresses from my ISP. One has always had my old server. The other I use for a firewall proxy filter for internet access to the local net.

I took down the proxy server and set up virtualmin pro using my public ip for the proxy. It seemed smart, as I could leave up my old server and test things. Then, when finished just change the ip address of internet ethernet card to the normal one and get my proxy going again on my second ip.

If all I have to do is change the netmask, then great. But I thought I'd at least get this posted as it shouldn't be setting it up wrong.... OR.... if it's a normal thing like it is only doing what I told it, :) --- then maybe someone here will see my plight and help me out a bit.

thanks. /johnford

Fri, 03/02/2007 - 01:42
JohnFord

I think all the subnet mask settings are correct. I'm not learned on these settings.

I see that after I told virtualmin the ip range to use 192.168.1.111 thru 192.168.1.199 that it set up the eth0:1, etc to use the subnet mask for the primary gateway route. 255.255.255.224

I thought it'd be set to 255.255.255.0 which is what I use on the other ethernet card for the local net work.

I don't know why it is not working.

shouldn't it broadcast to 255.255.255.255?

I set up a host name for the virtual ip address in the hosts file and then apache will direct to the right location but it only does this on the server machine and will not service it correctly for incoming packets from the public.

any help would be appreciated.

Fri, 03/02/2007 - 10:38 (Reply to #2)
Joe
Joe's picture

<i>I see that after I told virtualmin the ip range to use 192.168.1.111 thru 192.168.1.199 that it set up the eth0:1, etc to use the subnet mask for the primary gateway route. 255.255.255.224

I thought it'd be set to 255.255.255.0 which is what I use on the other ethernet card for the local net work.

I don't know why it is not working.

shouldn't it broadcast to 255.255.255.255?</i>

&quot;other card&quot; in this query is probably a bit of a red flag.

You probably aren't correctly handling routing betwixt your two private network ranges here--if you have 192.168.1.1 on eth0 and 192.168.1.128 on eth1, then neither should have a netmask of 255.255.255.0. They're different physical network segments. Now, some (maybe all) Linux kernels have an interesting quirk of working anyway in such a circumstance (they treat the two interface as if they're on the same switch)...so, this probably isn't going to keep things from working, but it's also probably not the right way to go about solving this particular problem.

--

Check out the forum guidelines!

Fri, 03/02/2007 - 01:52
JohnFord

as far as I can tell it's just apache doing this. I sent email and picked it up from the wan side of my network.

I read on one site that to see if your linux kernel is setup for ip aliasing; look for files in the /proc/net/alias* - well I have no files there or a directory there either.

But maybe fedora 6 does this some other way.

If I don't have ip alias setup then why does ifconfig set up these virtual eithernet cards under eth0?

surely this isn't this issue. Is there some other way to see if this is something else besides apache.

I say this because maybe I was able to pickup mail because my dns at godaddy.com told my mail client where to find postfix/dovecot on the new server and they answered base on name provided.

I did set apache to use the name provided but it did not help. It was set to a radio button that says default... so I changed it to use the name provided by the browser. This didn't help, so I figured that the default is to use the name provided by the browser.

Fri, 03/02/2007 - 02:01
JohnFord

just to reiterate...

every domain gets routed to the default /var/www/html folder instead of it's $HOME/domainname/public_html folder.

The only way to have apache direct a browser request to the correct $HOME/domainname/public_html folder is to put it's virtual ip address in the browser's command line instead to the hostname.

e.g. of browser request...
http://192.16.1.111 - directs to correct $HOME/domainname/public_html
http://virtualdomainname.com directs to the default /var/www/html

natually, now one but people on my network and those one my dsl subnet mask will be able to get my domains... but only if they use the private IP instead of the host name.

again, please offer any help. thanks.

Fri, 03/02/2007 - 10:50 (Reply to #5)
Joe
Joe's picture

<i>The only way to have apache direct a browser request to the correct $HOME/domainname/public_html folder is to put it's virtual ip address in the browser's command line instead to the hostname.

e.g. of browser request...
http://192.16.1.111 - directs to correct $HOME/domainname/public_html
http://virtualdomainname.com directs to the default /var/www/html

natually, now one but people on my network and those one my dsl subnet mask will be able to get my domains... but only if they use the private IP instead of the host name.</i>

Now we're getting somewhere! I've been reading all of the posts in the thread trying to figure out what the actual problem is. All this talk of aliases and netmasks and stuff is just confusing you. And me. ;-)

Luckily, it's easy to configure Virtualmin for use on a private network with a NATted public IP.

Here's what you do:

In Virtualmin's Module Config, in the Other server settings section, set the following bits:

Network interface for virtual addresses: Whatever interface is hooked up to the public address. I think you mentioned eth0. (Note that this should always be the real device, and never an alias device like eth0:1.)

Default virtual server IP address: Your public IP address.

Save it.

Now, you'll need to alter your Apache and BIND configuration to fix those broken VirtualHost sections and fix the wrong hosts files. I'm not sure if the Change IP Addresses will handle this particular case for you, but maybe. Apache and BIND need to have the public IP address, and not the private one. You can do that in the actual configuration files, or using the Webmin modules for Apache and BIND. (Or, you could give a go to the Change IP Addresses form in Virtualmin. I think it'll do the trick...but I'm not actually sure if that form has trickled back into GPL yet (if it hasn't it will soon).

--

Check out the forum guidelines!

Fri, 03/02/2007 - 02:04
JohnFord

another typo... just correcting for posterity.

e.g. of browser request...
http://192.16&lt;b&gt;8&lt;/b&gt;.1.111 - directs to correct $HOME/domainname/public_html
http://virtualdomainname.com directs to the default /var/www/html

Fri, 03/02/2007 - 10:20
JohnFord

please respond. The documentation on this is lax.

can you use private class c ip addresses for the needed separate aliased ip's or not.

I have seen examples on the net that use 192.168. addresses for the eth0:1, eth0:2, etc. - for separating the ssl

Is the proc/net/alias a good determination or not on a fedora6 machine that the kernel is capable to do ip aliasing?

thanks.

Fri, 03/02/2007 - 10:31 (Reply to #8)
Joe
Joe's picture

Hi John,

Every kernel ever made for Fedora (any version) is capable of aliasing. So, your kernel can definitely do IP aliases. I'll answer your other queries in sequence, as there's a lot of questions in this thread, and I'm having trouble keep up with all of them. ;-)

--

Check out the forum guidelines!

Fri, 03/02/2007 - 11:04
JohnFord

Hello Joe,

thanks for trying to help... I'm leaving the office for a few hours but saw this before I left.

anyways... my server dell rackmount 1550 comes with two built in ethernet cards.

eth0 - is what I use for static isp provided IP address.
eth1 - is what I use for local 192.168.1.0 network.

I configured virtualmin to user eth0 and in the default template I set the range to be 192.168.1.111 thru 199 - I used the same network range as my local so that as I administer the server I can pass all the packets without going thru the subnet on the dsl line.

I didn't know that virtualmin would broadcast the 192 addresses to the dsl line - but that is what appears to be what it did to set it up.

what virtualmin did after I told it the ip range 192... was set up a eth0:1, etc for each domain but chose the broadcast of 204.245.255.191 - which is the broadcast router for my dsl subnet mask. This caused a route table to be made with 192.168.1.96 being the start and 255.255.255.244 being the subnet mask.

here's what virtualmin made as startup eth alias...

192.168.1.111 - ip
255.255.255.224 - netmask
204.245.255.191 - broadcast - (again this is my dsl broadcast ip... I didn't enter this into anything by myself)

next domain... exactly the same except 112 as the last octet on the private ip

then... what becomes active for each eth0 - after boot constantly running due to the above start at boot settings...
192.168.1.111 - ip
255.255.255.224 - netmask
192.168.1.127 - broadcast

and, as I mentioned... this causes a route to be formed in the route table with
192.168.1.98 - destination
none - gateway
255.255.255.224 - netmask
eth0 - interface

thanks for the help. I'll be back later today and maybe you'll be around then.

/johnford

Fri, 03/02/2007 - 11:34 (Reply to #10)
Joe
Joe's picture

<i>I configured virtualmin to user eth0 and in the default template I set the range to be 192.168.1.111 thru 199 - I used the same network range as my local so that as I administer the server I can pass all the packets without going thru the subnet on the dsl line.</i>

Ah, that's the problem.

Don't do that.

There's nothing you can do with all of those private IPs if they aren't mapped directly to public ones. This aint Skype...HTTP doesn't have any NAT traversal magic built-in to it (and even if it did, you'd be better off using names, which is does support!). You can only make use of as many private addresses as has public counterparts. (And if you can avoid involving the private IPs at all, you'll save yourself some trouble, since networking can get complicated when you're doing NAT with this level of complexity.)

So, you can put as many shared hosts as you want onto one of those addresses, and put one SSL host onto the other (the next Virtualmin release will also allow an SSL host on the primary shared IP, as well, so if you have two IPs, you'll be able to run two SSL hosts and unlimited name-based hosts).

--

Check out the forum guidelines!

Fri, 03/02/2007 - 10:54
Joe
Joe's picture

Oh, yeah, somewhere in this thread you asked if private aliases could be used for SSL hosts, and the answer is: Only if you've got an additional public IP NATting to each of those private IP addresses. And even then, I don't think our private network handling is going to make it easy.

But, I believe you're trying to avoid a fundamental feature of the protocol: Identity. Because the entirety of the stream is encrypted there is no way to select between a number of certificates based on the hostname requested (nobody knows the hostname being requested until after the encrypted connection is already setup). So, one certificate per SSL domain, and the only way to choose between certificates is the IP where the connection came in.

So, no, you can't get something for nothing when it comes to SSL. ;-)

--

Check out the forum guidelines!

Fri, 03/02/2007 - 11:09
JohnFord

I do have two public ip addresses - but not on this machine - but I could set them both up on this machine if necessary.

Fri, 03/02/2007 - 11:11
JohnFord

I typo'ed again

the start of the route is 96 not 98 as the last octet

Sat, 03/03/2007 - 04:39
JohnFord

i got it working... but only on my network. It is really hard to keep track of all this stuff. To test sometimes I have to unplug one eth to make sure it isn't going to let packets in that way... but some cards won't work/route against the lo with it unplugged from the hub/switch. So, I have to plug it into a switch all by itself. Plus the firewall gets in the way, changing gateways, forgetting which is currently active, etc.

You sure were right about being better off without all the private ip stuff.

What I did was...
Set up all the virtual ips on eth1 which is the local eth. I told eth0 to be act as a router. this got ip forwarding or NAT going. Then... if I set my local machines to use the dns on the virtualmin server machine as their primary dns then they don't get the public ip that would have been returned from the DNS records I set up at godaddy.com. This causes my local browser's to go to the local ip for the http ssl request. (it works with virtual ip's on eth0 but takes much translation and is slower than just having a netmask that is already using the same first three octets on the local network side; no route is formed in the route table this way... so moving it to eth1 and using eth0 to act as a router is faster).

it goes like this...
192.168.1.1 - local win2k browser machine wants somedomain.com
DNS query passes thru gateway 192.168.1.254 - which is IPCOP proxy
IPCOP proxy then passes the dns request to the virtualmin server via public 204.245.255.189 to 204.245.255.187 - the virtualmin machine's eth0 (both are my public ips that I pay monthly for...) - DNS on virtualmin eth0 tells win2k machine the private IP 192.168.1.111:80 or 443 for the virtualmin website

Maybe you can see that I was trying to lay it out to where you can see that I actually when out to the public IPs and came back in to get my DNS request. Well the same will happen with the browser request too.

The browser then uses the same route to retrieve the 192.168.1.111:80 or 443 and httpd passes the page because the request comes in on the right IP and port.

You're right... I was thinking like apache was doing some NAT magic or something like that... I did not even snap that it was responding to the hostname:portnum based on the one it answered. If it arrives on the public IP 204.245.255.187 then the only VirtualHost or ServerName for that ip is... well... it is none! - so it delivered the browser request to the /var/www/html folder every time. Any request to that IP that didn't have a virtual host directive with a ServerName must be sent to the default folder directive.

When I conjoled some way to arrive at the 204.245.255.187 address (even from through the public side), with a hostname request for a virtualmin IP I had to arrive with a 192.168.1.xxx request and proper hostname. Then apache would then send me the correct page... even send it out by way of the one public IP I have to the other public IP I have, (my IPCOP proxy) to my localmachine. (more properly, i'd guess is that it hands it to eth1:1 which then uses the eth0 route back).

now... if my dns on the virtualmin machine goes down or for whatever reason does not respond quick enough; then my win2k browser on my local network will query my secondary dns setting, which is my isp's dns which will return the 204.245.255.187 (set up at godaddy.com) and the browser then goes to the virtualmin machine with the hostname request at the public IP and it fails.

so... if I want my pages to be accessed just by me and my six or so private machines I have and the other 28 on the subnet of my DSL line - (provided I can tell them and get them to put my virtualmin DNS server as there primary DNS)... then I can leave it this way.

anyways... as usual, you're right joe. But this is all your fault... (just kidding) :0), but I wish you would have put it in the docs that needing a separate ip meant public not private. I see how/why you said above... &quot;There's nothing you can do with all of those private IPs if they aren't mapped directly to public ones&quot;.

apache does no natting at all... I guess just answering and serving. I tried turning the &quot;Use cannonical on&quot; but it did not help. I don't know why... because it is supposed to not use the browser's request this way and look things up for itself in the directive value for the hostname.... I take that back... it goes back to my improper thinking... it doesn't work because of the IP address that the request comes in on... duh... whatever that IP is... that is the one that has to have the correct host name or it goes to default.

Also, the apache website says you can use the NameVirtualHost directive as much as you want. It shows examples that use the complete ipv4 and ipv6 address and port num. But it didn't help. No one from the public side will be able to request these websites unless they can come to the one public IP and then tell it that it really wants a private IP... well browsers don't do that! I've found that there is a way to have a reverse proxy that passes the right requests back/forth between my local network and the public. That's a lot of hassle and I saw a few were doing this to save on certificate costs. They call it tunnelling.

It all boils down to which IP address that apache answered the request on... it better have a hostname with that IP because, it won't change to another ip... just decide what hostname, if any, that it can direct it to... otherwise it would be NAT and that's what you said to me before I left this morning. All day before I got back here to work on this I was thinking about NAT and NAMEs.

The frustrating thing was most every thing I found on this issue showed examples of setting up virtual ip's on a single eth by using private network numbers in their examples. So, I thought it was a simple issue of just setting up virtual eth's on either one of my eth cards. Please forgive me for blaming you... I'm really not, just making a joke. Sure, I'd like more documentation... but I can't really believe what I do get for the price. The past few years I never even paid you guys a penny. I really am amazed you've done so much that you've done. I really hope you can withstand all the rig-a-ma-rores that come to bear with this project and simply... &quot;hang in there&quot;!

You can do it with private ip's, but it is useless unless you're just using it as a local test server.

There are a couple of issues now that I see I need to use only name-based virtual hosts. (and what a name-based virtual host truly is! :)

OK... Name-based ssl will work with apache using the NameVirtualHost *:443 directive... but everyone gets the same certificate... and the irratating warning. This is fine for me for the several hosts that I want to use it on...

1. I'm wondering if I should just answer the question myself, but are you going to have to tell me that namebased ssl is not supported so you cannot really recommend what to do if I want to use NameVirtualHost *:443 directive. I'm thinking that re-validating servers, and many other things may go haywire if I try to leave these four domains under the control of Virtualmin.
2. That is the biggest reason I bought the pro version is so that it could set up apache, mail, virus, spam, dns... so, now that I got all those so close to what I want; then I guess I could just delete the server, but choose the option to just remove it from the control of virtualmin. There are a lot of ongoing services that I will miss out on if I choose to do this... so if there is anyway to set up NameVirtualHost *:443 directive for a host or two...it'd be a plus. Will just saving these directive in apache somewhere else... then deleting and starting over with namebased - then copy/paste the directive into apache's config cause problems?
3. why did you say that I cannot even have one of my hosts on the same IP as the namebased *:80 and that this will change later... I don't see anything stopping it now.

4. More of a take notice than question.... All of the above stuff worked fine... but to get the server to see the ssl requests I had to stop iptables... for some reason virtualmin did not ever add a chain to the linux firewall to accept https. It should have done this for me shouldn't it?

thank you for all your time and patience... and if you are still reading... you're stamina.

/johnford

Sun, 03/04/2007 - 15:36 (Reply to #15)
Joe
Joe's picture

Hey John,

<i>i got it working... but only on my network. It is really hard to keep track of all this stuff. To test sometimes I have to unplug one eth to make sure it isn't going to let packets in that way... but some cards won't work/route against the lo with it unplugged from the hub/switch. So, I have to plug it into a switch all by itself. Plus the firewall gets in the way, changing gateways, forgetting which is currently active, etc.

You sure were right about being better off without all the private ip stuff.</i>

Yes, this is actually the kind of tricky stuff I was encouraging you to avoid. And the forgiving nature of Linux routing across local NICs is actually a hindrance when things get complicated (because you end up thinking all of this jiggling of wires and ports and switches is how you should make it work, when in fact, you ought to be getting the routing tables, masks, etc. right, which makes it work for everyone, not just the Linux box itself). You can get as complicated as you want, and Linux will accommodate, but you need to learn a lot about routing to get it right. Adding NAT to the routing picture makes it even harder.

<i>anyways... as usual, you're right joe. But this is all your fault... (just kidding) :0), but I wish you would have put it in the docs that needing a separate ip meant public not private.</i>

I figured it didn't make any difference, but I guess I didn't make it clear that the problem you have to solve is end-to-end connectivity, <i>not</i> fooling Apache or Virtualmin into serving or setting things up--it's not the software you have to convince...it's the protocol, which insists on end-to-end connectivity (anything else looks like a man-in-the-middle attack to the client). Apache will happily serve SSL on as many domains as you want, but it'll always look like whatever domains certificate you're using. That's bad security, and removes half of SSLs purpose (identity), so we don't do it.

If you want multiple SSL domains with actual security, you <i>need</i> multiple IP addresses. There is a future without this problem, but it's not one that you or I can solve--the browser and webserver have to support newer protocols. I don't think any version of either do so today.

<i>I'm thinking that re-validating servers, and many other things may go haywire if I try to leave these four domains under the control of Virtualmin.</i>

No, of course not. If you setup SSL hosts outside of Virtualmin they don't affect Virtualmin at all, and Virtualmin doesn't affect them. That's why, among other things, Virtualmin is the best damned thing going in this space. ;-)

Setup as many SSL VirtualHosts outside of Virtualmin as you like. Virtualmin won't give one whit about them. You can even manage them in the Apache module, if you want. Virtualmin doesn't care.

<i>2. That is the biggest reason I bought the pro version is so that it could set up apache, mail, virus, spam, dns... so, now that I got all those so close to what I want; then I guess I could just delete the server, but choose the option to just remove it from the control of virtualmin. There are a lot of ongoing services that I will miss out on if I choose to do this... so if there is anyway to set up NameVirtualHost *:443 directive for a host or two...it'd be a plus. Will just saving these directive in apache somewhere else... then deleting and starting over with namebased - then copy/paste the directive into apache's config cause problems?</i>

Hmmmm...I have no idea what you're asking here, but it sounds bad. ;-)

Don't go deleting stuff or removing it from the control of Virtualmin--you lose so much capability for ongoing maintenance. I'd never wish that on anyone.

You're assuming Virtualmin is preachy and bossy. It isn't. It really really isn't. It'll do what you tell it, and it won't break the stuff you add to Apache outside of Virtualmin, even within the VirtualHost sections that Virtualmin manages! Though there could be conflicts in directives.

If you want to do what I think you want to do (I'm having a hard time keeping up!), do it this way:

[ol]

[*]Create your domains. Get 3.36 of Virtualmin so you can create one as SSL.[/*]

[*]Edit httpd.conf.[/*]

[*]Copy the VirtualHost sections that don't have SSL counterparts.[/*]

[*]Convert them to SSL sections, by moving them to ip:443, and adding certificate directives--all pointing to the same certificate. Pretty much just mirror the one SSL domains directives right over to all of the other domains.[/*]

[/ol]

Now, the domain itself and its contents (mailboxes, scripts, PHP4/PHP5, etc.) are controlled by Virtualmin. Your SSL hosts, except the first, are outside of Virtualmin's control, but you'll rarely need to do anything to them (but you should keep an eye on the non-SSL ones to be sure any directives get ported over when Virtualmin adds them for scripts and such (or scripts installed with Install Scripts won't work).

<i>3. why did you say that I cannot even have one of my hosts on the same IP as the namebased *:80 and that this will change later... I don't see anything stopping it now.</i>

Virtualmin prior to 3.36 assumed nobody would want to put SSL hosts on the same IP as their shared hosts. 3.36 will allow you to setup one SSL host on a system that only has one IP. Just an assumption borne out of a history of being used in large hosting environments. Some of our Early Adopters are in much smaller environments, often without spare IPs, so we've now accommodated that particular situation.

Oh, yeah, I wanted to address this, as well:

<i>Also, the apache website says you can use the NameVirtualHost directive as much as you want. It shows examples that use the complete ipv4 and ipv6 address and port num. But it didn't help. No one from the public side will be able to request these websites unless they can come to the one public IP and then tell it that it really wants a private IP... well browsers don't do that! I've found that there is a way to have a reverse proxy that passes the right requests back/forth between my local network and the public. That's a lot of hassle and I saw a few were doing this to save on certificate costs. They call it tunnelling.</i>

Again, this is a routing problem. Apache will work fine on any number of private addresses mapped to public ones (your VirtualHost sections need to specify the private addresses--not the public ones). You get the requests from the outside to the inside via correct routing and NAT, and Apache will do the right thing with the requests. It sounds like you may not have the routing infrastructure in place to meet that requirement. No proxies are needed, thought proxies are great for some situations (my previous company was a proxy appliance vendor...I'm a big fan of proxies in their right place...but you don't <i>need</i> proxying...just correct routing and NAT).

Browsers don't need to do anything special, nor does Apache. If you route/NAT correctly between the two, neither will even know about the difference.

Linux, all by itself, can provide the routing infrastructure needed to do what you want. It has one of the most amazing routers on the market built right in to it. But, you'd have to give Linux one or both of your public IPs. And then you no longer have this particular set of problems to solve! Your only problem then would be getting your internal PCs out to the world...that one is easy. IP Masquerading in Linux is magically simple. There's a great HOWTO about it here:

http://tldp.org/HOWTO/IP-Masquerade-HOWTO/

--

Check out the forum guidelines!

Sun, 03/04/2007 - 18:08
JohnFord

Thanks Joe,

I got them set up and haven't put the name-based ssl directive for each one to use the ssl with the same cert. - I did delete them... then set them up for name-based on :80 only by using virtualmin. I had saved the old copy of httpd.conf to reference the ssl directive if/when I tried my namebased deal with *:443. By this time I have decided or figured out for the most part... and your response did a great booster of encouragement... the virtualmin won't get irritated and is by far the most well planned and understanding about all of these different issues... and that is would not care in the slightest if I had other directives in there that the web forms didn't put there... or even that the web forms said was a no-no... like this ssl issue. I really, really do like this software. It's champion. I hope you never figure out all the bugs so we can all pretend we're upset and you'll be the goody-two-shoes good buddy and keep the price as low as it is... (just kidding... but if we stick together over the years I'll be expecting... just cause of what I've seen of your character so far... some favortism for us &quot;charter members&quot; if you will).

I see all the posts and the stuff you've got to deal with on a day to day basis and I really commend you. I'm quite sure even some (or most) of my posts you've done some mumbling, or grumbling about - like &quot;gee-wheez what have I got myself into&quot;...

anyways...[b&gt;I really do like&lt;/b&gt; the software so believe me when I say it so you'll never be thinking I'm trying to badmouth... (another thing I'm guessing but learing I would think it you could do that pretty well too... so, if I was badmouthing... I am kinda like you... and don't do it on the sly... just come right out with it).

----------------------------------------
they'll be a lot of important stuff in my response here... so please concentrate.. ;-)

1. Please remember that when I was setting these up and therefore caused me to make this post... I used your web forms so they made complete IP addresses in the apache directives... they were private ip address... but they were complete and correct.
2. Maybe I am not following you correctly... but I think it is in reverse because I've reread you post two-three times.
3. I did have the ip address in the directive... but the only way apache would serve me that particular directive... was based on how it was asked... (so I do not see how routing and nat or even masq(nat) will help.
4. You see... I need everyone in the world to know my private ip addresses for these domains... well what does that work for them... if their browser wants to know how to find www.domainname.com and their dns client says it is at 192.168.1.111 - then they will be routed to who knows where... probably no place but surely the entire of the internet is not going to let all their routers pass it to little old me.
5. I must then tell everybody that the address is a public one... and that is how I have it set up... 204.245.255.187 - at my name server at godaddy.com. (I think you just suggested that I can get nat or masq or routing to work in reverse... and I am real limited in all my learning but I do not think that is right).
6. so... now that I told them to come looking at the public IP for the domain.com... I better have something there that can get the request... and translate it to the private ip address. That way... it'll ask apache for the host at the 192.168.1.11 address... and if the directive says... yep... you arrived on 192.168.1.111 with a request for domanname.com... this is valid... so, here... get this page instead of the default /var/www/html.
7. the only way I see to do this is with a proxy. Even if I nat or masq across eth cards it would still be based on what I was able to get them to my box on... just like you're statments above about it being an issue of each private ip being mapped to a public one.
8. I have to make the public one smart enough to decide if a hostname or namebased request arriving on one public ip is a valid request and then send it to apache on the right IP address. (nat and masq or routing don't that do they??? they just translate the address and not the packets containing hostname etc.)
9. this is why and only why, (based on my understanding of what is going on...) that I was able to do this on my local network... (and even going out of it and back into it on the subnet of the dsl line)... It was because I forced/ or figured out how to get my browser to arrive with a request to 192.168.1.111:443 at the public address... so it got routed to apache with the right ip address and hostname.
10. I did read some of the stuff and that great URL you posted for me... and, please believe me... I probably read more than you're having to by reading this email... but I do not see how it will help and maybe you are so much more familiar you will read this and point out errors or fallacies.
11. The fact that you were johnny-on-the-spot ready to tell me to go-for-it if I wanna use namebased *:443 instead of a simple. &quot;look dude... we don't support it... so, don't bug me with this...&quot; bespeaks much of your character and the great service and situation I have gotten into with ever even involving myself with this organization... so I hope that say enough atta-boys because I am serious about this being the best isp management software and crowd on the planet.

-------------------------------
now... please keep concentrating because these things I think will help us both much in the future...

11. You mentioned to keep an eye on the non-ssl directive... (ah-hah... ) why don't you guys make a tag or something we can put in any text config file which makes webmin or virtualmin leave it alone? Most all of them use the # to comment out a line... why can't we do a #-begin_novirtualminedit - and then a #-end_novirtualminedit kind of a tag??? have we got that going already? It'd be great! You guys use perl for most everything... so it looks like it would be easy to implement.
12. I mentioned that using the virtualmin forms to create ssl domains did not make a iptables firewall rule and that should be gleaned out of this post and bug report or whatever.
13. I know my posts have been long and maybe hard to follow or deal with... but, if you ever really want to tell me off... please do it by private email so we can pretend like it never happened on the forum... (joke...)

Respectfully,
John Ford

Sun, 03/18/2007 - 11:04
ah...lifes...good

Oh my god! My eyeballs popped out by the time I read Reply 15! I think John Ford could write a 3rd volume of the bible (Newest Testament) by next Sunday and no, he doesn't need to rest on Sunday. Hehehe... ;-)

I jumped on this thread because I have a similar problem:

I created a virtual server (e.g. bible3.com) via Virtualmin but couldn't access it -- i.e. when I browse the domain name , I got directed to the &quot;catchall&quot; website as stipuated in the httpd.conf under[VirtualHost *&gt; -- see below.

That is, the Apache web server served /var/www/html/catchall/public_html instead of /var/www/html/bible3.com/public_html

Why is that so?

&lt;VirtualHost *&gt;
DocumentRoot /var/www/html/catchall/public_html
&lt;/VirtualHost&gt;

&lt;VirtualHost 10.1.1.2&gt;
ServerName bible3.com
DocumentRoot /var/www/html/bible3.com/public_html
&lt;/VirtualHost&gt;

Sun, 03/18/2007 - 23:43 (Reply to #18)
ah...lifes...good

&gt;&gt; I created a virtual server (e.g. bible3.com) via Virtualmin but couldn't access it -- i.e. when I browse the domain name , I got directed to the &quot;catchall&quot; website as stipuated in the httpd.conf under[VirtualHost *&gt; -- see below.

That is, the Apache web server served /var/www/html/catchall/public_html instead of /var/www/html/bible3.com/public_html

Why is that so?

OK, problem solved. Removed an extra &quot;Options&quot; in the VirtualHost directive created by Virtualmin in the httpd.conf

When I restarted the server, Virtualmin tells me that the Apache server wasn't working properly because there is an additional &quot;Options&quot; before &quot;Options ExecCGI Includes....&quot;

I don't know how the additional Options got there. May be it's me or maybe there is a bug in one of Virtualmin's Apache config interface.

Sun, 03/18/2007 - 14:45
JohnFord

A.H.

no... I could not write the Bible... there is no truth in that statement whatsoever. I have tried my best to be accurate but something like that would be nothing but lies.

ok...

when I do a DNS lookup for bible3.com I get the ip address 216.246.48.138 - I do not get 10.1.1.2... so naturally my browser is going to go to 216.246.48.138 to get the website.

when my browser goes to that ip - 216.246.48.138 to get the website it gets the very page that apache has listed for that IP... /you're/catchall/directive/as/you/put/it/up/there

My browser will not go to your server and arrive at ip address 10.1.1.2 with a request... because DNS lookups do not map to that address.

NOW... the important thing is that 10.1.1.2 is a private ip address... so if you figure out some way for my browser to get that address when it does a DNS lookup... then you are getting closer... my browser will then try to go to 10.1.1.2 on port 80 with a website request. The problem is that it being a private ip address... I have very little chance at all of ever getting to your server... it being a private one... the chances are there are many other private machines with that IP that I can go to instead of yours... yours will in all likelihood, get lost in the maze

but in actuallity... most all routers, computers, etc. are setup where they do not pass packets to private IP addresses on the public pipes. That way my private IP traffic doesn't do stuff to yours and so on and so on and so on. That is why they made private and public IPs. To allow for setup that separates or does not listen to stuff it shouldn't.

You need to figure out a way for any browser in the world to come to your 216.246.48.138 address and then map them once they arrive to the 10.1.1.2 - that is the whole nature of this discussion. Apache only was told that requests arriving at 10.1.1.2 port 80 should be mapped to the /bible3.com/directive/folders/you/mentioned/above.

Right now you are not ever getting traffic to appear at that 10.1.1.2 IP with a request...so it get directed to the catchall.

Sun, 03/18/2007 - 16:31
JohnFord

to elaborate a bit further as it looks like you might have been thinking along the same lines as I was...

You see... when someone's browser comes to your box with a website request... and they are at the public IP 216.246.48.138 port 80... then is how they first meet up with your apache.

The problem is... thinking the host name request that you know that anyone's browser (or put it most every person's browser) will request is not valid.

Why... because it came in on 216.246.48.138 port 80 and then said... my host/domain I want is 'www.bible3.com' - apache looks in the directives... and says... look dude... we got one of those... but if you would have arrived on 10.1.1.2 then I'd be sending you there... there is no place but the &quot;catchall&quot; to send you to because we have no &quot;www.bible3.com&quot; at this IP 216.246.48.138

you see... it never resolves to anything... because the domain name is not correct for the IP address that it came in on...

I hope that helps to explain it and it is just what I can see happening based on spending hours trying to make it work.

Mon, 03/19/2007 - 00:33
JohnFord

A.H.

I don't know what you did... but things did not change for me... I get the same page I was getting earlier today... some page with a bunch of spanish or italian looking words on it.