Messages

os-acme-client works great, thanks!

Getting the same thing but with Porkbun as my DNS provider.

The update to 25.1.8_1 messed something up as no provider exists in my list aside from Cloudflare

They do. I tried in normal Firefox and it also works fine there. So I'm guessing it's some hardening setting in Librewolf. Thanks for helping me narrow this down! I'll keep digging into the settings of LW.

It's the combination of the ResistFingerprinting setting and Caddy with LE certs that seems to be the problem, for me at least.

Never mind, was looking via direct IP and didn't notice.

Live logs work with that method. So is the issue somehow with the LE cert? I'd much prefer to use my LE cert for this.

Edit: it seems to be a browser issue. Live logs work fine with my original set up in Brave, but not librewolf. Strange.

I wonder what I'm doing wrong then. My section looks similar to yours, with the addition of the certificate, I just have the WebUI bound to a specific interface:

Code Select Expand

handle {
reverse_proxy 192.168.5.1:444 {
transport http {
tls
tls_trust_pool file /var/db/caddy/data/caddy/certificates/temp/670931cbb863a.pem
tls_server_name OPNsense.localdomain
}
}
}

Hello, caddy doesn't seem to like the firewall live log view. Auto-refresh will not stay enabled. I don't have this problem when viewing logs via direct IP.

Caddy logs show this "context canceled" error when it happens:

Code Select Expand

"debug","ts":"2024-11-18T13:32:10Z","logger":"http.handlers.reverse_proxy","msg":"upstream roundtrip","upstream":"192.168.5.1:444","duration":0.001754159,"request":{"remote_ip":"192.168.5.4","remote_port":"59054","client_ip":"192.168.5.4","proto":"HTTP/2.0","method":"GET","host":"opn.example.com","uri":"/api/diagnostics/firewall/log/?digest=91a55b1d9ceb232a54b94da9ad86d84e&limit=1000","headers":{"Accept":["application/json, text/javascript, */*; q=0.01"],"Sec-Gpc":["1"],"Sec-Fetch-Mode":["cors"],"Accept-Language":["en-US,en;q=0.5"],"X-Csrftoken":["EzCqIYHuVYedZX-dW038qA"],"Sec-Fetch-Dest":["empty"],"Cookie":["REDACTED"],"X-Forwarded-For":["192.168.5.4"],"Referer":["https://opn.example.com/ui/diagnostics/firewall/log"],"Sec-Fetch-Site":["same-origin"],"Te":["trailers"],"Dnt":["1"],"User-Agent":["Mozilla/5.0 (X11; Linux x86_64; rv:132.0) Gecko/20100101 Firefox/132.0"],"X-Requested-With":["XMLHttpRequest"],"Content-Type":["application/json"],"X-Forwarded-Proto":["https"],"X-Forwarded-Host":["opn.example.com"],"Accept-Encoding":["gzip, deflate, br, zstd"]},"tls":{"resumed":true,"version":772,"cipher_suite":4865,"proto":"h2","server_name":"opn.example.com"}},"error":"context canceled"}

What could be the problem?

Hi,

I wonder what caused this.

Update on my issues, I am on AT&T fiber and had their gateway in passthrough mode to my opnsense box. I've recently implemented a bypass via a ONT on a SFP stick to be able to completely cut their gateway out of the mix. Monit has not triggered once to restart my WG interfaces in the week since doing so. So, it seems possible that if you're in a similar situation that might be the cause.

Want to report back that for the past 5 days I haven't noticed any interruptions, and monit logs show the restarts. So thank you again!

You are a lifesaver xsfpo! I was focusing on the gateways, not thinking about the interfaces themselves. Gonna apply this and hopefully not get this anymore.

So I completely reinstalled opnsense and things are more stable in comparison, but I still get regular (maybe once a day) issues with "loop detected". I have discovered that taking the wg gateways in the group down and bringing them back up seems to consistently resolve the issue.

Is there a way to use monit to automatically bring the gateways down and up?

Is there something else I could provide to give more insight into this that someone might have an idea for a more specific area to look?

I'll also add that I have 3 VLANs; general population, IoT, and a DMZ. I have put them with my LAN in a Firewall Group that has a few rules to apply to all the them.

They are all using my wg gateway group as the gateway for general internet access.

I'm unsure what extra I could provide that would help, so if anything else would be useful to troubleshooting this please let me know and I'll share.

I have 4 tunnels set up to mullvad with routes disabled, a gateway group set up, and used in firewall rules. For the past few months I've been getting consistent packet loss only on some of the tunnels. It used to only happen about once a day for about an hour, but now it's almost constant.

When all 4 tunnels are connected, logs in System > Log Files > General show

Code Select Expand

Notice kernel <5>wg1: loop detected If I bring down wg1, the loop changes to wg3, if I also bring down wg3, the remaining 2 tunnels are fine.

I have set up all 4 tunnels with the same methodology, so I don't think it's something in the wireguard settings. I've attached screenshots of them just in case I'm missing something.

I am more inclined to think it's a firewall rule somewhere, but neither wg1 or wg3 are in rules by themselves. I use the WG gateway group in my rules. How can I figure out what the exact cause of this loop is?

I noticed that a small update was available, one of which was the wireguard-kmod to 0.0.20220615_1. Took that then rebooted and now things are connected. Guess that answers that.