Messages

Layer 8 strikes again (๑﹏๑//) Sorry for sending you on a wild goose chase! It's indeed already in 3.1.1, this is simply a case of GUI integration.

As a test I added

Code Select Expand

HE_DDNS_KEY="the_generated_key" in

Code Select Expand

/var/etc/acme-client/accounts/[...]/account.conf, called acme.sh with

Code Select Expand

--dns 'dns_he_ddns' instead of

Code Select Expand

--dns 'dns_he' and the certificate is created.

Currently, in the GUI username/password are supplied for all domains under "Challenge Type". As this new feature is per-domain, it's probably reasonable to add a checkbox which enables per-domain tokens to be supplied in each certificates' dialogue?

Glad to hear it! :-)

Yes, that's the commit.
I assumed it to be integrated in a way that simply takes the user/password input in ACME's challenge types. But that was overly optimistic to naive. Guess I should finally RTFM the plugin documentation^^

You're absolutely correct, pulling in everything is probably just asking for trouble. Yet, doing individual pulls for non-critical issues creates too much work for projects as big as OPNsense.

I felt somewhat naked without having 2FA activated on my Hurricane Electric account. However, as HE apparently doesn't support global access tokens, that requires ACME.sh to support record-specific API keys - which is safer anyways: https://github.com/acmesh-official/acme.sh/pull/5237

Cheers,
Fabian

PS: Thank you, I'm doing great and hope you are as well! :-)

Thank you both for the insights! So it's either back to waiting for a new release tag or building from git myself.

Hi,

the release cadence of acme.sh can be slow with gaps of up to a year. If I understand the readme correctly, one should use the latest code instead of waiting for new tags anyway:

acme.sh is in constant development, so it's strongly recommended to use the latest code.

Since the last release from April, useful new features such as the DNS API of Hurricane Electric have been added. Would it be possible to update OPNsense with the latest code from github? Thanks!

[Services --> HAProxy --> Settings --> Rules & Checks --> Conditions]

Those who are having issues with "503 Service Unavailable" only for internal access might want to try this:

Part 7 Step 4:
Services --> HAProxy --> Settings --> Rules & Checks --> Conditions
Don't set the condition to "Source IP is local" but select "Source IP matches specified IP" and input the private IP ranges you actually need, e.g. 192.168.0.0/16 10.0.0.0/8 172.16.0.0/12.

This fixed the issue for me.

Also, in case your local servers only accept http connections, make sure to remove the SSL checkmark of the respective "real server" entry. Even though that should be somewhat self-evident :-)

Hi,

are there any plans to simplify captive portal login via QR codes?
From what I could find, a patch was created but never merged. https://github.com/opnsense/core/pull/3388
This would be a great feature.

There was a recent submission which probably fits here...

https://github.com/opnsense/core/commit/2a1ccae9

# opnsense-patch 2a1ccae9


Cheers,
Franco

This solves the issue for me, thanks!  :)

I'm seeing the same issues on OPNsense 24.7.4_1-amd64. However, even when setting no limit and selecting all categories via multi-select, no logs are shown. Any idead how to fix this? ???

Well, turns out this one is a combined OPNsense AND layer 8 issue:
https://github.com/opnsense/core/issues/6907
Increasing "Time period" to a higher value allowed Dpinger to come up again.

Hi,
my OPNsense looses internet connection every 3-4h. Restarting the box fixes the issue.

Are you a customer of Vodafone West (former Unitymedia) by any chance?
You could try adding

Code Select Expand

supersede dhcp-server-identifier 255.255.255.255 under Interfaces->Your WAN Interface->DHCP client configuration (Advanced)->Option Modifiers

This worked for me as Vodafone is doing funky stuff with their DHCP (it's hidden behind a relay causing IP renew request going to the wrong server, thus triggering an IP lease timeout).

Hi,

the issue persists in OPNsense 23.7.9.
Unfortunately logging is proving less than helpful. Any idea on how to diagnose this?
As it stands, Multi-WAN failover is broken because of this issue. :(

Hi,

just updated to OPNsense 23.7.8, unfortunally the issue persists :-\
Any ideas on how to proceed as I can't seem to get any useful info from logs?

Thanks!

good day
I have the same problem with my gateway, I already updated the latest version today, and I still have the same problem

Hi,
the issues are different as I don't get such an error message. Hence, I suspect different root causes.

Hi,

sorry for the delayed reply, it's been a busy start of the week!

- Is DPinger still "RUNNING" in services or stopped?
- Does it help to restart it?
- Is there any information in your log file about dpinger when you reconnect?
- What kind of IPs are you pinging? Is it the next hop or some far host?

-Dpinger is still listed as running, in fast the second interface is being monitored as always.
-The Dpinger attached to the affected WAN interface is stopped and doen't come up when restarted (tried via GUI).
-The only informating from the gateway log is "Reloaded gateway watcher configuration on SIGHUP".
-The monitoring IPs used are 8.8.8.8, 1.1.1.1 and others. I tried several to no avail.

Long time no see. Hope you are doing good!

Can you be a little more specific?

What's the error message? What does it try to start on the command line? How are your gateways set up (far gateway used)?

Thank you very much I'm well! I hope the same is true for you :D
It's been quite some time indeed, one could say OPNsense has been running too well  ;D

Oh I wish there was an error message :( Other than "Reloaded gateway watcher configuration on SIGHUP" I can't see anything, even directly from the command line. A second dpinger thread required for the affected WAN simply never comes online.  ???

The affected WAN gateway (Vodafone Germany, DOCSIS 3.1, TC4400 modem) is setup as upstream and far. This worked for years before the update but one should never discount the possibility of the ISP breaking things... Thus I played around with several variations of these settings as well as "disable host route" just to be sure. The WAN gateway that isn't affected (i.e. failover 5G) is configured as far gateway and nothing else.

For me, enabling 'Disable Host Route' on my problematic gateway (I think) helped.

Maybe my setup is similar to yours:
- 2 ISP connections
- 2 separate opnsense routers
- Failover network between them, to facilitate 'cross' failover if 1 ISP is down

Thanks for chiming in! :)
My setup is quite different as both ISP uplinks are attached to the same OPNsense box with the second OPNsense box (just one ISP) at another independent location.

Right now I can only test on the primary box as messing around with gateways breaks remote access.