Messages

Could you please post your config?

Have you got the frontend set to SSL / HTTPS TCP mode?

https://cbonte.github.io/haproxy-dconv/2.1/configuration.html#7.3.3-src_is_local

src_is_local : boolean
Returns true if the source address of the incoming connection is local to the
system, or false if the address doesn't exist on the system, meaning that it
comes from a remote machine. Note that UNIX addresses are considered local.
It can be useful to apply certain access restrictions based on where the
client comes from (e.g. require auth or https for remote machines). Please
note that the check involves a few system calls, so it's better to do it only
once per connection.

So... If I read that correctly, it would work if the IP is local to the FW i.e. an interface IP.

Have you tried using "Source IP matches a specific IP" with a range i.e 10.0.0.0/24?

Could you please post what you currently have in your haproxy config?

I have found Smokeping very good at providing graphs to strengthen the case with your ISP: https://oss.oetiker.ch/smokeping/index.en.html

You will need to run it on an internal server - a Raspberry Pi will do just fine.

On a Debian based system run 'sudo apt-get install smokeping' to get started.

Bart...

Second the suggestion for smoke ping. Though I've started to more and more use Zabbix as it'll give me the functionality of smokeping and a whole lot more... I've got zabbix set up to not only monitor connections but system resources, interface statistics etc of my FW and servers.

So firstly, obfuscating ports really doesn't help... IP's and domains but ports make it hard to assist in diagnosing the problem.

In regards to the order of rules... You don't need anything fancy and it will currently work in HAProxy on Opnsense... Just drag what you want first to the front of the list. Examples attached.

ACL order should matter because at the moment with your config it'll always hit the third rule and stop there.

I personally prefer to have everything separated... HTTP to HTTPS Upgrades in a separate frontend, HTTPS Offloading on another, but I also use Let's Encrypt with DNS-01 so I don't have to worry about LE needing to traverse HAProxy.

Also I don't know much about PFSense and how the Primary and Shared front ends work but I've always tried to keep it that each front end has one job to do.

Could you please post your config so we can have a look?
So for Let's Encrypt you are doing the HTTP-01 challenge from a certain backend? Have a look at this as this might help you get what you're after https://serversforhackers.com/c/letsencrypt-with-haproxy... Alternatively are all of these domains managed by the one account? Would it potentially not be better to do a DNS-01 challenge and then you don't need to worry about trying to pass the challenge through HAPROXY

@cmdr.adama: Thanks for your reply .

I'm using Apache webservers. I'm going to check the error log of the server, maybe I can find some hint.

How can I implement the second way "Choose a server using SNI: aka SSL routing" in combination with OpnSense when it's not possible to edit the config file directly?

Is there any way to get a detail debug log out of HaProxy running on opnSense?

No probs,

You'll need to make the necessary changes in the GUI which will apply to the config. Did you find anything in the Apache logs? I suspect you'll get SSL errors

What you are after is SNI based routing. Have a look at this blog post on HAProxy about how to set it up to do so https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/#choose-a-server-using-sni-aka-ssl-routing

What webserver are you using?

Why are you using TCP mode on the SSL frontend and backend?
Edit: derp.. That's how you're meant to do it... Referring to this https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-name-indication-sni-tls-extension/. Config looks ok.
Are you getting any errors on the webserver?

Edit 2: Have you tried the setup as per "Choose a server using SNI: aka SSL routing" from the link above?

Ok so... That was easier than I had expected but still a screw around.

I have managed to get it working...

Firstly run the below as root

acme.sh --renew -d domain.com -d *.domain.com --dns dns_cf --home /var/etc/acme-client --force

Add the txt records as required and run the command again.

Then navigate to your domain root /var/etc/acme-client/home/domain.com

copy the .cer and .key.

Go to System > Trust > Certificates and click add.

Choose Import, set a name and past the cert data and the key data then save.

the Web GUI now has that cert...

Fingers crossed the plugin doesn't try and renew it and break it...

Was getting hard for me to troubleshoot too as I keep running into the LE rate limit... So it's likely that with the acme.sh update the plugin could be working again.

did a manual acme.sh update... That seemed to work fine however it's going to be messy to try and link the cert up to the GUI and HAProxy... not to mention being saved in the wrong place.
I think we'll need the plugin to be updated as well... Going to do a reboot to see if that'll have any effect.

There's no real changes to the plugin on github since 1.31 came out> Doesn't mean something hasn't changed with LE or Cloudflare

I'm getting the exact same thing and inconveniently today is the day that my cert expired....
I have gone to renew it and it failed every time... Recreated it completely, seemed like it worked for a bit then broke again...

Let's Encrypt shows the renewal as pending however I am also seeing the exact same with the logs.

Have tried the global API as well as the restricted API same result.

Further scouring through the logs and the API calls suggest it's all good and well up to the API post to https://acme-v02.api.letsencrypt.org/acme/chall-v3/**********

Interestingly at that point I have a line with "payload='{}'"

SSL: check
Verify SSL Certificate: check
SSL Verify CA: LE Authority X3

Firstly, it seems a little odd that you're using Let's Encrypt internally. What I do is offload LE and then re-encrypt with a cert from an internal CA on the FW. Then verify the server cert with the same CA. I'm going to have a stab in the dark on that being your problem.

either via IPv4 from inside my network or URL from inside/outside my network.

So... You can't even access it internally?

If it worked before with a Sophos UTM, my guess is it's still set up to use a Cert and CA from the Sophos... You will need to change it to a Cert and CA from OpnSense...