Messages

Hello,

I have an issue that I have seen reported by others, but I think I was able to identify opnsense as the culprit, not my device.

I have a small IoT device that, for whatever reason, does not have a hardware MAC address. It generates a random address every time it boots up. I am looking into writing a custom u-boot for it to hard-code an address, but for now it has a new address each time it boots.

As an initial temporary measure, I created a startup script that brings down the interface, assigns a fixed MAC address and brings the interface back up. That is successful in getting the DHCP server to assign the static IP address that I want to use, but as others have reported, the IoT device does not have internet access after that change.

I was able to trace the issue to a logging problem. I am using Unbound DNS and when looking at the logs, I see entries for dhcp reporting a new dynamic IP address for the device as it boots up, but no report for the static assignment when the MAC address changes. It's as if Unbound does not realize there was a change and does not reply to requests from the static IP/MAC.

If the dhcp server is supposed to notify Unbound, then it would appear it is a dhcp server bug or misconfiguration. If Unbound is supposed to notice the change and respond accordingly, then the issue is there.

Any assistance is appreciated.

Update: I filed an issue report with Google: https://issuetracker.google.com/issues/289365943

It really depends on how critical they think it is to add support for POSIX systems. I think the fix might be fairly simple, but it will take some research and possibly submitting a patch to their team.

For now, I would recommend reverting the CLI sdk to version 419.0.0.0

Hi @siga75,

I ran into the same issue today (like you, when trying to update my certs). It appears to be an issue with the newer versions of the google-cloud-sdk.

I found a workaround here: https://issuetracker.google.com/issues/249727215#comment6

After updating the file, I reverted to version 419, which was listed in another issue as the last known version to work in FreeBSD, by issuing the command:

Code Select Expand

gcloud components update --version 419.0.0

Hope you have already solved the issue by the time I write this, but I am adding it for others who may not have seen the issue yet.

Hello,

I know this is an endless subject and a moving target, but I want to document my experience in any case.

I got a good deal on a mini PC with a Celeron J3455 CPU and two Realtek NICs (I think they are RTL8168). I wanted to install opnsense to replace a larger PC to reduce power consumption. I knew Intel NICs were the better choice, but I thought I would give it a try.

I was pleasantly surprised to see that a config running Suricata in IPS mode gave me 900+ Mbps on tests, but then saw that the interfaces would go down, showing "no carrier" errors after an hour or so of service. Only a reboot seemed to fix the problem. I installed the Realtek plug-in (BTW, thanks for that!) and had stable NICs that lasted days without issues, but then I could only get 400Mbps speeds. The driver was the only change.

My Internet connection is 1Gbps which means I can't use this mini PC as my firewall at the moment. Some FreeBSD forums seem to indicate that the native (re) driver has seen improvements over time, so I might be able to get speed and stability from a future version. They also mention that those improvements seem to go away between major releases.

Considering the current system's power consumption, I ordered a much more expensive mini PC with intel NICs, which I will be configuring soon. It will pay for itself eventually with power savings, but I would have preferred to be able to work with the good deal I got.

Does anyone else have similar experiences with getting only 50% speeds using the factory drivers? Can I use older drivers that perform better?

[New update (Dec 21, 2020)]

New update (Dec 21, 2020) Let's Encrypt announced on their blog (https://letsencrypt.org/2020/12/21/extending-android-compatibility.html) that they have a workaround for older Android devices.

This fix relies on an Android-specific implementation of certificate validation, which may or may not match other systems, like IoT devices or other OSs.

They also say that, since this workaround is supposed to prevent Android devices from having any issues, they will not implement changes they had in mind for January or February of 2021. This could be critical for anyone having certificates nearing expiration. On the other hand, if the Android issue is causing you pain with newly renewed certificates, you might want to force an early renewal to get things to work again.

It is important to test now and look for workarounds or fixes.

[upstream TLS]

Hello,

As stated in the unbound.conf page (https://www.nlnetlabs.nl/documentation/unbound/unbound.conf/), there is an option to turn on upstream TLS. I always assumed that by entering data into Unbound DNS/Miscelaneous/DNS over TLS Servers, this option would be turned on, but I spent some time examining the config files and I don't see an entry to enable it.

Code Select Expand

server:
   tls-upstream: yes
I believe the statement above would be needed to actually turn the feature on, in addition to the path to the certificates and the servers/ports. The latter two options are added in /usr/local/unbound/miscelaneous.conf, but I don't think the traffic is actually encrypted unless the tls-upstream option is used.

Can someone a) verify that my understanding is correct, and if so, b) direct me to the proper way to file this as a bug in the interface?

Thanks!

@Franco, thanks for the clarification. I didn't think to look for the kernel itself in the packages screen. Now I see it and I think I should have done that!

@Steve79, thanks for the update and the clarification. Yeah, without being able to see an actual certificate, my guess was, well, just a guess  :).

@Franco, thank you for your help. I am very glad this did not affect me directly, but still very thankful that you guys are so quick to fix stuff.

Hi there,

When I clicked on Audit/Health on the Opnsense GUI, I got the following output:

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
>>> Check installed kernel version
Version 20.7.4 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 20.7.4 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check for and install missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Checking core packages: .................................................................... done
***DONE***
Everything looks good, except I have version 20.7.5. Is this a typo in the check script, or is it really checking against the previous version?

Thanks in advance for your help!

@Steve79, yes, it looks like they switched on December 3. I got the impression, from reading their blog post, that they would not make the change until January 2021, but here we are.
https://twitter.com/letsencrypt/status/1334568843927228418

I'll try to edit my original post to correct that part.

You should still be able to renew the certificates by issuing the renew command with the alternate option, as referred in the Let's Encrypt blog post, but I am not sure the Opnsense GUI is aware of that option yet. I'm also happy to see that @Fraenki was on top of the issue and issued a hotfix with lightning speed!

I did not realize that so many systems would be impacted (even Android 10!) . I am lucky that my cert was renewed before the switch. I just happened to run into the announcement on Twitter and I thought it was important to post here.

If you can, please post progress on this thread. I know I will need to follow the same steps in the next few weeks.

[UPDATED Dec 21, 2020]

UPDATED Dec 21, 2020
Please see post in the thread below about fix for older Android devices from IdenTrust and Let's Encrypt

UPDATED Dec 5, 2020
Let's Encrypt switched to a new CA on Dec 3, 2020, and any certificates renewed or issued with default settings are affected. There is a hotfix for 20.7.5 to prevent Opnsense from reporting issues with the validity of renewed/new certificates. Please see the thread below for the link.

The original post mentions that the change will happen in January 2021, but Let's Encrypt already made the change. Presumably to coincide with their 5th year anniversary.

--- Original Post ---

If you use Let's Encrypt certificates for your firewall and perhaps other internal servers, this might affect you. Your certificates may start giving certain users/clients warnings that they are not valid, starting in January 2021. Please read on.

Currently, the root CA for Let's Encrypt is cross signed by another CA, which was widely available 5 years ago. This made Let's Encrypt's certificates valid from day 1 on many systems, including legacy systems. That root CA is up for renewal on September, 2021, and Let's Encrypt will replace it with a new CA, which is not cross-signed. This should not be a problem for any system that is regularly patched, but it is likely to be an issue with legacy systems that are not regularly updated, or for IoT setups that don't get new certificate store updates.

When you renew any Let's Encrypt certificates after January 2021, you will get certificates signed by the new CA. This may break SSL/TLS for those older/IoT systems. To help with the transition, Let's Encrypt will allow clients to request certificates signed with the old root. That will give you time to make whatever changes you need (including migrating to a different CA) before the September 2021 deadline when all new certificates will be signed by the new CA.

More info at https://letsencrypt.org/2020/11/06/own-two-feet.html

There are two other free alternatives to Let's Encrypt, which use the same setup: Buypass, and ZeroSSL. Migrating to either one could be as simple as changing the URL for the certificate request.

[os-google-cloud-sdk]

Hi Ishantz,

I have the Google Cloud SDK as well, but I don't see that problem in my installation. A quick search for 'google-api-php-client' returns the Github page where Google maintains the code. They say that this is an API to access their services, but they recommend a new API for Google Cloud because it is under active development and adding new features. https://github.com/googleapis/google-api-php-client

This is just my guess, but it is possible that an old installation of the os-google-cloud-sdk package added that API and a newer installation failed to remove it. I would suggest contacting the package maintainer. If you look at the info link in your system, you can find their email address there.

Even if they did not place it there, they might know why it is there, since they are familiar with Google services accessed from opnsense.

BTW: From the error log, this is not hurting anything. The script starts, can't find the account information, and exits with an error. But I believe you shouldn't have anything in your system you are not using. I agree with you that this should not be running in the first place.

Well, turns out that everything is the good old /var/log folder.

There are no kernel panics or any indication that the system is shutting down. I fear this is a hardware issue. HDD tests and Memory tests both passed. I turned on SMART tools and will monitor those for a while for errors.

I read that there were some issues with CPU patches for new vulnerabilities, but my symptoms don't match what I have read so far. I'll keep digging to see if there are any clues anywhere.

Hi there,

I am experiencing random reboots on my system (19.7.1). Not sure where to start looking for the cause. I don't think they are necessarily CPU panics, but I can't prove it yet. I have no problem with the command line, but I'm still a noob when it comes to Free-BSD. Browsing through the System logs with the web GUI has not given me anything. I can see when the system is starting, but I can't see when or why it went down.

Which file/directory is the best place to start looking? I have two approximate times to look for in the logs that can hopefully tell me how the system went down.

This is my home firewall and I don't really have a need for 24/7 internet, so my firewall goes down every day at night and starts in the morning. I don't think this is a stability issue, unless there are known problems with some CPUs or hardware.

My system is as follows:
OPNsense 19.7.2-amd64 -- Updated on 8/5/2019
FreeBSD 11.2-RELEASE-p12-HBSD
LibreSSL 2.9.2 -- Soon to revert back to OpenSSL
Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 cores)
8GB RAM
450GB HDD
Intel Gig Network cards for LAN and WAN
Plugins:
Suricata with Hyperscan enabled
UnboundDNS with DNSSEC enabled
WebProxy with some ACLs

This system should be overpowered for its load. Even with Suricata running, I never see significant memory usage and have lots of it assigned to Squid, for faster browsing. I don't think I had these problems before 19.7.1, but I can't be sure unless I dig into my log files. I work from home often, though, and I would definitely notice firewall reboots if they happened during office hours. I really think this is a new issue.

Thanks in advance for any help/advice.

Hello,

I was experiencing the same issue as is discussed in this post https://github.com/NethServer/dev/issues/5152, which says that unless the WAN IP address(es) is(are) in the Home Networks list, a number of Suricata rules won't fire.

To replicate it, I followed these steps:

• Created a new fingerprint rule in Services/Intrusion Detection/Administration/User defined
• The rule is an Alert with all the fields left blank and set to Alert, which should show all traffic passing through
• Hit Apply

I did not get any alerts from Suricata.

Then, I added my WAN interface IP address to Services/Intrusion Detection/Administration/Settings in the Home Networks field. I should say that Suricata was configured to look at LAN and WAN. Immediately after pressing Apply, I saw a flood of alerts, as I had expected before. I disabled the test Alert fingerprint rule and I started seeing blocked connections that were simply passing through before without firing any alerts.

The proposed change is to Add the WAN IP address to Home Networks when the WAN network is selected in the corresponding drop down. It might even make sense to enable it by default.

Thanks!