# Simple reverse proxy configuration

**URL:** <https://community.ipfire.org/t/simple-reverse-proxy-configuration/13128>\
**Category:** Routing\
**Created:** [4 November 2024 14:16 UTC](https://community.ipfire.org/t/simple-reverse-proxy-configuration/13128 "2024-11-04T14:16:48Z")\
**Posts on this page:** 4\
**Page:** 2

<div class="post-metadata">

**Author:** ![dr\_techno](https://community.ipfire.org/user_avatar/community.ipfire.org/dr_techno/32/15388_2.png) [@dr\_techno](https://community.ipfire.org/u/dr_techno)\
**Post date:** [16 November 2024 10:46 UTC](https://community.ipfire.org/t/simple-reverse-proxy-configuration/13128/21 "2024-11-16T10:46:34Z")

</div>

What gets me asking is why the use of HA proxy configuration when this looks like a simple changes in the sites-available after re-reading this:

> [@rowihei](#):
>
> But there is a web server in green at IP 172.20.20.219.  
> At the time we had an port forwarding rule:  
> **all port 7443 \>\> 172.20.20.219 port 443**  
> That’s OK, but a long http string to input:
> 
> > _[https://xxxx.yyy-zzzzzzz.de:7443/aaweb](https://xxxx.yyy-zzzzzzz.de:7443/aaweb)_
> 
> We thought, that we could simplify this long string to:
> 
> > _[https://aaweb.yyyy-zzzzzzz.de](https://aaweb.yyyy-zzzzzzz.de)_

So they have a nginx site at 172.20.20.219  
a hostname [xxxx.yyy-zzzzzzz.de](http://xxxx.yyy-zzzzzzz.de) is entered into hosts in ipfire

so their default file in sites available should be:

```auto

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html;
        index index.html index.htm index.nginx-debian.html;
        server_name http://xxxx.yyy-zzzzzzz.de;
        location / {
                        try_files $uri $uri/ =404;
                       }
}

```

There should be a new file created and I would name it aaweb and I would create it by going to the sites-available folder in a terminal as root and `cp -p default aaweb`

Then I would edit the new file aaweb for the site [aaweb.yyyy-zzzzzzz.de](http://aaweb.yyyy-zzzzzzz.de)

```auto

server {
    listen 80;
    server_name aaweb.yyyy-zzzzzzz.de;
    
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    server_name aaweb.yyyy-zzzzzzz.de;
    ssl_certificate /path/to/aaweb.yyyy-zzzzzzz.de.crt;
    ssl_certificate_key /path/to/aaweb.yyyy-zzzzzzz.de.key;
    root /var/www/html/aaweb;
    index index.html index.htm index.nginx-debian.html;
           location / {
                        try_files $uri $uri/ =404;
                       }
}

```

Next, I would enable the site aaweb:

`sudo ln -s sites-available/aaweb sites-enabled/`

Then add [aaweb.yyyy-zzzzzzz.de](http://aaweb.yyyy-zzzzzzz.de) as a host entry in ipfire pointing to 172.20.20.219

Then if [aaweb.yyyy-zzzzzzz.de](http://aaweb.yyyy-zzzzzzz.de) is access http or https then its going to [https://aaweb.yyyy-zzzzzzz.de](https://aaweb.yyyy-zzzzzzz.de)

I think what they wanted to do is two sites at 172.20.20.219 but one is a http and another, a http by what they say.

---

<div class="post-metadata">

**Author:** ![firewire](https://community.ipfire.org/user_avatar/community.ipfire.org/firewire/32/16590_2.png) [@firewire](https://community.ipfire.org/u/firewire)\
**Post date:** [16 November 2024 15:26 UTC](https://community.ipfire.org/t/simple-reverse-proxy-configuration/13128/22 "2024-11-16T15:26:35Z")

</div>

I think running `172.20.20.219` on GREEN as dedicated webserver isn’t that nice anyway. May be something pre-conditioned like a NAS or such.

Aside of that, your latter nginx solution shall be okay, and I think you are right when you say that solves the problem. ☮

Please note I just wanted to suggest an alternative as part of the initial request based on my latter experiences I’ve had with HAProxy, which, BTW, may not be sufficient enough and I’m still testing around on my installations.

> I think what they wanted to do is two sites at 172.20.20.219 but one is a http and another, a http by what they say.

I think the inital question was on HTTPS only but due to the `haproxy.cfg` posted afterwards it may appear as a Port 80 frontend to be designed for a port 443 backend. What indeed may work but I think is not intended.

---

<div class="post-metadata">

**Author:** ![nickh](https://community.ipfire.org/user_avatar/community.ipfire.org/nickh/32/9845_2.png) [@nickh](https://community.ipfire.org/u/nickh)\
**Post date:** [16 November 2024 17:35 UTC](https://community.ipfire.org/t/simple-reverse-proxy-configuration/13128/23 "2024-11-16T17:35:39Z")

</div>

In haproxy, I think most normal is ports 80/443 front end with port 80 back end so haproxy looks after the certification.

A 443 front and back end to me seems odd in some ways. because it means the back end server the backend server has an encryption overhead then haproxy has to decrypt it and re-encrypt it which seems a awful waste of processing unless you have a requirement to keep everything totally secure like a bank or credit card processing comapny.

---

<div class="post-metadata">

**Author:** ![firewire](https://community.ipfire.org/user_avatar/community.ipfire.org/firewire/32/16590_2.png) [@firewire](https://community.ipfire.org/u/firewire)\
**Post date:** [17 November 2024 09:02 UTC](https://community.ipfire.org/t/simple-reverse-proxy-configuration/13128/24 "2024-11-17T09:02:25Z")

</div>

I reflected a bit on the setup and wonder if that whole thing would work as there are servers hanging in the DMZ which are handled via port forwarding and then there is this server on GREEN via HAProxy.

[Previous page](https://community.ipfire.org/t/simple-reverse-proxy-configuration/13128.md?page=1)