Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - passeri

#1
I have some important listening to songbirds to do.
#2
@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.
Quote from: Patrick M. Hausen on July 07, 2025, 01:08:23 AMI 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.
#3
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.
#4
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.
#5
It would be attractive for me also, especially where you could select the leases as @numachx suggests.
#6
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.
#7
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.
#8
Quote from: Lantern5 on June 12, 2025, 02:32:38 AMSince the Sophos + ER-X combo does not exhibit the same issues as Sophos + OPNSense; I came to the conclusion that the issue is not on the Sophos Box.
I did not imply I thought it was the Sophos box. The switch was from Lenovo M900 with its LAN ports to Ubiquiti ER-X, was it not? If not, what exactly are you swapping please? A labelled network diagram may be helpful

Quote from: Lantern5 on June 11, 2025, 11:12:28 AMThe em0 interface is up when I check via console, but does not respond to ping unless I power off the box and power it back up; or issue the ifconfig em0 down | up command
Quote from: Lantern5 on June 12, 2025, 02:32:38 AMI need to completely power down the OPNSense box after a reboot, or a LAN cable change; before the OPNSense box starts passing traffic on the LAN interface. The interface is up, but does not do anything.
[my emphases]

The bold parts of the statements are in conflict. What statement is both true and complete please?
#9
Quote from: Lantern5 on June 11, 2025, 01:40:58 PMI believe this is definitely an issue with OPNSense.
Why, when you have also changed the hardware?

Your problem appears to be that after a reboot of the Opnsense box you need to reboot it, or the LAN interface, a second time before it will respond on em0. Is that correct? I ask because your description is a little ambiguous.

The behaviour of em0 contrasts with igb0 which continues to operate normally.

Realtek aside, I know of no other cases of similar behaviour under Opnsense, certainly not on several different boxes which I have used. Your own case shows that Opnsense has no difficulty on igb0.

I would be looking at the NIC. Perhaps a workaround could be to add a script that issues ifconfig commands to cycle em0 after startup completes. I have not thought about how to do that.
#10
Yes, you could reset those devices to default.

That is my opinion, whereas Monviech's reply was a factual and reasonable response by an expert to an insufficiently-defined request. I realise that sounds a "tone-police" style of advice by me, please take it as kindly.
#11
Quote from: Monviech (Cedrik) on May 24, 2025, 02:26:52 PMThough this is the case with all of what Opnsense offers, just look at the complexity of firewalling and NAT. Some meticulously craft their rulesets, others will go for any any any
which is an important reminder thanks.

I can understand the interest when new features like the Unbound/DNSmasq integration are released. My own network is simple in some ways, being home user(s) only, yet with different services (some public) separated vertically and horizontally with a strong emphasis on security with minimised damage from possible failure. Consequently I need to know clearly where new features fit, what are the alternatives, so I can maintain a clean and useable system. I shall keep happily batting along with Kea while looking for improvements as we always do.
#12
I think that is the oddity, Monviech. The manual suggests only large or HA or complex installations might need Kea yet for basic DHCP with some reservations it is simple to implement and just works. That hardly defines as large or complex. People can use what they please though looking at MildDisaster's description of their progress, might they have had an easier time with Kea? That is not clear to me.
#13
OK, thanks, no special reasons after the need to move away from ISC. My choice for my small installation was Kea. It has been flawless so I remain curious about other experiences.
#14
I do not run DNSmasq. To help me understand the change, which reasons stated in the manual were persuasive for your particular case please?
#15
I switched from ISC to Kea. Unbound listens on all ports and I have a redirection rule for DNS. Kea is not involved.