Messages

Thanks for looking into this!

It happened again. mail.google.com was categorized as "Web Category: Advertisements". Again, clearing the cache fixed the problem... but why did it happen at all? Screenshot attached.

Here's a screenshot of another bizarre categorization that just happened (attached).

Sure, what should the bug report contain?

It seems to work at the moment, after clearing the cache as you suggested. But why was mail.google.com ever blocked as "Advertisements"?

Today I had both mail.google.com and www.jetbrains.com blocked as "Web Category" "Advertisements".

That's pretty bad. How are these categories decided? I didn't expect to have to whitelist Gmail...

maybe a reboot would also work

Rebooting didn't help me.

I'm not familiar with how FreeBSD packages work, but the problem seems to be something to do with how os-sensei handles its dependency on a PHP extension for MongoDB.

The dependency was satisfied by the PHP 7.4 extension - php74-pecl-mongodb - but that extension won't work with OPNsense 22.7 because it uses PHP 8.0. When OPNsense was upgraded, os-sensei's dependency should have also been upgraded, but it wasn't.

There is a way to change reporting database without uninstalling Zenarmor on OPNsense. Please follow the link.

I followed the instructions there and it did indeed allow me to choose a different reporting database. I chose MongoDB and it reinstalled the mongodb40 package. I see there's a php80-pecl-mongodb package installed now too. This seems to have fixed the problem with the Dashboard and Reports pages, thank you.

It's kind of annoying to have to go through the whole setup Wizard just to change databases though. I suppose it won't happen often so it isn't a big deal.

Also, I noticed that before I did this, the Zenconsole wouldn't let me switch back to MongoDB. It only listed SQLite and ElasticSearch as options.

Anyway, it all seems to be working with OPNsense 22.7 now.

I have had a similar experience:

• After upgrading to OPNsense 22.7, I saw the same error: Unable to load dynamic library 'mongodb.so'
• I removed the PHP 7.4 extension for MongoDB: pkg remove php74-pecl-mongodb
• That fixed the error, but now I couldn't see anything on the Dashboard or Reports pages
• I tried re-installing Zenarmor with pkg install -f os-sensei but that made no difference
• I enabled Cloud Management, then using Zenconsole I switched from MongoDB to SQLite for reporting
• Now the Dashboard and Reports pages work again

I assume the problem is that Zenarmor was using the PHP 7.4 extension for MongoDB but OPNSense has now upgraded to PHP 8. Is there no equivalent extension for PHP 8 that Zenarmor could use?

I'm happy with SQLite but obviously this is a problem for people who want to use MongoDB.

Also, is there no way to switch between different reporting databases without using Cloud Management? I don't mind using Zenconsole but I had never needed to before. I quite like being able to control everything from the same OPNsense Web GUI.

There was one other bug: right after I had changed from MongoDB to SQLite, the Threats tab on the Reports page didn't work. I guess there wasn't any data yet - no threats had been recorded - and the PHP code doesn't handle that situation correctly: I can't find the error in my logs now, but it was something about treating a bool as an array. Now that I have some threat data in the database, it works.

Warez is definition for torrents and P2P clients

I think you've got that backwards: Warez refers to pirated software. They may often be distributed via P2P networks but they don't have to be. Any pirated software, however it is distributed, is warez.

See: https://en.wikipedia.org/wiki/Warez

Thank you for the clarification, that makes sense.

In this particular case, the pornographic images weren't ads: if they were, I hope they would have been blocked by Zenarmor's ad blocking anyway. That game site has a lot of pornographic games: interactive movies with sex scenes, etc.

It also has pirated games, so I guess it is both "Warez" and "Pornography" (or possibly "Adult", if you don't count CGI sex as porn).

When you say "TLS inspection feature", do you mean that Zenarmor will support man-in-the-middle for HTTPS filtering?

That would be cool.

I finally worked it out. I took a look with Wireshark and found that even when I cleared the cache and hard refreshed Youtube, the initial packet to youtube.com was TLS "Application Data" - Chrome never sent a "Client Hello" message to begin a new TLS session.

This really confused me, until I realized that the same IP addresses are used for multiple Google services. For example:

www.youtube.com.   71094   IN   CNAME   youtube-ui.l.google.com.
youtube-ui.l.google.com. 89   IN   A   142.250.178.14

And also:

contacts.google.com.   3032   IN   CNAME   plus.l.google.com.
plus.l.google.com.   66   IN   A   142.250.178.14

So if you've already connected to one Google service - for example, Gmail, or maybe you've just logged into your Google account - then Chrome already has a TCP connection open to a youtube.com IP address. Since it's using HTTP/2, it is allowed to re-use an existing TCP connection, provided that the TLS certificate is valid. Google uses a wildcard certificate that matches all their services, so the cert will be valid, so Chrome can re-use the existing TLS session. It doesn't send a new Client Hello message, so it doesn't ever send an SNI field containing the hostname, so Zenarmor can't tell that this TLS data is web traffic for youtube.com.

In "Web Controls", there's an "Adult" category and a "Pornography" category. What's the difference?

Also, what category should a site that offers pornographic games be in? For example, repacklab.com is currently categorized in "Games" but its front-page contains pornographic images (albeit 3D renders, not photos). I was going to request a re-classification to "Pornography"... but then I spotted the "Adult" category... and now I'm not sure what it should be.

I don't claim any expertise in these matters, but RFC 9000 seems to indicate that QUIC can use any port: https://datatracker.ietf.org/doc/html/rfc9000

Maybe it's only used for websites at the moment though, so people only use it on ports associated with HTTP and HTTPS, perhaps?

Ian Swett, one of the Google engineers responsible for QUIC, claims that Chrome uses both port 80 and port 443, see https://groups.google.com/a/chromium.org/g/proto-quic/c/ksokVdwXfQ0

However, blocking both UDP/80 and UDP/443 doesn't stop Chrome from loading youtube.com anyway.