Edit: The last couple of days I have tried to gather some information of why the service won't start. Unfortunately there is not much information that can help me for specific installations on FreeBSD. But I have tried the following commands, with the output I get. I don't know if someone can see why it fails.

/usr/local/etc/rc.d/haproxy start:
WARNING: failed precmd routine for haproxy
/usr/local/etc/rc.d/haproxy enable:
haproxy enabled in /etc/rc.conf
/usr/local/etc/rc.d/haproxy status:
haproxy is not running.
/usr/local/etc/rc.d/haproxy configtest:
Configuration file has no error but will not start (no listener) => exit(2).
haproxy -f /usr/local/etc/haproxy.conf -p /var/run/haproxy.pid:
[ALERT] 070/102644 (18074) : [haproxy.main()] No enabled listener found (check for 'bind' directives) ! Exiting.

Also, what I've done so far:

Set the protocol for the webConfigurator to https Changed the TCP port to something other than 443 Turned on the Disable webConfigurator redirect rule

Some other information that might be important:

When I click on the (I don't know what else to call it) play button, the gear will load for a few seconds, then reload and then silently fail. Because the Haproxy service isn't enabled, I can't save the change made in settings of; Enable HAProxy.

If anyone has an idea of what might be happening, please let me know because I'm out of idea's.

I was able to solve this by following the HAProxy documentation regarding HTTP to HTTPS redirect.

Adding unless { ssl_fc } to my ACL action on the front end got rid of the error.

Now it looks like : scheme https unless { ssl_fc }

image-01.jpg image-02.jpg

Yeah, you wouldn't want to do that because the backend/frontend need to stay the same protocol.

But if you want to be able to enter fqdn.com and have that redirect to www.fqdn.com/home/somepage.htm you should be able to. And doing it there prevents HAProxy accidentally overmatching.

Steve

Got mine working here with Pfsense, HAProxy and the same Ansible script.
Matrix Federation Tester Output

{ "WellKnownResult": { "m.server": "", "result": "Get \"https://MYDOMAIN/.well-known/matrix/server\": x509: certificate has expired or is not yet valid: current time 2021-12-30T22:11:39Z is after 2019-07-20T00:20:42Z", "CacheExpiresAt": 0 }, "DNSResult": { "SRVSkipped": false, "SRVCName": "_matrix._tcp.MYDOMAIN.", "SRVRecords": [ { "Target": "matrix.MYDOMAIN.", "Port": 8448, "Priority": 10, "Weight": 0 } ], "SRVError": null, "Hosts": { "matrix.MYDOMAIN.": { "CName": "matrix.MYDOMAIN.", "Addrs": [ "MY.IP.Addr.Rss" ], "Error": null } }, "Addrs": [ "MY.IP.Addr.Rss:8448" ] }, "ConnectionReports": { "MY.IP.Addr.Rss:8448": { "Certificates": [ { "SubjectCommonName": "MYDOMAIN", "IssuerCommonName": "R3", "SHA256Fingerprint": "mNxQhNc5kh0y/m0M/lNmUT6tH/ZagjQ+yd/fHuKqwRA", "DNSNames": [ "MYDOMAIN" ] }, { "SubjectCommonName": "R3", "IssuerCommonName": "ISRG Root X1", "SHA256Fingerprint": "Z63RFmsCCuYbj1/JaBPATCqliZYHloZVcqPH5zdhPf0", "DNSNames": null }, { "SubjectCommonName": "ISRG Root X1", "IssuerCommonName": "DST Root CA X3", "SHA256Fingerprint": "bZn7Jl6xxbN0R2X8vGSPPNjhv/r9xML5m51Hz3/xwk8", "DNSNames": null } ], "Cipher": { "Version": "TLS 1.3", "CipherSuite": "TLS_AES_256_GCM_SHA384" }, "Checks": { "AllChecksOK": true, "MatchingServerName": true, "FutureValidUntilTS": true, "HasEd25519Key": true, "AllEd25519ChecksOK": true, "Ed25519Checks": { "ed25519:a_uphM": { "ValidEd25519": true, "MatchingSignature": true } }, "ValidCertificates": true }, "Errors": [], "Ed25519VerifyKeys": { "ed25519:a_uphM": "X9d+yyyMpzQ/KmWXvTScn13Iiki/k8H5tyxii9y64rw" }, "Info": {}, "Keys": { "old_verify_keys": {}, "server_name": "MYDOMAIN", "signatures": { "MYDOMAIN": { "ed25519:a_uphM": "huZnEh+oLK2aKPspuQx5iq12e0QO3I1igbx2vZ513awgDHPieRuw1JUitm1z+kvWWFu6ZCT7W1dBFHyIann3Cg" } }, "valid_until_ts": 1640988673800, "verify_keys": { "ed25519:a_uphM": { "key": "X9d+yyyMpzQ/KmWXvTScn13Iiki/k8H5tyxii9y64rw" } } } } }, "ConnectionErrors": {}, "Version": { "name": "Synapse", "version": "1.49.2" }, "FederationOK": true }

Your HAProxy Config would be helpfull

@viragomann Dachte ich mir schon, ist aber ist trotzdem schade. Irgendwas ist immer, vor allem wenn etwas einfach umzusetzen ist. Das ganze funktioniert ja überraschend gut, nur das die IP-Adressen von der anfragenden Quelle nicht an den HAProxy weitergereicht werden.

@piba see also https://github.com/pfsense/FreeBSD-ports/pull/1066

@piba

So after reading your comment, I installed the devel package and after working out the differences I needed to make that were version related, my OCSP stapling is now working again.

Thanks for the help.

@piba said in 2.4.5_1 PHP Error installing HAProxy:

unset($config['installedpackages']['haproxy']);
write_config("fix haproxy install, remove empty config");
print("config fixed?");

By Jove Sir, I think you got it.

I was able to install HaProxy.

that looks like solution.

Thank you for the quick response

@noplan said in Reverse proxy with HAProxy pointing to the firewall:

@Bob-Dig

Oh yes... I forgot that one

Move to something like 99443
Nothing like 80443 0r 8080

Smashed it out of the park =D thanks for that, needed to do some reading but moving the port seemed to do the trick.

@planetinse
Don't ask, read..
If the certificate is valid for the root domain, then its probably due to the acl's that get added, either check both boxes for checking subject/san, or uncheck them that should allow traffic to pass to the (default) backend. That is assuming you have indeed the same issue, if not, start a different topic please.

@pooperman

there is some issue with SSL handshake:

1.JPG

@PiBa Good news, I got it to work! I did as you suggested and got a self signed certificate on the server using this guide. After that HAProxy is able to route traffic to the host. It even works with the Let's Encrypt wildcard cert I have through the ACME package, so there's no cert errors getting to the site. Thank you for the help again.

@phoadm
Have you configured the haproxy webgui to 'monitor' a carp interface? If so it wont start on that node until that node becomes master.

@lido14
'Normally' IPFW is not running when only pfSense is used without captive-portal..

The quickest fix is probably to give pfSense a reboot.. Haproxy loads and configures IPFW if it 'needs' transparent-client-ip with its current config settings.. If none of the backends require this the IPFW related configuration code is likely completely skipped. It does not remember that it still needs to disable the old ipfw settings.... I guess i need to set a little 'flag' that transparent-client-ip was used and check that to remove the last rules if the current config doesn't use it anymore.. I'm not sure if unloading ipfw itself is possible.. i think there was a issue there...

@crowfather

I get that the backend limit is 1/10th the front end... but still not sure what this resolves.

If you set the front-end to 500 does that mean the back-end is really 500 but is only showing 50. Should we be setting it to 10X the value we want or is it that it only incorrectly displays this way?

--Nikolaos

TLS 1.3 will require OpenSSL 1.1.x, which is only currently available on pfSense 2.5.0 development snapshots. Though it does look like net/haproxy-devel is at 2.0-dev2 on the branch used for pfSense 2.5.0 development, but the pfSense haproxy-devel package doesn't use it (yet).

I'm not aware of any plans to switch that over yet, but it's probably just a matter of time.

Do it even easier:

Run acme package on FW1 (I assume it's a CARP cluster with syncing?) and let it create a certificate for both names (fw1.xxx AND fw2.xxx). When it's done, select the cert for the webui. Then login to FW2 and select it, too, as certificates get synchronized automatically (if selected) to the secondary. There choose the same certificate as WebUI cert and be done :)

Just check that you configure the acme service on fw1 to restart its own webserver after renewal AND via remote the service on fw2 (see the help for this)!

Greets

Will be nice to learn how to do it both ways - using haproxy and just using the internal CAs as @johnpoz proposes. I went the haproxy route and couldnt get it to work. I have the certs issued and haproxy setup. Perhaps @Renat you can provide a guide how to do it and I will see if that can get me over the hump since I have already done most of the steps? ( some screenshots of haproxy setup). Also anything has to be done on the synology side?

@interloper Do you have a guide on how you setup your google domain settings for your subdomains? I am trying to figure it out but having a hard time. Here is my open topic on this forum (https://forum.netgate.com/post/830593).

Thanks

The benefit is that you don't need to use port forwarding at all and you only need to have one port open. You can have HAproxy listen on the WAN on port 443 and send requests to the appropriate backend server based on the requested URL.
You don't have to remember what port the services are running on externally just the FQDN.
It isn't necessarily any more secure though. You only have one firewall rule on WAN so you can't apply different rules to each service at the firewall level. Connection limiting, traffic shaping etc.
You still can have HAprxy listen on different ports though if you found you needed that.

Steve

I moved the galaxy backend to the ssl offload fronted.

Added a custom ACL and used this https://stackoverflow.com/questions/23342036/haproxy-restrict-single-backend-by-ip-range

@jimp could you point me in the right direction how to setup so HAProxy on pfSense handels the certs ( not just getting them )

That was it, thank you for your help!

Probably not in this case.