Messages

1

24.7 Production Series / Re: Adguard not starting after Update

« on: August 10, 2024, 07:28:42 pm »

That's essentially it: After the 24.7.1 update, the Adguard plugin is visible, but refuses to start.

Any ideas?

Best e.

I had the same issue. It would start and instantly stop. Reviewed the config and everything looked fine. Ended up deleting the yaml configuration file and redoing the whole configuration. Worked fine with a fresh config, so it acts like there was some setting it didn't like in old configs.

2

24.1 Legacy Series / Re: Questions about wifi-calling/ePDGs

« on: July 09, 2024, 08:04:03 pm »

No one's had wifi-calling issues but me? I find that hard to believe. :-p

3

24.1 Legacy Series / Questions about wifi-calling/ePDGs

« on: July 07, 2024, 06:53:02 pm »

Of late, we've been having loads of issues with our cell phones not getting calls (ie, they don't ring, but then there's a voicemail waiting), or when we make calls, it's just dead air for 20-30 seconds and then finally starts ringing. Problem vanishes if we switch from wifi to mobile network.

For the longest time, I blamed my cell carrier and/or my wifi. Changed carriers, same issue. Changed wifi, same issue. Very odd. So, with nowhere else to look, I wondered if there's something that might be causing OPNsense to drop wifi-calling connections, especially if idle for a while? Ie, we leave the phone untouched for 4hrs, then try to make a call...would OPNsense have some kind of issue with re-establishing the ePDG connection? Some sort of timeout maybe?

I know I'm grasping at straws, but figured I'd reach out to the experts and see if anyone knew!

Setup:
* OPNsense (current version)
* Wifi via Ruckus AP, with ePDGs enabled. Ruckus has ruled out all possible issues on their end after way too many hours on the phone with them. Tested with a Unifi AP and had same results, so I begrudgingly agree with Ruckus.
* Android 12/13 phones (same issue occurs for people visiting this location and using wifi)
* All devices seem to work fine/better when not on our building wifi

4

24.1 Legacy Series / Re: ACME client issues w/Cloudflare

« on: March 12, 2024, 09:16:41 pm »

I noticed that when creating the cloudflare api token, Acme required:
Zone Resources set: Include | All zones.   This appears to be the problem.
To sum it up:
Zone | DNS | Edit
Zone Resources | Include | All Zones
Client IP (not using this field)
TTL | set a valid date range
This appears to work OK.

Tried this. Still says the domain is invalid. I've got all zones allowed and a TTL, as well as the edit permissions.

5

24.1 Legacy Series / Re: ACME client issues w/Cloudflare

« on: March 12, 2024, 06:07:00 am »

Does seem to be the case! I definitely didn't mean to break the acme plugin.

6

24.1 Legacy Series / Re: ACME client issues w/Cloudflare

« on: March 12, 2024, 03:38:55 am »

Lacking other options, I did try the Caddy plugin. No luck...but different results.

Example, it's setup with some.sitename.com points to handler 192.168.0.1, port 1111. I go to some.sitename.com:443 and it gives me a secure blank page. It does not forward to 192.168.0.1:1111 at all.

Progress, maybe? Still would love to know why the built-in plugin isn't working, but no one seems to want to talk about it, judging by the other threads about this.

7

24.1 Legacy Series / Re: ACME client issues w/Cloudflare

« on: March 12, 2024, 02:46:54 am »

I really don't want to learn Caddy to fix an issue that just cropped up with the built-in system. I'll consider that a last resort.

Side-note...tested again using the global API key. Also says the domain is invalid.

8

24.1 Legacy Series / ACME client issues w/Cloudflare

« on: March 11, 2024, 06:45:16 pm »

I've seen and read many posts about issues with Cloudflare, but have been using it without issue for about 1-2 years, using the generated API keys from CF. I use a wildcard domain and all renewals worked from 2022 until about 70 days ago. Then, mysteriously, they stopped working with the errors below. Hoping someone has some ideas on this as I've been beating my head against it for days.

Issue:

• Starting about 70 days ago, the renewals began failing with "invalid domain" and "Error add txt for domain"
• In the past, others have fixed this with updates (I'm current on both OPNsense and plugins) or new API keys (tried that)
• Rebuilt all stages of the cert and issue persists
• Tried with a single subdomain and issue persists

Tested:

• Recreated the verification challenge, as that's where it's failing. Same errors.
• Verified/recreated the API key permissions in case something changed on CF's end. Same errors.
• Switched to a single subdomain, rather than wildcard. Same errors.
• Recreated all stages of the request. Same errors.
• Created a new API key with correct permissions. Same errors.
• Contacted CloudFlare. They blame OPNsense, because of course they do.
• NOTE: The API key does have zone read and dns edit permissions

Code: [Select]

See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
Please add '--debug' or '--log' to check more details.
Error add txt for domain:_acme-challenge.somedomain.com
invalid domain
Adding txt value: <somestring> for domain: _acme-challenge.somedomain.com
Getting webroot for domain='*.somedomain.com'
Getting domain auth token for each domain
Single domain='*.somedomain.com'
Using CA: https://acme-v02.api.letsencrypt.org/directory

9

23.7 Legacy Series / Re: LAN2LAN port forwarding question

« on: January 16, 2024, 10:05:33 pm »

I agree, but would still like to figure out why I can't port redirect lan to lan.

10

23.7 Legacy Series / LAN2LAN port forwarding question

« on: January 16, 2024, 08:36:17 pm »

I'll admit I'm baffled by this one and it seems like it should be really easy...I'm clearly missing something.

I can port-forward all I want from WAN > LAN without issue. Example, WAN port 9999 forwards into a specific LAN device port 99. Easy. Works great.

Where I run into problems is LAN > LAN forwarding for ports that do hit the firewall (so this isn't a layer-2 issue, as it's not going from client -> server, but rather client -> fw -> forward to server). I know, I know...this is because someone keeps changing the IP of the LAN server and I want to update it on one spot, rather than inform a dozen users that the IP changed again. My goal is that they just go to a port on the firewall and it redirects them to wherever the LAN server is this week.

• Firewall LAN IP is 192.168.0.1
• LAN server is 192.168.0.5
• NAT rule forwards firewall port 9999 to LAN server port 9999
• Client machine goes to 192.168.0.1:9999. They should get 192.168.0.5:9999, but instead get a timeout. Firewall logs say that the traffic WAS redirected successfully. LAN server doesn't see any traffic from the client or the firewall.
• Client machine goes to 192.168.0.5:9999. Site works fine
• LAN server's internal firewall disabled to ensure it was not the cause of issues.
• Tested with reflection enabled and disabled. No change

What am I missing here to redirect LAN to LAN?

11

23.1 Legacy Series / Re: Ongoing ACME/LE issues

« on: July 18, 2023, 03:33:33 pm »

Hadn't been using automations for that, given that a reboot didn't help (and I didn't know there would be different results from a UI restart vs a reboot). Will give that a try and see how it does...though it'll be a bit before I know for sure, since it just renewed.

Thanks!

12

23.1 Legacy Series / Re: Ongoing ACME/LE issues

« on: July 17, 2023, 08:17:13 pm »

I would guess that you are not reloading whatever service that is using the certificate, hence you experience that kind of behaviour.

It's not really related to ACME itself since it's doing its job, renewing certificates.

You can solve the reload issue by using automations.

A reboot doesn't fix the issue...wouldn't that be a reload for purposes of this issue?

13

23.1 Legacy Series / Ongoing ACME/LE issues

« on: July 17, 2023, 07:32:36 pm »

Hunted around the forums and saw plenty of ACME-related things, but didn't find this particular one. Let me know if there's already a solution I missed.

Basically, every 90 days, my certificate "expires"...but when I look at ACME, it renewed just fine. The cert is valid, but what OpnSense is presenting is the previous certificate. Fixing it is easy enough. I go into settings > administration, change back to the internal cert, then back to ACME, and it presents the right cert again. Rebooting OpnSense doesn't fix the issue.

Essentially what I'm seeing is that ACME isn't applying the new certificate when it renews. It gets the new cert, but doesn't switch OpnSense to it. I've reinstalled ACME, but the same thing happens. I think this began in late v21, but continues into 23.

Anyone know how to fix ACME so it actually applies the certs it gets, instead of idly sitting on them and never applying?

14

Intrusion Detection and Prevention / Re: Suricata Not Finding Anything

« on: May 31, 2023, 10:37:19 pm »

Seeing the same thing. Completely blank logs (even if I turn them up from Default). Watching traffic, I'm getting the usual 1000s of bots trying to look for vulnerabilities on my WAN side, but Suricata isn't stopping anything at all. Saw this once a while back (v19 maybe?) and it got fixed with an update, but this time around it seems to have not blocked anything in weeks...ie, at least 2 versions.

15

23.1 Legacy Series / Re: LetsEncrypt issues after v23.1 upgrades? (likely just mine)

« on: April 06, 2023, 09:18:51 pm »

Ok...got a fix, but no idea why/how it broke in the first place.

Things I tried that didn't work:
- Check ref of the cert in config files (it was correct)
- Re-issuing the cert
- Reinstalling ACME plugin
- Import the config onto a new firewall as-is

Thing that did work (this is stupid easy and I should have done it first...not sure why an import to a new firewall didn't work):
- Switch active cert (system > trust > certs) back to the self-issued one
- Reboot (this part was required or the rest didn't work)
- Switch active cert back to LetsEncrypt
- Now, suddenly, it's issuing the real cert

Thanks everyone! Gotta love the weird issues.