Messages

1

High availability / Re: HAProxy 4.3 Broken with Cloudflare Origin Cert and OCSP Automatic Update

« on: February 08, 2024, 11:57:27 pm »

I fixed it. Documenting this if anyone comes across this same issue in the future.

TLDR: Import the Cloudflare CA to your Authorities

The haproxy plugin in 4.1 was the bugged version. The updated plugin in 4.1.1 corrected the bug.

The valid syntax for the configuration is to have the [ocsp-update on] in brackets. So the reason my config worked on 4.1 is because the ocsp-update on parameter was invalid and not interpreted by the haproxy engine. 4.1.1 corrected the syntax and highlighted my actual issue which is that I needed to install the Certificate Authority for the Cloudflare Origin Certificate. This was made evident because the error states that, maybe the issuer could not be found. This refers to the .issuer file under the directory, /tmp/haproxy/ssl/, there was no .issuer file here for me.

I went here and downloaded the CA for my cert (ECC in my case)...
https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/#cloudflare-origin-ca-root-certificate

Then I imported into System > Trust > Authorities, applied my haproxy configuration, and I got no error message in the GUI. The .issuer file appeared in the /tmp/haproxy/ssl/ directory.

Now everything works.

Thanks to these two folks, rlebreton and fraenki, for pointing me in the right direction on GH.
https://github.com/haproxy/haproxy/issues/2432#issuecomment-1935042531

2

High availability / Re: HAProxy 4.3 Broken with Cloudflare Origin Cert and OCSP Automatic Update

« on: February 07, 2024, 10:26:16 pm »

Confirmed the issue was introduced with yesterday's update.

I reverted the haproxy plugin to 24.1's version...

Code: [Select]

opnsense-revert -r 24.1 os-haproxy
And now haproxy is working with the Cloudflare Origin cert and Automatic OCSP Updates enabled.

The only delta I see so far is the fact that the contents of the /tmp/haproxy/ssl/659dc76096fe83.76462299.certlist file doesn't have [] anymore...

/tmp/haproxy/ssl/65c3e946c3ef1.pem ocsp-update on

vs

/tmp/haproxy/ssl/65c3e946c3ef1.pem [ocsp-update on]

Not sure if that makes a difference...

3

High availability / HAProxy 4.3 Broken with Cloudflare Origin Cert and OCSP Automatic Update

« on: February 07, 2024, 06:57:58 pm »

I updated my OPNsense firmware yesterday to 24.1.1 and according to the changelog, that included an update to HAProxy, version 4.3 (2.8.5-aaba8d0). I didn't reboot until this morning and I noticed my HAProxy service was stopped. I tried restarting it to no avail so I went to settings and checked the syntax where I got the following error...

Code: [Select]

[NOTICE] (62651) : haproxy version is 2.8.5-aaba8d0
[NOTICE] (62651) : path to executable is /usr/local/sbin/haproxy
[ALERT] (62651) : config : parsing [/usr/local/etc/haproxy.conf.staging:73] : 'bind 127.4.4.3:443' in section 'frontend' : 'crt-list' : error processing line 1 in file '/tmp/haproxy/ssl/659dc76096fe83.76462299.certlist' : '/tmp/haproxy/ssl/65c3b55f42923.pem' has an OCSP URI and OCSP auto-update is set to 'on' but an error occurred (maybe the issuer could not be found)'.
[ALERT] (62651) : config : Error(s) found in configuration file : /usr/local/etc/haproxy.conf.staging
[ALERT] (62651) : config : Fatal errors found in configuration.
I googled and found the following issue on the HAProxy Github...
https://github.com/haproxy/haproxy/issues/2432

The issue being described in here is with regards to HAProxy producing this error message when evaluating a self-signed certificate with no URI declared in the pem file. This isn't my exact case as the Cloudflare origin cert I'm using does have a URI defined...

Code: [Select]

root@OPNsense:~ # openssl x509 -noout -text -in /tmp/haproxy/ssl/65c3b55f42923.pem | grep URI
OCSP - URI:http://ocsp.cloudflare.com/origin_ecc_ca
URI:http://crl.cloudflare.com/origin_ecc_ca.crl
The workaround is to disable 'Automatic OCSP updates' under Settings > Global Parameters > SSL settings. This allows me to use my Cloudflare Origin cert and keep the SSL/TLS encryption mode in Cloudflare to Full(Strict).

I can also keep 'Automatic OCSP updates' turned on, use any self-signed certificate for the HTTPS frontend public service, and dial back my SSL/TLS encryption mode in Cloudflare to Full(Not Strict).

Is anyone else experiencing this issue?

Also, side note...

I followed the amazing guide by TheHellSite...
https://forum.opnsense.org/index.php?topic=23339.0

Looks like it was recently updated to state, "OCSP updates are now built into HAProxy. No external Cron job is necessary anymore." AND it instructs you to add 'strict-sni' to the SSL Offloading section on your https frontend. This breaks my websites. Why?

4

Virtual private networks / Re: Outbound NAT rule for WireGuard client Session

« on: January 09, 2024, 09:24:29 pm »

I figured it out and boy do I feel silly lol

I needed to set the interface to the one for WireGuard (PAV)

5

Virtual private networks / Outbound NAT rule for WireGuard client Session

« on: January 09, 2024, 08:50:25 pm »

I think I need an Outbound NAT rule but I have no idea how to construct it to allow clients behind my opnsense router to reach the remote network through the vpn tunnel NATing from the tunnel IP.

I have my WireGuard connection up and running. My opnsense router is the client and it's connected to a remote WireGuard server. I configured an interface for the WireGuard connection (PAV) so that I can create a gateway and static route to the remote subnet.

I am able to ping the remote network from my router and from a single host in my DMZ because of the fact that the 'AllowedIPs' on the server config permits the opnsense client, 10.80.190.2, and a single server in my DMZ, 192.168.0.251, for Syncthing functionality.

An easy fix would be to put my local subnets on the remote WireGuard server AllowedIPs and then everything can talk to one another. However, I much rather have all of my local clients NAT through the WireGuard client IP, 10.80.190.2.

I followed the steps outlined in the following article...
https://docs.opnsense.org/manual/how-tos/wireguard-client.html
...to no avail.

I attached a picture of the Outbound NAT rule as it is now.

Please help. Thank you

6

General Discussion / Re: 24.1 Potentially the "Last one"?

« on: January 08, 2024, 05:34:22 pm »

oh, well that makes a lot more sense considering the preceding sentence...

"The final test phase for 24.1 is starting just as 23.7 strechtes towards
its inevitable end of life."

I feel embarrassed that I didn't read into the context of the sentence that caused me concern. I suppose I'm jumpy considering the situation with the other guys and licensing lol

Thank you for clarifying

7

General Discussion / 24.1 Potentially the "Last one"?

« on: January 08, 2024, 05:21:10 pm »

Hello,

Brand new potential convert from the other guys. Apologies if this has already been asked and answered.

I'm currently fielding OPNsense on a VM before putting it on bare metal production in my home lab. I noticed the changelog message when updating the firmware...

"...At the moment it is unlcear if this release
will be the last one or not so we shall refrain from stating something that
may not be true in the coming weeks."

Can you expand on this?

The fear I have is going through the process of migrating my environment over to OPNsense only to be met with a similar subscription model or the project itself being dropped.

Thank you very much and I hope to be fully converted over and using this service soon. I appreciate all of the work you guys have put in to make a great product.