Messages

Mal das hier versucht?
https://www.reddit.com/r/opnsense/comments/16n2fr3/voipdectbasestation_behind_opnsense_firewall/?show=original

Läuft bei mir mit neustem OPNsense Update nach wie vor tadellos.

I am facing the same issue since 24.1.6

That's strange... Do you have OPNsense version 24.1.6 installed?

Yes.

I have a question about HAproxy SSL performance with large downloads:

Using a NAT port forward to an internal HTTPS nginx server, I get full wire speed i.e. (45 MByte/s) from the outside, but using HAproxy following this tutorial, I am limited to download speeds of ~4-5 MByte/s.

I have tried to use HTTP instead of HTTPs for the backend server connection to no avail.

I suspected that the SSL termination would lead to an interrupt of the streaming flow in that each packet must be acknowledged over the whole chain before the next one can get requested, so I have somewhat optimized my throughput by a factor of 2 via this tuning:

Code Select Expand


    tune.h2.max-frame-size 4048576
    tune.pipesize 4048576
    tune.h2.initial-window-size       1048576
    tune.h2.be.initial-window-size    1048576
    tune.h2.fe.initial-window-size    1048576


But it seems that the HTTPS termination within HAproxy itself is the culprit. I found some other source that suggest there might be a problem with only some ISPs showing that behaviour when SSL traffic is terminated by HAproxy.

Does everybody else see this or may my ISP really be the culprit?

No issues on my side here.

VDSL 100/40 MBit/s on HAProxy side.
VDSL 250/40 MBit/s on Client side.

Client side downloads files from HAProxy side using File Browser with max speed of 40 MBit/s.
This is using a direct connection between two parties and no peering service (f.e. Cloudflare) involved.

Just chiming in here --

Thanks very much doing all the work on this How-To, OP, and for keeping it updated, etc.
I successfully implemented it in my modest OPNsense instances/networks, before realizing that for small networks where there may never be more than perhaps 1 to 3 people logging in to a given OPNsense instance, in fact it's far more secure to simply shut off all HTTP listening on external network ports, and instead use SSH tunnels / port redirects, i.e. ssh -L 9450:localhost:80 my.opnsense.host to connect directly to the opnSense instance and access the webgui that way.  Then it doesn't matter at all whether HTTPS is active as the entire connection takes place inside the highly-secured SSH network connection.  With SSL tunnels there is no need for a webgui process to be listening anywhere except localhost:80.

It avoids the major overhead and ongoing maintenance complexity of getting a public/real SSL certificate issued, emplaced, and dealing with ongoing renewals, etc.

The main purpose of the tutorial is not to to access the OPN UI, for which your method makes perfect sense, but instead to reverse proxy services that are hosted internally in a LAN.

Exactly.
To add to this, exposing any administrative web interfaces using a reverse proxy is the worst thing you could possibly do.
Only expose those things using either your SSH tunnel method or VPN tunnels.

The whole point of a reverse proxy is to make web services available using a single port, a nice URL and a valid certificate.

It avoids the major overhead and ongoing maintenance complexity of getting a public/real SSL certificate issued, emplaced, and dealing with ongoing renewals, etc.

We are using ACME to avoid exactly all of that. It is a one time only set and forget process.

I think you didn't really understand the tutorial at all.
Also public certificates, as you can see in my tutorial, are so easy and completely free to obtain nowadays.

[temporarly]

I am not sure this was mentioned before but https://desec.io no longer new registrations for DynDNS.
For the German speaking audience I can highly recommend https://ipv64.net/
Many texts on the website are English, but someone not speaking German might have problems understanding everything

This is not entirely true, but I am already aware of that.
deSec had a "bot registration attack" and therefore paused all new domain registrations temporarly.

https://talk.desec.io/t/dyndns-service-down/823/3?u=thehellsite

[Attention!]

Attention!

Hey everyone,

after the upgrade to 24.1, please check your cron job for updating OCSP data.
Since that function is no longer available from the list, mine was set to "Automatic firmware update", which could potentially be *really* bad :o

@TheHellSite: Thank you for the guide and the ongoing maintenance, much appreciated! :) (beer is on the way)

Thank you for pointing this out, I opened a bug report.
https://github.com/opnsense/core/issues/7197

@TheHellSite, many thanks and kudos for your tremendous effort, contribution and help!

I try to avoid seeking for help and solve my problems on my own. But after upgrading to 24.1 I stuck in the CRON configuration when it comes to the update HAProxy OCSP Data you mentioned in Part5.4, this feature has disappeared and can no longer be selected. I assume this is needed to get the OCSP must staple extension running.

Is there an alternative way of configuring or what I'm doing wrong or missing.

Thanks loop0

As i know the OCSP update cronjob isn't needed anymore since the OCSP feature was completely revamped with the actual version of haproxy 4.2 which is bundled in opnsense 24.1

I had some errors with the OCSP updates so i opened a issue in the opnsense/plugins github repo.
https://github.com/opnsense/plugins/issues/3755

I will update the tutorial once again to comprehend the changes, please bear with me.

EDIT: Fixed, see Part 5.

As the automatic OCSP updates are now fully built into HAProxy, there is no need for the previously used Cron job, which has been removed from the OPNsense system as of update 24.1.

[Important changes for OPNsense v24.1 and above]

Important changes for OPNsense v24.1 and above

• 20240201
  
  • Simplified and improved Part 8. The "INVALID_SNI" certificate is no longer needed, instead we use the "strict-sni" parameter to achieve an even better result.
    Thanks @mnaiman for the suggestion.

To comprehend the changes introduced in OPNsense v24.1 and above (HAProxy version >4.2) please do the following.
This is only necessary if you followed "Part 8 - Advanced Configuration: Hide your certificate on access by IP" of the tutorial!

Modify your configs as shown in the updated part 8 of the tutorial and remove the "INVALID_SNI" certificate as default certificate from your "HTTPS_frontend".

The "INVALID_SNI" certificate can then be deleted at "System: Trust: Certificates".
The "INVALID_SNI" certificate-authority can then be deleted at "System: Trust: Authorities".

Kind Regards
TheHellSite

Hello @TheHellSite

I was using opnsense with HAProxy > 1 year.
Thanks for opffering this free tutorial, it definitely made the world better (at least for me).

The problem with opnsene 24.1 and HAProxy 4.2 hit me as well.

I will be happy when the "strict-sni" update of your guide is released.

Thank you in advance.

It just dropped.

[/etc/haproxy/frontend-crt-list.conf]

EDIT:
HAProxy refuses to start if a self-signed certificate is configured as (default) certificate under the SSL offloading section on a (HTTPS) frontend.
So for now it is best to remove the "INVALID_SNI" certificate as default from the HTTPS frontend.

@TheHellSite

I'm _not_ using your plugin, but I do use HAProxy on other systems with a crt-list, default self-signed cert and ocsp updates. So a shot in the dark, not sure if this "solves" your problem: You might want to declare your "default" certificate with "!*" in a crt-list to prevent errors:

https://www.haproxy.com/documentation/haproxy-configuration-manual/latest/#5.1-crt-list

/etc/haproxy/frontend-crt-list.conf

Code Select Expand


/path/to/default.crt.pem !*
/path/to/fqdn.crt.pem [ocsp-update on alpn h2,http/1.1] foo.bar
/path/to/wildcard.crt.pem [ocsp-update on alpn h2,http/1.1] *.foo.bar


Thank you, this should definitely fix the issue.
However most of the people using this guide refrain from editing the OPNsense config files.
Therefore I hope we will see a fix in the OPNsense HAProxy plugin for self-signed certs.

[Attention]

Attention

The latest HAProxy update has a few bugs related to SNI and OCSP updates.

This means the following:
1. If you have multiple certificates on the same frontend for different subdomains/domains then connections will fail.
2. If you have "INVALID_SNI" configured then HAProxy will now always use the INVALID_SNI certificate because of issue 1.
3. The new built-in OCSP update feature is not working as intended just yet.

The good thing is that all issues are already patched and will be fixed in the next update.

Alternatively you can patch manually.
https://github.com/opnsense/plugins/issues/3779#issuecomment-1917956814

In order to apply the patch manually, access the OPNsense shell and run the following commands.

Code Select Expand

1. Reinstall the HAProxy plugin.
pkg install -f os-haproxy
2. Apply the patch.
opnsense-patch -c plugins 404c19f6e
3. Restart HAProxy from the OPNsense dashboard or reboot OPNsense.

EDIT:
HAProxy refuses to start if a self-signed certificate is configured as (default) certificate under the SSL offloading section on a (HTTPS) frontend.
So for now it is best to remove the "INVALID_SNI" certificate as default from the HTTPS frontend.

Kind Regards
TheHellSite

My post was helpful to you?

No, and I wasn't asking you either.

Yes you were, since I was that "anyone" who fixed it for him and many others that contacted me via PM.
And since you are following my guide I think it is somewhat helpful to you. But you do yours I guess.

Feel free to click [applaud] to the left underneath my profile.

Not for replies like these.

Fine with me.

Additionally you can consider donating

Only in your dreams.

Again, fine with me.

Unless you're desperate to earn something, then I can tell you these posts don't work in your advantage.

I think you are pretty smart, so if you take a look at the amount of views this guide has versus the number of people that actually donated you would be able to answer this on your own.

I even helped some people that contacted me via PM free of charge. Because they provided all the necessary information without me asking, have been very nice, friendly and just good to chat with.

Just to be clear though if it was my intention to make a living out of this I would put this whole guide behind a paywall or put it on my personal blog (which doesn't exist and hopefully never will) and fill it up with ads fishy as hell (like others do).
I even know that there are many companies out there that use this guide to bill their clients a big amount of money while I get nothing from it. Guess what, fine with me.

Instead I chose to publish this in the official forum, free of charge, available to anyone, without asking for anything.
Why? Because I believe in and support the "free knowledge for everyone" movement.
Not because I am from a third world country and can barely make a living,. I do this because it will make the world just a tiny little bit better.

But then I think perhaps you're not aware how some other people read your messages, so perhaps this makes you aware. If you want to take my advise, stop posting if you don't want to help (its fine!) but don't be like this.

Just so you know your issue and the ones of many others posting here is based on the fact that (you) misread / skipped / oversaw a tiny but very important bit of the configuration.
Additionally you didn't even include the config export, like many others. Which I clearly tell everyone to do so.
Now tell me you wouldn't be annoyed by that at this point.

But yes, you are right, I guess I am the offensive dick in this scenario.

Last but not least, the offensive dick is still happy to help.

Sure, fixed via PM.

To all people above asking for help...
Or "threatening" to use NGINX instead  ;D

Everything was and is working fine for me on 10+ instances of OPNsense (outdated and latest firmware versions) configured exactly as per tutorial.
If you are not able to follow the tutorial EXACTLY as it is, then this is totally a user error on your side.

As stated in the top of the tutorial, no more free support for a perfectly working tutorial if followed correctly.
If you still need help, feel free to PM me for paid support.

Best Regards
TheHellSite

Am I the only one ?

Yes you are. Issues with direct access to the local IP of the target service from within the same network has nothing to do with this tutorial.