[ha-proxy] SSL Offloading stopped working after some time (update)

[hopey]

Hello together 

I have an issue with my (once working) HA-Proxy 🙄 It is used to offload the (Letsencrypt) SSL certificate for my server instances (nextcloud and truenas) - I thought this is the more elegant way, then copying the certificate to the servers on every Letsencrypt update. But it stopped working (I have automativ updates activated) with following error message:

Code: [Select]

[NOTICE] (46781) : haproxy version is 2.4.15
[NOTICE] (46781) : path to executable is /usr/local/sbin/haproxy
[ALERT] (46781) : parsing [/usr/local/etc/haproxy.conf.staging:44] : 'bind' : invalid address: 'nextcloud.<domain>.de' in 'nextcloud.<domain>.de:443'
[ALERT] (46781) : parsing [/usr/local/etc/haproxy.conf.staging:45] : 'bind' : invalid address: 'truenas.<domain>.de' in 'truenas.<domain>.de:443'
[ALERT] (46781) : Error(s) found in configuration file : /usr/local/etc/haproxy.conf.staging
[ALERT] (46781) : Fatal errors found in configuration.
I don't really understand this Error. For sure the address is not present - HA-Proxy should listen at this adress.

When I give the servers the hostname (used for listening) in the static dhcp table or via Unbound DNS, the Error vanishes and I can safe the config. ...but HA - Proxy does not work (I can imagine the request will be directly rooted to the servers instead of going through the Proxy).

I think a good analysis start is the config opnsense generates:

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
    nbproc                      1
    nbthread                    1
    hard-stop-after             60s
    no strict-limits
    tune.ssl.default-dh-param   1024
    spread-checks               0
    tune.bufsize                16384
    tune.lua.maxmem             0
    log                         /var/run/log local0 info
    lua-prepend-path            /tmp/haproxy/lua/?.lua

defaults
    log     global
    option redispatch -1
    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: frontend_ssl_injection ()
frontend frontend_ssl_injection
    bind nextcloud.<domain>.de:443 name nextcloud.<domain>.de:443 ssl  crt-list /tmp/haproxy/ssl/620b750b826711.38878536.certlist
    bind truenas.<domain>.de:443 name truenas.<domain>.de:443 ssl  crt-list /tmp/haproxy/ssl/620b750b826711.38878536.certlist
    mode http
    option http-keep-alive
    # tuning options
    timeout client 30s

    # logging options
    option httplog
    # ACL: nextcloud_bedingung
    acl acl_620ba6f6251f72.51186815 hdr_beg(host) -i nextcloud
    # ACL: truenas_bedingung
    acl acl_620bbec7c8bf05.22443063 hdr_beg(host) -i truenas

    # ACTION: nextcloud_regel
    use_backend nextcloud_backend if acl_620ba6f6251f72.51186815
    # ACTION: truenas_regel
    use_backend truenas_backend if acl_620bbec7c8bf05.22443063

# Backend: nextcloud_backend ()
backend nextcloud_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 nextcloud_server XX.XX.XX.XX:443 ssl verify none

# Backend: truenas_backend ()
backend truenas_backend
    # health checking is DISABLED
    mode http
    balance uri
    # stickiness
    stick-table type ip size 50k expire 30m 
    stick on src
    # tuning options
    timeout connect 30s
    timeout server 30s
    http-reuse safe
    server truenas_server YY.YY.YY.YY:443 ssl verify none

# Backend (DISABLED): brother_backend ()

listen local_statistics
    bind            127.0.0.1:8822
    mode            http
    stats uri       /haproxy?stats
    stats realm     HAProxy\ statistics
    stats admin     if TRUE

# statistics are DISABLED

I might have missunderstood this proxy completely 😬 Hopefully you can help - please ☕

Have a nice day!
Matthias

[hopey]

It seemed to have worded because of a kernel setting, that might have changed later on (the kernel seems to prevent now from binding haproxy to an adress used anywhere else).

I found a solution on my own now... Read the tutorial: https://schulnetzkonzept.de/opnsense and came to the idea to add a virtual IP (Interfaces / Virtual IPs / Settings → Add, Mode IP Alias).
This virtual address is now used to let haproxy listen on.
Via Unbound DNS (Services / Unbound DNS / Overrides / Host Overrides → Add) I map my subdomains to this one virtual Adress and erverything is working like charm!

Have a nice day!

[Bunch]

Nice work.
But, do you only need to access your services in LAN?

The key word: bind
means you assigns a listener to a specific port of an IP
*You cannot bind 2 services in same port of same IP

Obviously you can create a VIP and bind to it, then create a local DNS record that points to the VIP.
Let say your Firewall LAN IP is 10.0.0.1, WAN IP is 1.2.3.4, website you host is 10.0.0.2:443, VIP you created is 10.1.0.1, SNI you want to redirect to the website is the.website.com

In LAN environment, you tried to access https://the.website.com
You browser asked the system about the IP of the.website.com. PC asked DNS server about the IP of the.website.com
Unbounded DNS server replies that it is 10.1.0.1.
Your browser tried to access 10.1.0.1:443 and sent a TLS package with SNI=the.website.com
Haproxy frontend handled TLS etc. and forward packages to 10.0.0.2:443.
So, In LAN environment, it should work.

In WAN environment.
Assume that you use DDNS service, and set the.website.com points to 1.2.3.4 in public. You opened port 443 to public.
As opnsense is listening to 0.0.0.0:443, which means it is listening to port 443 of ANY IP which can represent your firewall.
(10.0.0.1:443 and 1.2.3.4:443 in this case)
Your mobile device using 2.3.4.5 asked GoogleDNS to resolve the.website.com, and it resolves with 1.2.3.4.
You tried to assess 1.2.3.4:443 and send a TLS package with SNI: the.website.com.
It will give you opnsense page without asking haproxy, which is dangerous.

Recommend you add a NAT rule if you need WAN access
Interface: WAN
Source: Any
Destination: WAN address
Port 443
Redirect target IP: Your VIP