Messages

Did you have queries in relation to my reply to exactly this question from you here?

You can run a variety of OS using UTM on M-Macs but each is a sandbox. Primary communication will still be with MacOS as the host OS so even if you were to run Opnsense in FreeBSD on the Mac it would not protect your Mac as a whole.

Buy a small travel router to protect you in public places. I happen to use a Mikrotik. There are many good brands and models reviewed on the net.

You said the ASUS is on 192.168.50.1, which is a gateway.
Does the ASUS distribute IP addresses?

192.168.50.254/24 is not a static IP. It is the entire address space from .0 to .255, covering everything else to which you assigned "static" IPs, and the ASUS.

Basically, your IP addressing is up the creek. Which is your DHCP server?

From curiosity, why are you putting the Opnsense in bridge mode anyway, rather than it being the router? What are you gaining over a switch?

I suggest a default router configuration (LAN - WAN - others) with the Opnsense as router and ASUS in bridge mode, assuming the ASUS provides Wireless, else remove it or replace it with a switch.

Don't all the smart watches these days detect falls and possibly voice yells for help, and can be programmed to reach out?

Or phones.

You do not describe any special requirements so the Fritzbox or equivalent option could be good.

It seems to me that wanting to build your own machine while not distracting from your real work is inconsistent with not wanting to invest too much effort in Opnsense software.

If you think there is any chance you might want to exploit some aspect of Opnsense in the future, you could buy a Deciso box with business licence for something closer to an OOB solution with reliable and suitable hardware, lower maintenance effort, updates for security rather than for the leading edge.

My situation is somewhere in the substantial space between yourself and meyergru. I like playing and learning with routers yet I want something I can afford to ignore for a while, so I run the CE edition on Deciso hardware despite holding a current business licence.

While it is a suitable use case, thousands of clients are not pre-requisite for using Kea. In 25.1 I switched from ISC to Kea very easily. It is a good solution even with a few sub-nets and perhaps twenty clients. You have options.

I have used both. I replaced an i7 based 6-port (1 Gb) CWWK with a less powerful Dec 697. I gained 2.5 Gb ports, a smaller form factor and less heat, with less immediate benefits of purpose-designed hardware including memory and storage and greater confidence in the BIOS state.

I also supported Opnsense, and gained product support with assurance of compatibility.

I still use a 4-port (2.5 Gb) N100 CWWK internally, serving as a functional pre-test before upgrading the Dec697 to new releases, and have an older J3160 box (4 x 1 Gb) for exploration on the side.

Yes, the Chinese boxes usually work. Having the Deciso box lets me more easily forget about the critical router to get on with other things. It also offers an avenue for support other than donations, firstly buying the box and then if you wish renewing the business licence.

In my view it is possible to be too concerned about CPU speed and memory capacities. The Dec 697 load factors show it copes easily with its tasks, as did the J3160 prior to the i7 box which was gross over-kill. In fact the J3160 is my hardware backup in the unlikely event the Dec 697 should fail.

HTH

Did checks include the browser console log? I have no particular suggestion, just checking on the territory covered for location of the error.

I have some important listening to songbirds to do.

@coffeecup25 Banking on my recently acquired "nice guy" reputation :) firstly I am happy it is now working for you. Having a test bed, even pfsense rather than opnsense, can be useful and is something I do (with opnsense).

I might apologise for omitting the possible need to check DNS settings. My own IoT setup from which I plucked the example I gave includes a rule to redirect DNS to local, Unbound, and I have a floating rule for NTP. I omitted these because I was providing general advice, because I did not know your setup or your full needs.

I am long retired from consulting where an occasional role was managing and solving business-critical problems in IT-related space. Patrick's comment here deserves nailing to a wall.

I try to build a mental model of the situation you have at your place. That's challenging and exhausting, intellectually, and I need as much information as possible and very specifically when I ask a question, I need an answer to that question with just the facts. Not you jumping to conclusions based on your own understanding of the problem.

I learned opnsense having had only general involvement in networking, learning from Patrick, cookiemonster, meyergru, and others who have not posted in this particular thread as well as from reading, trying, reading again. They have different approaches, some more in tune with my own yet all with obvious expertise.

You have success for your initial question. I have always found that having supporting experts in specific domains is quite useful, worth retaining.

Yes, there are certainly other ways of doing it. The one I selected holds to my "allow required then block by default" policy even though logically these can be reversed into "block unwanted then allow the rest". As coffeecup25 notes, there is already an inversion in my rule by saying in effect "the WAN is not this group" so whether one is really saying allow-block or block-allow becomes moot. It is more important to hold a single [sense of your] logical model so that you can spot errors in your own rules more easily.

Create the interface as usual. It will have no access to anything.
Create an alias for RFC1918 addresses, call it something like "private_nets" or "rfc1918"
Create an Allow rule where source is your IoT port address and destination is private_nets with Destination/Invert ticked.

Other rules are possible. The above will give your IoT devices internet access without them access to anything local. It is all in one rule, not separate as you seem to imply.

It would be attractive for me also, especially where you could select the leases as @numachx suggests.

That sounds promising, Lantern5, assuming you are willing to do without / wait on a fix for ZenArmor.

While you had not mentioned you were running ZenArmor, I should still either have asked about other parts of the configuration or simply advised switching off all add-ons. As a comment, your additional tests changed the machine but not the NIC which was the more likely culprit, if ZenArmor were not intruding.

Thank you Lantern5. One test would be to try Opnsense on different hardware or at least with a different NIC, if you are able to. While I am also curious to know what DHCP you are running, it seems unlikely to be the problem given cycling the interface works. My conjecture is that the NIC itself is entering an unresponsive state when disconnected physically (LAN cable) or virtually (Opnsense restart) until it is itself re-initialised by one of the two means you mentioned. In that state its internal (to Opnsense) interface is up but its external (to LAN) is not -- it cannot even be pinged quite apart from not issuing addresses. That does not sound to me like an Opnsense problem.