Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Setup: 2 Webservers pointed to 127.0.0.1:8080 and :8081. Curl validates they work as expected. Apache with the following virt hosts:

NameVirtualHost 192.168.1.1:80

<VirtualHost 192.168.1.1:80>
  ServerAdmin foo@bar.com
  ProxyPass             /       http://127.0.0.1:8080/
  ProxyPassReverse      /       http://127.0.0.1:8080/
  ServerName 192.168.1.1
  ServerAlias http://192.168.1.1
</VirtualHost>

NameVirtualHost 192.168.1.2:80

<VirtualHost 192.168.1.2:80>
  ServerAdmin foo@bar.com
  ProxyPass             /       http://127.0.0.1:8081/
  ProxyPassReverse      /       http://127.0.0.1:8081/
  ServerName 192.168.1.2
  ServerAlias http://192.168.1.2
</VirtualHost>

On the server I can curl to the virtualhosts and receive appropriate responses. (curl 192.168.1.1 gives me the webservers response from localhost:8080, etc)

remote hosts cannot however connect to 192.168.1.1 or .2 at all. What am I missing?

Re: comments

Yes, the default directory Directive is still in place.

# Deny access to root file system
<Directory />
        Options None
        AllowOverride None
        Order Deny,Allow
        deny from all
</Directory>

No apache logs are generated when trying to reach 192.168.1.1 remotely. They do get generated when curl from local.

If I point the webservers to *:8080 and *:8081 instead of binding to localhost, I can access them from a remote host via 192.168.1.1 and 192.168.1.2 if i specify the 8080 and 8081 ports (both ports work on both IP's, which is what I'm trying to avoid with apache reverse proxy bind to 80 on each interface)

Edit2:

curl verbose output: (similar for second webserver, and for 127.0.0.1:portnum)

[user@host mingle_12_2_1]$ curl -v 192.168.1.1
* About to connect() to 192.168.1.1 port 80
*   Trying 192.168.1.1... connected
* Connected to 192.168.1.1 (192.168.1.1) port 80
> GET / HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: 192.168.1.1
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Tue, 16 Oct 2012 16:22:08 GMT
< Server: Jetty(6.1.19)
< Cache-Control: no-cache
< Location: http://192.168.1.1/install
< X-Runtime: 130
< Content-Type: text/html; charset=utf-8
< Content-Length: 94
< Connection: close
Closing connection #0
<html><body>You are being <a href="http://192.168.1.1/install">redirected</a>.</body></html>

log from the request local

192.168.1.1 - - [16/Oct/2012:12:22:08 -0400] "GET / HTTP/1.1" 302 94

no apache access log or error log generated when requests from remote clients.

Edit3

curl and logs to both virtual hosts are literally identical, except for the IP address used. Working w/ security admins to get the locked down rules for more info. I appreciate you guys' time.

share|improve this question
    
is this your complete apache config ? are there any <directory/ directives ? what error do you get (take a look at error log file) when you try to connect from a remote host ? –  m0ntassar Oct 16 '12 at 16:04
    
can you provide that from BOTH of virtualhosts not just one? –  alexus Oct 16 '12 at 16:36

2 Answers 2

Since a proxypass setup operates entirely in the (virtual) URL-space, you need to grant access to each vhost via a Location directive:

<VirtualHost 192.168.1.1:80>
  ServerAdmin foo@bar.com
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
  ServerName 192.168.1.1
  <Location />
    Order allow,deny
    Allow from All
  </Location>
</VirtualHost>

Also, get rid of the NameVirtualHosts if you're not using them, and a ServerName must be a hostname, there is no scheme or port or whatever. Just a hostname.

share|improve this answer
    
The added location directive had no impact on any of the results. Nor did the NameVirtualHosts (But I suppose thats a win, as the local requets was still successfully routed thru the proxy) –  Yep Oct 16 '12 at 17:13
    
If there is no Documentroot for these vhosts, access control may not matter. Every vhost needs a DocumentRoot. –  adaptr Oct 18 '12 at 9:09

can you provide:

  • curl syntax/output (use verbose)
  • logs from apache
  • ifconfig output
  • cat /etc/hosts
  • firewall ruleset
  • SELinux enable/disable?

* UPDATE *

also ServerAlias you should remove http:// part as that not needed, not to mention that since your ServerName is same as ServerAlias, ServerAlias is just not needed.

share|improve this answer
    
Nor is the entirety of that ServerAlias, since it is identical to the - already superfluous - ServerName this.is.my.ip form. –  adaptr Oct 16 '12 at 16:29
    
ServerName can be IP (it doesn't make any sense but it can) ServerAlias is not needed if ServerName has same thing. –  alexus Oct 16 '12 at 16:32
    
I did not say it could not be an IP. I said it was superfluous. –  adaptr Oct 16 '12 at 16:34
    
@adaptr, right I'm agreeing with you) I'm just expanding my answer. –  alexus Oct 16 '12 at 16:35
    
Then why don't you...expand your answer ? –  adaptr Oct 16 '12 at 16:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.