Tutorial 2024/06: HAProxy + Let's Encrypt Wildcard Certificates + 100% A+ Rating

[bringha]

Hi there,

I tried to activate DDNS via the API with ionos as suggested but miserably failed yet.  Might be somewhat unusual but I only want to activate DDNS for two subdomains, not my entire domain ‚domain.com‘ (only ‚sub.domain.com‘).

 I come up to the step that I have created my update URL, the server responds with 200 properly on the Ionos API page. This should then have activated DDNS for the requested subdomains according to the doc. However there is the no entry for these subdomain on the DNS page.

When I  apply Update URL  in the opnsense dyndns config and press ‚save and enforce update‘, my public IP is properly shown in the opnsense dyndns config page.  But still the subdomain is not shown as a DynDNS subdomain at ionos ..
as to be feared there is also no DNS with my public IP for the subdomain distributed …

Do i miss a step ?? I am looking forward to any idea.

Br br

[N0_Klu3]

FYI I got it working the Basic Auth.

So 21.7.4 has an issue with HAProxy where changes to config are not being saved: https://forum.opnsense.org/index.php?topic=25480.0
After I applied the patch it is working.

For Basic Auth all I did was create a user under User Management
(There does seem to be some restrictions around password length or complexity, I didnt spend a load of time testing)
My 20+ Char passwords would not work until I dumbed it down a bit.

So once you have a user go to your Backend Pools, choose your desired service, scroll down to Basic Authentication -> tick the box and add the username you just created.

Boom it works.

[TheHellSite]

Hi there,

I tried to activate DDNS via the API with ionos as suggested but miserably failed yet.  Might be somewhat unusual but I only want to activate DDNS for two subdomains, not my entire domain ‚domain.com‘ (only ‚sub.domain.com‘).

 I come up to the step that I have created my update URL, the server responds with 200 properly on the Ionos API page. This should then have activated DDNS for the requested subdomains according to the doc. However there is the no entry for these subdomain on the DNS page.

When I  apply Update URL  in the opnsense dyndns config and press ‚save and enforce update‘, my public IP is properly shown in the opnsense dyndns config page.  But still the subdomain is not shown as a DynDNS subdomain at ionos ..
as to be feared there is also no DNS with my public IP for the subdomain distributed …

Do i miss a step ?? I am looking forward to any idea.

Br br

Your issue is related to DynDNS I think you should fix that first and ask for help at the right place.
Maybe use google "how to set up a DynDNS subdomain at IONOS".
https://www.ionos.de/hilfe/domains/ip-adresse-konfigurieren/dynamisches-dns-ddns-einrichten-bei-company-name/

I am sorry, but since I am not using IONOS you will have to figure out their specifics on your own.
The only differences to my guide will be the DynDNS setup and the DNS challenge specifics for the ACME Client. Everything else is the same.

FYI I got it working the Basic Auth.

So 21.7.4 has an issue with HAProxy where changes to config are not being saved: https://forum.opnsense.org/index.php?topic=25480.0
After I applied the patch it is working.

For Basic Auth all I did was create a user under User Management
(There does seem to be some restrictions around password length or complexity, I didnt spend a load of time testing)
My 20+ Char passwords would not work until I dumbed it down a bit.

So once you have a user go to your Backend Pools, choose your desired service, scroll down to Basic Authentication -> tick the box and add the username you just created.

Boom it works.

Just tested it out myself. Basic Auth is so easy to set up that I am not really willing to cover it in this guide.
First create the user(s) in HAProxy. Then in the relevant backends activate basic auth and select the user(s).

The issue you are facing with your password is the way you included them in your config!
You will need to SHOULD use a password hash not the plain text password in the user management box.
Otherwise your passwords are visible in plain text in the config export.

Generate password hash using OpenSSL binary
1. (WINDOWS ONLY) Download the openssl binary, f.e. from here: http://wiki.overbyte.eu/wiki/index.php/ICS_Download#Download_OpenSSL_Binaries_.28required_for_SSL-enabled_components.29
2. (Windows) Open CMD in the directory of the binary file / (Linux) open the shell.
3. Run "openssl passwd -6" and enter your password.
4. Enter the generated password hash in the password field of the user in HAProxy Settings.

[lilsense]

I am having issues with modifying config which will not take effect.

as an example when attempting to modify default-dh-param from 2048 to 4096, the save and apply works but the config export is not updated.

[lilsense]

It was fixed after the latest update, however, I am still having connections issues... I am getting handshake failures.

Code: [Select]

#
# Automatically generated configuration.
# Do not edit this file manually.
#

global
    uid                         80
    gid                         80
    chroot                      /var/haproxy
    daemon
    stats                       socket /var/run/haproxy.socket group proxy mode 775 level admin expose-fd listeners
    nbproc                      1
    nbthread                    4
    hard-stop-after             60s
    maxconn                     10000
    tune.ssl.default-dh-param   4096
    spread-checks               2
    tune.chksize                16384
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 debug
    lua-prepend-path            /tmp/haproxy/lua/?.lua

defaults
    log     global
    option redispatch -1
    maxconn 5000
    timeout client 30s
    timeout connect 30s
    timeout server 30s
    retries 3
    default-server init-addr last,libc

# autogenerated entries for ACLs


# autogenerated entries for config in backends/frontends

# autogenerated entries for stats




# Frontend: 0_SNI_Frontend (listening on 0.0.0.0:80 and 0.0.0.0:443)
frontend 0_SNI_Frontend
    bind 0.0.0.0:443 name 0.0.0.0:443
    bind 0.0.0.0:80 name 0.0.0.0:80
    mode tcp
    default_backend SSL_Backend
    # tuning options
    timeout client 30s

    # logging options

# Frontend: 1_HTTP_Frontend (Listening on 192.168.1.50:80)
frontend 1_HTTP_Frontend
    bind 192.168.1.50:80 name 192.168.1.50:80 accept-proxy
    mode http
    option http-keep-alive
    option forwardfor
    # tuning options
    timeout client 30s

    # logging options
    # ACL: NOSSL_Condition
    acl acl_60f9d6d0118252.11362730 req.ssl_ver gt 0

    # ACTION: HTTPtoHTTPS_Rule
    http-request redirect scheme https code 301 if !acl_60f9d6d0118252.11362730

# Frontend: 1_HTTPS_Frontend (listening on 192.168.1.50:443)
frontend 1_HTTPS_Frontend
    http-response set-header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    bind 192.168.1.50:443 name 192.168.1.50:443 accept-proxy ssl curves secp384r1  no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384 ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256 alpn h2,http/1.1 crt-list /tmp/haproxy/ssl/60f9db5421ce96.24863488.certlist
    mode http
    option http-keep-alive
    option forwardfor
    # tuning options
    timeout client 15m

    # logging options

    # ACTION: Public_Sub_MapRule
    # NOTE: actions with no ACLs/conditions will always match
    use_backend %[req.hdr(host),lower,map_dom(/tmp/haproxy/mapfiles/61698448328ff6.66158166.txt)]

# Backend: SSL_Backend ()
backend SSL_Backend
    # health checking is DISABLED
    mode tcp
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    server HAP_VIP 192.168.1.50 send-proxy-v2 check-send-proxy

# Backend: TruePlex_Backend ()
backend TruePlex_Backend
    # health checking is DISABLED
    mode http
    balance source
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server TruePlex 192.168.1.12:32400 ssl verify none


[TheHellSite]

It was fixed after the latest update, however, I am still having connections issues... I am getting handshake failures.

From all client devices or just your smart TV(s)?
Does web browser access work?

[lilsense]

From all clients, nothing works.

I can connect to the plex with the local IP without an issue.

[TheHellSite]

From all clients, nothing works.

I can connect to the plex with the local IP without an issue.

1. Post a screenshot of your entire SSL Labs result. But black out any personal information from it, i.e. domain name, public IP,... You can also send me a personal message with the result link.
https://www.ssllabs.com/ssltest/


2. Go to "OPNsense --> System --> Trust --> Authorities" and post a screenshot of that page. If you want, you can black out all lines that don't have "Let's Encrypt" the name.

[lilsense]

There's an unknown cert and Cloudflare. I'll sent it in a bit.

[TheHellSite]

I thought you were asking about an HAProxy + Let's Encrypt issue...

Since you are using cloudflare certificates I am unable to help you. You are better off asking for help in the HAProxy forums or the cloudflare support regarding your issues.

Let me finish by giving you these informations:
1. The SSL Labs test pictures you sent me indicate that your certificate content (cn + alt name) seems to be wrong.
2. Your HAProxy HTTPS frontend settings do not match the ones I provide in my guide.


You could however just follow my tutorial step by step and would end up with a working setup.

[cookiemonster]

Thanks TheHellSite for the time taken to share the setup and help people.
This is my first foray into HA because I wanted to open traffic to a webserver on my lan for the first time. First I was going to just forward the port on OPN but then I saw your post and realised we can get so much more functionality from HA and your setup suggestion.

I have setup my webserver (nginix) to listen on custom port say 8082, and there is where I got the letsencrypt & dedyn.io setup first, as a kid of test before moving to OPN.
I've now done the cert as per your guide, essentially moved cert infrastrucure from the real server to OPN. All is good.

I've done the "pre-requisites" in my mind. I'm getting ready to string it together and then my question if I may.

Part 4, step 1. It says to change OPN Admin interface to another port(s) for http and https, usual 80, 443 because HA would expect traffic there.
Is it obligatory or could I keep my real server on 8082 and setup HA to exect that and keep OPN as is on 80 & 443?
I expect to use https with a self signed cert on the real server -instead of the current cert now in OPN-, or maybe only http on that port at the beginning.
Thanks.

[lilsense]

I thought you were asking about an HAProxy + Let's Encrypt issue...

Since you are using cloudflare certificates I am unable to help you. You are better off asking for help in the HAProxy forums or the cloudflare support regarding your issues.

Let me finish by giving you these informations:
1. The SSL Labs test pictures you sent me indicate that your certificate content (cn + alt name) seems to be wrong.
2. Your HAProxy HTTPS frontend settings do not match the ones I provide in my guide.


You could however just follow my tutorial step by step and would end up with a working setup.

I am not sure what I am missing... I went over the HA HTTPS Frontend a dozen times and I am not seeing what's not matching...

[TheHellSite]

Part 4, step 1. It says to change OPN Admin interface to another port(s) for http and https, usual 80, 443 because HA would expect traffic there.
Is it obligatory or could I keep my real server on 8082 and setup HA to exect that and keep OPN as is on 80 & 443?
I expect to use https with a self signed cert on the real server -instead of the current cert now in OPN-, or maybe only http on that port at the beginning.
Thanks.

You can run your real servers (f.e. nginx web server) on whatever port you like (80, 443, 50443, ......) that doesn't matter at all.
The reason why you have to change the OPNsense web server port is quite simple.

OPNsense is obviously running a built in webserver by default (LAN INTERFACE / PORT 443), otherwise you wouldn't be able to access the web interface at all.
HAProxy is listening on ALL INTERFACES by default.

Web Server = Interface = IP:Port
HAProxy = ALL = 0.0.0.0:0 or 0.0.0.0:80+443
OPNsense = LAN = 192.168.1.1:443

This is the conflict! You can't have two or more services listening on the same "Interface + IP:Port". How would they know which traffic belongs to whom? As soon as one of them grabs the traffic the other one will never get it.

TL;DR:
1. Yes, you can run your real servers on any port (f.e. 8082).
2. No you can't change the OPNsense back to port 443 because you wouldn't be able to reach the OPNsense web interface anymore and or HAProxy will refuse to start.
3. I strongly advise you to also run your real server(s) with a self-signed SSL certificate to increase security. It is however not necessary.

[TheHellSite]

I am not sure what I am missing... I went over the HA HTTPS Frontend a dozen times and I am not seeing what's not matching...

As I already said, it has something to do with your cloudflare domain config!

[cookiemonster]

Web Server = Interface = IP:Port
HAProxy = ALL = 0.0.0.0:0 or 0.0.0.0:80+443
OPNsense = LAN = 192.168.1.1:443

This is the conflict! You can't have two or more services listening on the same "Interface + IP:Port". How would they know which traffic belongs to whom? As soon as one of them grabs the traffic the other one will never get it.

TL;DR:
1. Yes, you can run your real servers on any port (f.e. 8082).
2. No you can't change the OPNsense back to port 443 because you wouldn't be able to reach the OPNsense web interface anymore and or HAProxy will refuse to start.
3. I strongly advise you to also run your real server(s) with a self-signed SSL certificate to increase security. It is however not necessary.

Thank you for taking the time to answer. The problem with conflicting ip+ports is one I understand but I failed to articulate my question to explain what I meant.
I have been following the guide step by step, back and forth to understand each part. I made a little diagram for me to understand it better. I hope you don't mind if I spoil your thread with it. It just works for me to understand and better ask a question.

Essentially my question was if I could bind the SNI front end internally to a custom port instead of the usual 80,443. I probably should think again if what I'm asking is a sane question.
I've used this diagram and read&re-read your guide and I think I have a better grasp on it.
The nginx in my picture is me trying to figure out where/how I need to do the setup for my use. I hope I have not misrepresented it.
Let me come back with a better question when I've tested things. Much obliged.