Topics

1

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

2

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

3

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?

4

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?

5

23.1 Legacy Series / [Solved] LetsEncrypt issues after v23.1 upgrades? (likely just mine)

« on: April 05, 2023, 10:52:29 pm »

I'm currently on 23.1.5_4. It appears that sometime after I upgraded to 23.1, the ACME updates stopped working. I've done several updates since then with no change.

TL;DR of what I'm seeing:
- Certificate renewals are happening as per normal.
- All renewals are successful (log pics attached, showing renewals on 4/4/2023)
- However, the firewall still sends the old certificate to all requests, which is now expired (pics attached, showing expiration on 4/1/2023)
- I have tested this on multiple browsers and machines and all get the same expired certificate reply. Tested in Chrome, Firefox, and Opera, on Windows 11 and on Ubuntu.
- Confirmed that the system IS using the LetsEncrypt certificate as its default. The system only has one certificate and it's this one that's having the issues. Pic attached of that, too.

Any ideas? I've already exported the config and imported it on a new installation with the same results. Seems almost as though the ACME Client plugin broke during the upgrade to 23.1, though no one else is reporting it, so I'm guessing it's just mine. The fact that it's pulling new certs successfully, but then not using them it is definitely what has me confused. Renewals have been working fine previously since v19 and this is the first time it's stopped renewing since then.

6

21.1 Legacy Series / Question about os-git-backup

« on: May 24, 2021, 04:53:07 pm »

Not sure how many others use this plugin, but my company uses it on every unit. However, about 6mo ago, I started getting the warning below by email every few days. I read up on the article and it said to use the SSH private keys. Ok, no problem. I added that to the OPNsense ui...but I still get the notices about passwords. Is there something I'm missing to get this fully in compliance, or is the plugin out of date?

Warning:
"You recently used a password to access the repository at XXXXXX with git using git/2.31.1.

Basic authentication using a password to Git is deprecated and will soon no longer work. Visit https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information around suggested workarounds and removal dates."

7

20.7 Legacy Series / Any way to repair pkg or to do a full packages repair?

« on: November 03, 2020, 04:44:50 pm »

Just had one of our firewalls upgrade from 20.1 to 20.7.4. As with previous ones, it installed fine and we were back up in a short while, aside from the syslog lockup issue, which is an easy fix. After booting up...no DNS. I logged in and found that os-dnscrypt-proxy hadn't installed for some strange reason. The package had been there on 20.1, so this was really odd.

I clicked the plus to add dnscrypt...it runs through the install, then says "nothing to do". It's still not installed, though. Rebooted, tried again, nothing. Logged in via SSH and did the pkg install, same thing. It asks if I want to install it (y/n), then doesn't. No error. ALL other packages install fine. I've done "pkg update -f", "pkg clean -a", and just for amusement I even reset the configuration to stock and tried again. Same issues.

Anyone know a fix for this that doesn't involve a full reinstall?

8

Development and Code Review / General building from source questions

« on: October 21, 2020, 03:53:29 pm »

I'm definitely finding some strong gaps in my knowledge here and haven't been able to find the answers. Hoping someone can point me in the right direction. I've been able to build without issue from the source. However, I'm trying to do a slimmed down version and having no luck figuring out the steps. Here are the steps as I understand it...can someone correct where I'm going wrong? Thanks in advance!

1) Download tools, "make update"
2) make base, make kernel, make ports, make plugins, make core, make nano *as of here, everything's good
3) I copy a config into a new folder (config/1.0) and then edit plugins.conf to comment out builds of some plugins I don't ever use.
4) This is where I get unclear. Franco's notes looked like I should just run "make nightly SETTINGS=config/1.0" but that fails.
5) I tried "make base VERSION=1.0 SRCVERSION=stable/20.7" and it has major problems along the way, hinting that I should have renamed the source. From this, I continue to get builds named 20.7, despite the VERSION tag.
6) I lastly tried, "make rename-base VERSION=1.0" to convert it over and build as if it were always called 1.0. This one gives me tar errors on "repacking base set" (specifically "tar option -f requires an argument") and then fails.

Can anyone give any pointers? My ultimate goal is to include a custom theme, disable builds and inclusion of a few plugins, and renumber the build (so I don't get confused whether I'm on stock or custom).

9

Development and Code Review / Build errors referencing IA32_DEBUG_INTERFACE

« on: October 16, 2020, 09:39:00 pm »

EDIT: I'm just wiping out every folder and starting over. No idea what broke, but I'm hoping it won't happen again. Fingers crossed.

My apologies if this one's been answered before, but a search didn't turn it up. When building 20.7, following the directions, I went through with zero issues...once. Have the img file to show for it. I've since made no changes.

However, if I try to build again, it fails after a few seconds with the errors below. I've done "make update", "make clean" commands, tried doing individual steps, but this error occurs right at the start in "make base". Really confused what's happening, given that if it worked once, I'd have thought it would work again. Even "make test" fails with an identical error.

===> share/i18n/esdb/UTF (all)
===> usr.bin/pagesize (all)
/usr/src/usr.sbin/bhyve/xmsr.c:63:8: error: use of undeclared identifier 'MSR_IA32_DEBUG_INTERFACE'
                case MSR_IA32_DEBUG_INTERFACE:
                     ^
===> usr.sbin/acpi/iasl (all)
/usr/src/usr.sbin/bhyve/xmsr.c:128:8: error: use of undeclared identifier 'MSR_IA32_DEBUG_INTERFACE'
                case MSR_IA32_DEBUG_INTERFACE:
                     ^
/usr/src/usr.sbin/bhyve/xmsr.c:133:15: error: use of undeclared identifier 'IA32_DEBUG_INTERFACE_LOCK'
===> usr.bin/passwd (all)
                        *val = 0 | IA32_DEBUG_INTERFACE_LOCK;
                                   ^
3 errors generated.
--- xmsr.o ---
*** [xmsr.o] Error code 1

make[4]: stopped in /usr/src/usr.sbin/bhyve
1 error

make[4]: stopped in /usr/src/usr.sbin/bhyve
--- all_subdir_usr.sbin/bhyve ---
*** [all_subdir_usr.sbin/bhyve] Error code 2

make[3]: stopped in /usr/src/usr.sbin
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/lib/libdwarf
--- all_subdir_lib/libdwarf ---
*** [all_subdir_lib/libdwarf] Error code 2

make[3]: stopped in /usr/src/lib
1 error

make[3]: stopped in /usr/src/lib
--- all_subdir_lib ---
*** [all_subdir_lib] Error code 2

make[2]: stopped in /usr/src
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/usr.bin/passwd
--- all_subdir_usr.bin/passwd ---
*** [all_subdir_usr.bin/passwd] Error code 2

make[3]: stopped in /usr/src/usr.bin
1 error

make[3]: stopped in /usr/src/usr.bin
--- all_subdir_usr.bin ---
*** [all_subdir_usr.bin] Error code 2

make[2]: stopped in /usr/src
A failure has been detected in another branch of the parallel make

make[6]: stopped in /usr/src/share/i18n/esdb/UTF
--- all_subdir_share/i18n/esdb/UTF ---
*** [all_subdir_share/i18n/esdb/UTF] Error code 2

make[5]: stopped in /usr/src/share/i18n/esdb
1 error

make[5]: stopped in /usr/src/share/i18n/esdb
--- all_subdir_share/i18n/esdb ---
*** [all_subdir_share/i18n/esdb] Error code 2

make[4]: stopped in /usr/src/share/i18n
1 error

make[4]: stopped in /usr/src/share/i18n
--- all_subdir_share/i18n ---
*** [all_subdir_share/i18n] Error code 2

make[3]: stopped in /usr/src/share
A failure has been detected in another branch of the parallel make

make[5]: stopped in /usr/src/usr.sbin/acpi/iasl
--- all_subdir_usr.sbin/acpi/iasl ---
*** [all_subdir_usr.sbin/acpi/iasl] Error code 2

make[4]: stopped in /usr/src/usr.sbin/acpi
1 error

make[4]: stopped in /usr/src/usr.sbin/acpi
--- all_subdir_usr.sbin/acpi ---
*** [all_subdir_usr.sbin/acpi] Error code 2

make[3]: stopped in /usr/src/usr.sbin
2 errors

make[3]: stopped in /usr/src/usr.sbin
--- all_subdir_usr.sbin ---
*** [all_subdir_usr.sbin] Error code 2

make[2]: stopped in /usr/src
A failure has been detected in another branch of the parallel make

make[4]: stopped in /usr/src/share/timedef
--- all_subdir_share/timedef ---
*** [all_subdir_share/timedef] Error code 2

make[3]: stopped in /usr/src/share
2 errors

make[3]: stopped in /usr/src/share
--- all_subdir_share ---
*** [all_subdir_share] Error code 2

make[2]: stopped in /usr/src
4 errors

make[2]: stopped in /usr/src
--- everything ---
*** [everything] Error code 2

make[1]: stopped in /usr/src
1 error

make[1]: stopped in /usr/src
--- buildworld ---
*** [buildworld] Error code 2

make: stopped in /usr/src
1 error

make: stopped in /usr/src
*** Error code 2

Stop.

10

Zenarmor (Sensei) / ElasticSearch migration

« on: September 23, 2020, 07:49:00 pm »

I was eyeing the external ElasticSearch option and was curious about a few things there.
1) If we fully offload the ElasticSearch to something external, does that change anything with our reporting/graphs, etc? I wasn't clear on whether the "Kibana" portion of the directions was something required as part of the move to external.
2) If we offload to an external DB how do we move to the external database, or do we need to reinstall? I see the directions for attaching it as a stream target, or how to use external from the start, but wasn't sure how to switch after installing.
3) Lastly, what's the benefit of storing locally and also streaming to external? Wasn't sure what benefit that provided.

Thanks!

11

Zenarmor (Sensei) / Policy order and priority

« on: September 21, 2020, 04:42:14 pm »

I realized I may have a misunderstanding of how the policies work and was hoping for some clarity.

How I thought they worked:
- Like firewall rules, it continues until it matches, then stops there.
- If you have Policy1, Policy2, and Default, it will process Policy1 and if it applies, it would allow/block as appropriate, but if the policy didn't apply (wrong user/group), it would move to Policy2, and if neither applies, it uses Default.
- Example: We block Proxies in Policy1, but not in Policy2 or Default. If user is included in Policy1, it blocks their Proxy. If they are not included in Policy1, we don't.

How it's actually working and why I'm confused:
- Policy1 is our employee policy. It blocks pornography and nothing else.
- Policy2 is our guest/student policy. It blocks pornography, proxy, games, and violence.
- Default is the default policy. It blocks pornography, proxy, games, and violence (we had to match policy2 and default, as anonymous users did not count as any user or group we could identify for Policy2)
- Staff member tries to use his computer. If he goes to pornography, I see it blocked by Policy1, as expected.
- Staff member tries to use his computer. If he goes to a proxy, I see it blocked by Default, which surprised me. This seems to indicate that all policies that do apply to the username/group are applied AND ALSO the default, as though they combine their blocks.

If the last statement above is true and it's (all policies which apply + default) on all users, how do I apply something to anonymous users, without also blocking non-anonymous users? In the example above, I don't want to block staff from proxies, but if I block anonymous via the Default policy, I also inadvertently block staff. I feel like we either need the ability to apply a policy to "anonymous" users or the ability to have a policy stop processing of any further policies (like the firewall rules).

12

20.7 Legacy Series / Failed 20.7 upgrade (twice)

« on: July 31, 2020, 05:39:19 pm »

Got the 20.1.9_1 patch the other day with no problem, nor have I ever had a patch fail before. Went to install the 20.7 upgrade and it took a bit of time, then finished successfully. Firewall came up, internet came up...then went down. I thought maybe it was a second required reboot, but then it came up, went down again.

Jumped over to console and found that once the firewall reached login, it stayed working fine for about 30 seconds, then spammed a few dozen pages of white text (too fast to grab any info), and rebooted. Over and over. Restored old copy, upgraded, same thing. Meanwhile, another firewall (same hardware and general config) is fine on 20.7.

Ended up having to restore back to 20.1.9_1. I'll update this post if I can duplicate the problem and grab text/logs.

13

20.1 Legacy Series / VoIP troubles

« on: June 17, 2020, 05:05:04 pm »

Having my first weird issue (two, actually, but I'll start with the one I care about). We recently installed an OPNsense 20.1.7 firewall for our small office. Everything worked great for a few days, then we got notified that all our remote workers were having calls drop on their VoIP lines. Essentially, the phone registers, then days later, it will still ring, but then have dead air if you pick up. Two or three tries from the same caller and suddenly it works again for a few hours. If they reboot the phone, everything's fine for a few days.

Specifics: We have remote workers with VoIP phones that connect to a PBX at our home office. I have NAT rules for the port range the phones use that forward traffic to the PBX. When the calls fail, I show no traffic on the firewall from that IP. At recommendation of other posts, I added an outbound NAT rule for the PBX and changed the firewall optimization to Conservative...this did not help.

Any suggestions to get these phones back online and to stay online?

Second minor issue:
Since 20.1.7, I've started getting a warning "A problem was detected" on some (not all) firewalls using LetsEncrypt. I can't find any known issue about this, so was curious if anyone knew why that might be happening. Only thing I can find is a PHP error: PHP Warning "continue" targeting switch is equivalent to "break"