Messages

Are you an AI bot?

That depends on your definition of AI.

One or more of the above. Some are legitimate, some are... elective. Like most folks, I have some real constraints, and I go out of my way to find others.

Well, there's two solutions for that.
1) Obtain some free power from sunlight, have a battery (charged by sunlight) that powers it when the sunlight is dark. So free power here.
2) Lower heat means lower used wattage. Devices rarely use full rated power, but using less power means less heat. If the heat dissipation vectors are an issue (like in small enclosure or room), then some sort of ductwork and fan is needed to move the heat elsewhere.

Not knowing the actual constraints means less fruitful answers.

I can take things one at a time and simply start with a good, fast, router.

But w/o some metrics how do we now what you mean by "good" and "fast"?
Are you talking about 10Gb all day long, a 100Mb on occasion? How much encryption will be done?

You can tune cpu power down to whatever min level you can tolerate. Dozing cpu means it takes longer to wake up.

What's the concern about power use? Cost of the power, the heat it makes, other?

As far as notify on updates, check this one https://forum.opnsense.org/index.php?topic=23227.0
I however have a shell script (for another product I have) that checks to see if a web path has something new, and if it does the script pulls it down via wget. You can easily do checking using any scripting you like, just go look at a download mirror to see what that latest version is. This is just for OPNsense. Just open a mirror and look:
https://mirror.sfo12.us.leaseweb.net/opnsense/releases/
https://mirror.vraphim.com/opnsense/releases/
https://mirror.raiolanetworks.com/opnsense/releases/

What do the grid line numbers mean? A nice "uniform" bell curve in that widget, that alone seems odd because there's nothing the CPU is doing that looks like that. It usually just ramps up almost instantaneously, and then dwindles down at a fast pace, so I would expect to see more of a sawtooth pattern.

I don't know, CPU widget doesn't see all that useful to me.

cpu load stats from top (also a widget) is all that really matters.

Seeing a graph that says cpu is doing something, is not all that interesting.

Use tcpdump on site-A wan, see if your expected vpn-icmp is hitting the wire there outside the vpn. Then you'll know where to look.

Log file hunting will give an answer perhaps.
Maybe in /var/log/utx.log or /var/log/messages

Where in the full fw ruleset does the float show up?

How does Float rules get applied? IN or OUT on an iface?
What iface is your rule attached to? What iface is your pc closest to?
What about NAT, could the NAT occur before the Float and it misses a match?

Can you do packet captures using tcpdump, lets see what it looks like.

Than you should go with OPNsense.

Agreed. Just do it.

As to Cloudflare, I view them as extortion racket and treat them accordingly. They can go and do whatever.

I think you missed the point.
Cloudflare (and many others) already does the GeoIP blocking (without issue), and, you stated you see an issue with your current solution. You're arguing why the better choice is a bad choice.

Maybe MaxMind-dev can ID the issue and provide solution for fix.

Well, let's start with some basics around proxy.

Is the proxy doing man-middle for TLS? If not then any security control that needs to scrub the payload will be completely moot.

If your proxy setup is all good with trusted certs for end-users (basically one trusted cert to impersonate all dst URI), then the security controls can work on the payload. Is clam-av any good? It's something, but the bad folks know how to skirt around it.

Example, send some questionable exe's to virus-total, the big list of scanners there will scrub it, most will say the exe is ok, a few will say not.

So, is clam-av any good for you? Debatable for sure. But I can say for sure, is something better than nothing?

First, I need to know whether ClamAV works conceptually. So far this is inconclusive.

Short answer is yes. If you want the long answer than you need to define a lot of other things. It works to some extent, and the shortfalls are well documented.

To help with the short answer, three readings are provided:

1) https://docs.opnsense.org/manual/how-tos/clamav.html
2) https://forum.opnsense.org/index.php?topic=19460.0
3) https://en.wikipedia.org/wiki/ClamAV

1) Put the Logout button in the top static area, not in the Lobby
2) Make some/all the auto-gen rules supersede state table. As example, if I click "block rfc1918" on WAN iface setting, then a outbound SYN for a rfc1918 will have the SYN-ACK blocked on return because src IP will be rfc1918 WAN inbound, (block any protocol, etc). This is basic IP spoofing stuff. Technically, that setting should create two block rules, one src block WAN-in, and another dst block WAN-out.
3) The gui menu on left side, make each section expandable/collapsible (and stick open), this way we can switch between different sections more quickly.

and 4) The small System Status icon next to hostname in upper area of gui, put it to more good use. Make script or the like (aka "feature") to pull CVE info from NVD related to installed versions freeBSD and OPNsense, and monitor NIST NVD (eg; https://services.nvd.nist.gov/rest/json/cves/2.0?cpeName=cpe:2.3:a:opnsense:opnsense:25.7:*:*:*:*:*:*:*) and when something matches the versions you blink the status icon, giving users a heads-up. This helps the community be a tad more proactive with the knowledge (workarounds, mitigating control, nothing to do if CVE is a specific feature and you don't use that feature, etc). Maybe even create an "email me" option for such feature, like "email me a notice every X hours when there's a known CVE", etc.

check sysctl for dev.cpu.1.cx_lowest (dev.cpu.[cpu num].cx_lowest)

Are any C2 or C3 ??

I not expecting that setting to cause full sleep.

Is sleepd running in your ps list?

What's the WAN side of the fw? Is it a modem, or a direct cooper/fiber connection?
If it's a modem, then having a modem that is configurable in some way is ideal, so you can dump blocking ACL's there, to keep that noise from touching your fw. If it's direct copper/fiber connection, then ask your ISP if there's a place you can add such ACL's.

Last resort, stick a basic router between ISP and your fw and put your blocking ACL's there. I forget what the fastest drop method is, is sending the noise to /dev/null a fast way? You might even find some GeoIP software to put on that basic router, this way it's more like what you are wanting,blocking by name and the list gets updated every 4 or 12 or 24hr, etc.

Bit bucket the noise, so the noise is not being processed by the fw iface.

You have net exposed services and want to use GeoIP blocking? Consider fronting it via Cloudflare or similar, then use their GeoIP blocking options.

Blocking by GeoIP is not a fruitful way to block real adversaries. If the target is say in US, adversaries will establish a jump point in the US, thereby making your GeoIP control a bit moot.

GeoIP blocking is a noise control, it's not an adversary control.