[gentoo-user] Reverse Proxy with Apache2

Raphael Mejias Dias

unread,

Jan 18, 2022, 12:00:04 PM1/18/22

to

Hello,

I'm trying to setup a reverse proxy on my apache2 server to serve an another apache2 server running on a vm, basically my root apache2 is at 192.168.0.15 and my second apache2 is at 192.168.0.15:8280.

My idea is to have 192.168.0.15/zm as 192.168.0.15:8280.

The question is, how to do it?

I've looked up some guides, but it is difficult to setup.

My config:

ServerAdmin ro...@192.168.0.15

ServerName 192.168.0.15

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

SSLEngine on

SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt

SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

SSLOptions +StdEnvVars

</FilesMatch>

SSLOptions +StdEnvVars

</Directory>

</VirtualHost>

ServerName 192.168.0.15/zm

ServerAlias zm

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

ProxyPass /zm http://192.168.0.15:8280/zm

ProxyPassReverse /zm http://192.168.0.15:8280/zm

SSLEngine On

SSLProxyEngine On

SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt

SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

</VirtualHost>

</IfModule>

Does it look any good?

Thanks.

M.S. Raphael Mejias Dias

Nuclear Engineer | Reactors

Secure e-mail: raphael.m...@protonmail.com
PGP Key for rap...@gmail.com: https://pgp.mit.edu/pks/lookup?op=get&search=0x87BC5A746072F951

Anatoly Laskaris

unread,

Jan 18, 2022, 1:30:05 PM1/18/22

to

On 2022-01-18 19:57, Raphael Mejias Dias wrote:
> Hello,
>
> I'm trying to setup a reverse proxy on my apache2 server to serve an
> another apache2 server running on a vm, basically my root apache2 is

> at 192.168.0.15 and my second apache2 is at 192.168.0.15:8280 [1].
> My idea is to have 192.168.0.15/zm [2] as 192.168.0.15:8280 [1].

>
> The question is, how to do it?
> I've looked up some guides, but it is difficult to setup.

I'm sorry for not answering to the question directly, but why use
apache2?

There are modern alternatives with very simple configuration and low
operational overhead like Caddy (https://caddyserver.com/) where reverse
proxy is just one command: caddy reverse-proxy --to 127.0.0.1:9000

And something completely different like Traefik
(https://doc.traefik.io/traefik/getting-started/quick-start/) which is
geared towards modern cloud native infrastructure with containers and
workload orchestrators like Nomad or Kubernetes.
Usually you don't configure Traefik with static config file, but with
metadata and annotations in K8S and Consul so it is dynamic and
reactive.

Or you can use nginx (which is already considered pretty old and clunky,
but it is much easier than apache still).

Grant Taylor

unread,

Jan 18, 2022, 2:20:03 PM1/18/22

to

On 1/18/22 9:57 AM, Raphael Mejias Dias wrote:
> Hello,

Hi,

> I'm trying to setup a reverse proxy on my apache2 server to serve an
> another apache2 server running on a vm, basically my root apache2
> is at 192.168.0.15 and my second apache2 is at 192.168.0.15:8280.
> My idea is to have 192.168.0.15/zm as 192.168.0.15:8280.

If I understand you correctly, you want to take a sub-directory / path
from a site on one port (80) and reverse proxy it to the root of another
site on a different port (8280) on the same host. Am I understanding
you correctly?

> The question is, how to do it?

I need to finish my $CAFFEINE before I formulate a complete answer. But
I'm sharing an incomplete answer to hopefully get you down the road sooner.

> I've looked up some guides, but it is difficult to setup.

Like most things Apache, it's mostly difficult the first (few) time(s)
you do it. Once you've done it, it's not as bad.

> My config:

I'm redacting the things that I think aren't germane to the question at
hand.

> <VirtualHost _default_:443>
> ServerName 192.168.0.15
> DocumentRoot /var/www/html

> </VirtualHost>
>
> <VirtualHost *:443>
> ServerName 192.168.0.15/zm

> ProxyPass /zm http://192.168.0.15:8280/zm
> ProxyPassReverse /zm http://192.168.0.15:8280/zm

> </VirtualHost>

>
> Does it look any good?

I question the use of "_default_" and "*", both of which on port 443.
My fear is that there is a large potential for confusion ~> conflict
between these two named virtual hosts.

I'm also not seeing the config for the instance listening on port 8280.

If the second named virtual host was put in place specifically in
support of the reverse proxy, then I think you want to refactor it as a
<Directory>...</Directory> under the original named virtual host.

The other thing that I'm not seeing is the <Proxy>...</Proxy>
configuration that I would expect to see. E.g.

<Proxy>
Order deny,allow
Deny from all
Allow from 192.0.2.0/24
Allow from 198.51.100.0/24
Allow from 203.0.113.0/24
</Proxy>

Beyond that, I need to finish my $CAFFEINE, have some clarification from
you, and look at specific failures.

N.B.: The access and error log files are going to be your friend when
configuring this (or really anything Apache httpd related) as they will
let you know when your configuration is correct but things like
permission (Allow from) are the problem. Also apache(2)ctl configtest
is your friend.

> Thanks.

You're welcome.

--
Grant. . . .
unix || die

Grant Taylor

unread,

Jan 18, 2022, 2:20:03 PM1/18/22

to

On 1/18/22 11:24 AM, Anatoly Laskaris wrote:
> I'm sorry for not answering to the question directly, but why use apache2?

- Because Apache is already installed and listening on the port in
question.
- Because that's what the OP asked about.
- Because it might be IBM / Oracle HTTP Server which are re-rolls of
Apache HTTP Server.
- $REASONS

> There are modern alternatives ...

Age of something doesn't mean a lot.

- TCP/IP is from the 80s and yet we are still using it.
- OSI is newer than IPv4.
- IPv6 is newer than IPv4 and OSI.

Yet we are still talking about the venerable IPv4.

> And something completely different like Traefik
> (https://doc.traefik.io/traefik/getting-started/quick-start/) which is
> geared towards modern cloud native infrastructure with containers and
> workload orchestrators like Nomad or Kubernetes.
> Usually you don't configure Traefik with static config file, but with
> metadata and annotations in K8S and Consul so it is dynamic and reactive.

I view adding /additional/ software / daemons as poor form, especially
when the /existing/ software can do the task at hand.

Don't overlook the port conflict.

> Or you can use nginx (which is already considered pretty old and clunky,
> but it is much easier than apache still).

Why start the email asking why something old is used and then finish the
email suggesting the possibility of using something else old?

Raphael Mejias Dias

unread,

Jan 18, 2022, 3:30:05 PM1/18/22

to

Hello,

I've modified a little my config file:

ServerName raphaxx.intranet

ServerAdmin rap...@gmail.com

DocumentRoot /var/www/html

ErrorLog ${APACHE_LOG_DIR}/error.log

CustomLog ${APACHE_LOG_DIR}/access.log combined

ProxyRequests Off

ProxyPreserveHost On

Order deny,allow

Allow from all

</Proxy>

ProxyPass "zmz" "http://raphaxx.intranet:8280/zm/"

ProxyPassReverse "zmz" "http://raphaxx.intranet:8280/zm/"

SSLEngine on

SSLCertificateFile /etc/ssl/certs/apache-selfsigned_raphaxx.crt

SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned_raphaxx.key

SSLOptions +StdEnvVars

</FilesMatch>

SSLOptions +StdEnvVars

</Directory>

</VirtualHost>

</IfModule>

My ssl is ok, the ssl redirect is on default.conf

But this ProxyReverse, I've been trying in many ways, another file, and so on, but nothing works.

About the VirtualHost for the 8280, I'm guessing it was not necessary, because the 8280 is the VM and the VM has its own apache2.

I have a nat rule to redirect 192.168.0.15:8280 to my VM server 192.168.2.100:80 on my root server 192.168.0.15.

About Caddy, I do not want to install another server and deal with another config.

Thanks!

Anatoly Laskaris

unread,

Jan 18, 2022, 3:40:04 PM1/18/22

to

On 2022-01-18 22:17, Grant Taylor wrote:
> Age of something doesn't mean a lot.
>
> - TCP/IP is from the 80s and yet we are still using it.
> - OSI is newer than IPv4.
> - IPv6 is newer than IPv4 and OSI.
>
> Yet we are still talking about the venerable IPv4.

Age migth mean a lot when we are talking about software. Modern software
usually is easier to configure, has sane defaults, more secure and has
integration with other modern software. And is much more popular in the
community meaning better support.

> I view adding /additional/ software / daemons as poor form, especially
> when the /existing/ software can do the task at hand.

I'm was not talking about adding software, I was talking about replacing
software. Time saved in managing complex software that does a simple
task can be applied elsewhere.

In regards to "already having a software" most modern applications don't
require "having" them. It works out of the box, usually with one command
and you can switch parts of your infrastructure without pain thanks to
containers (or statically linked binaries in golang and rust) without
downtime (if done right).

> Don't overlook the port conflict.

Dynamic ports with service discovery == no port conflicts.

> Why start the email asking why something old is used and then finish
> the email suggesting the possibility of using something else old?

Not that old as apache. Nginx is still widly used (contrast to apache),
but is being replaced by caddy/traefik. Apache is ancient and I've never
seen it running in production.

Nginx is from the same (premicroservice) age as apache and will probably
we easier to understand than something like Traefik.

Grant Taylor

unread,

Jan 18, 2022, 6:30:03 PM1/18/22

to

On 1/18/22 1:30 PM, Anatoly Laskaris wrote:
> Age migth mean a lot when we are talking about software. Modern software
> usually is easier to configure, has sane defaults, more secure and has
> integration with other modern software.

I'll concede that those points are /possibilities/. But they are not
guaranteed.

> And is much more popular in the community meaning better support.

I do not agree that something being more common means, much less
implies, better support. There are an awful lot of bad recommendations
all over the Internet.

> I'm was not talking about adding software, I was talking about replacing
> software.

But you are. Replacing something inherently implies adding and / or
configuring something old with something new.

> Time saved in managing complex software that does a simple task can
> be applied elsewhere.

Sometimes yes, sometimes no.

> In regards to "already having a software" most modern applications don't
> require "having" them. It works out of the box, usually with one command
> and you can switch parts of your infrastructure without pain thanks to
> containers (or statically linked binaries in golang and rust) without
> downtime (if done right).

"if done right" is so over the top the /operative/ /phrase/ of that
statement that it's not even remotely funny.

> Dynamic ports with service discovery == no port conflicts.

There's no dynamic ports / service discovery in what the OP asked about.

The OP asked how to configure a feature (reverse proxy) of the software
that they are already (Apache HTTPD) using for a part of a URL
(https://192.168.0.15:443/zv) for a service that's currently listening
on a given IP and port pair (https://192.168.0.15:443/).

So please elaborate on what the right way is to replace (as in add new
and remove old) the existing software /or/ split the IP & port
(192.168.0.15 TCP port 443) across multiple daemons is. I would very
much be interested in learning how to do this the right way.

I can think of many ways to do this, but all of which require something
intercepting the port & IP pair at some point up stream.

> Not that old as apache.

I take your statement to be that the Apache HTTPD developers and
administrators have more experience than Nginx / caddy / traefik
developers and administrators by the simple fact that it has existed longer.

What /new/ thing are you using to communicate with caddy / traefik if
you don't use the old crufty IPv4 / IPv6?

> Nginx is still widly used (contrast to apache),

The first four reports I found when searching for web server popularity
show that Apache and Nginx are the top two popular servers. Which one
is number one depends on the report.

Link - Global Web Server Market Share January 2022
- https://hostadvice.com/marketshare/server/

Link - Web and Application Servers Software Market Share
- https://www.datanyze.com/market-share/web-and-application-servers--425

Link - Usage statistics of web servers
- https://w3techs.com/technologies/overview/web_server

Link - January 2022 Web Server Survey
- https://news.netcraft.com/archives/category/web-server-survey/

My opinion is that being the first, or the close second is a good
indication that Apache is still wildly used.

> but is being replaced by caddy/traefik. Apache is ancient and I've
> never seen it running in production.

If you've never seen the first or second most popular web server running
in production, I can only question where you are looking.

I know multiple people that have run Apache HTTP Server (both by Apache
and rebranded by IBM / Oracle) web server in production on multiple
platforms for each and every year for the last two decades. I've
personally run Apache in production for that entire time.

Grant Taylor

unread,

Jan 18, 2022, 6:50:04 PM1/18/22

to

On 1/18/22 1:26 PM, Raphael Mejias Dias wrote:
> Hello,

Hi,

> I've modified a little my config file:

Okay.

> ProxyPass "zmz" "http://raphaxx.intranet:8280/zm/
> ProxyPassReverse "zmz" "http://raphaxx.intranet:8280/zm/"

I would expect the first parameter to be anchored / fully qualified from
within the site's URL. E.g.

ProxyPass "/zmz" "http://raphaxx.intranet:8280/zm/"
ProxyPassReverse "/zmz" "http://raphaxx.intranet:8280/zm/"

My expectation would be that for this <VirtualHost> to proxy any
requests to the "/zmz" path (sub-directory?) to the "/zm/" path on an
HTTP server on port 8280 of raphaxx.intranet.

Aside: Make sure that "raphaxx.intranet" resolves where you want it to.
Be mindful of IPv4 vs IPv6.

> My ssl is ok, the ssl redirect is on default.conf

Okay.

> But this ProxyReverse, I've been trying in many ways, another file, and
> so on, but nothing works.

I have the following in a config file for a service that I disabled a
few months ago.

ProxyPass "/" "http://127.0.0.1:8080/"
ProxyPassReverse "/" "http://127.0.0.1:8080/"

This was in use in a Named Virtual Host that reverse proxied everything
to port 8080 listening on localhost (127.0.0.1).

Aside: Port 8080 on localhost (127.0.0.1) was actually an SSH remote
port forward to a web server running on the remote client machine.

You will want to adjust the source path ("/") and the destination
("http://127.0.0.1:8080/") as you need. But this is copied verbatim
from a site that I disabled recently. (Disabling is typical Ubuntu /
Debian remove a sym-link so that the config is not in the sites-enabled
directory. No changes to the actual config file.)

> About the VirtualHost for the 8280, I'm guessing it was not necessary,
> because the 8280 is the VM and the VM has its own apache2.

ACK

> I have a nat rule to redirect 192.168.0.15:8280 to my VM server
> 192.168.2.100:80 on my root server 192.168.0.15.

Okay. That could be a complicating factor.

You say "NAT rule". I'm taking that to mean a Destination NAT (DNAT)
rule for port forwarding. The important bit is that it doesn't alter
the source IP (SNAT). So you could potentially be running into a TCP
triangle scenario.

Unless you have a specific reason to use the NAT rule, I would strongly
suggest altering the ProxyPass(Reverse) rules to use the proper target.

ProxyPass "/zmz" "http://192.168.2.100:80/zm/"
ProxyPassReverse "/zmz" "http://192.168.2.100:80/zm/"

Just avoid the potential for a TCP triangle all together.

Considering the potential complexity, please share what sort of errors /
failures you are seeing. Given the remote nature of the real server
(from the point of view of the Apache HTTPD instance), please provide
output of a TCP dump for tests. Let's make sure that all the bases are
covered.

> About Caddy, I do not want to install another server and deal with
> another config.

I can fully understand and appreciate that.

> Thanks!

You're welcome.