Recent posts

#1

26.1, 26,4 Series / Re: how to create floating (an...

Last post by Netlearn - Today at 06:19:55 AM

I always read the notes that are being shown when I'm about to update.  I don't recall any mentioning of the new rules at all, though my memory isn't what it used to be.

Yet if there had been a suitable warning about the new rules like I suggested in my previous post, I would have remembered it.

It looks like you have not even read my post. There has been a whole lot of mentions to the new rules area, starting with version 26.1. To be clear, I will repeat it again:

o The firewall migration page is not something you need to jump into right away.  Please make yourself familiar with the new rules GUI first and check the documentation for incompatibilities.  Single interface from the floating interface will not be considered "floating" in priorities.

This just has been handled badly.

Did you absolutely need to migrate to a brand new rules GUI?
Did you check the exported ruleset on a spreadsheet?
Did you have a configuration backup?
Did you have an snapshot?
Did you try it on a test system beforehand?
Did you have a replicate machine to test the changes beforehand?
Do you have a written design of your ruleset?
Maybe it's you that are handling this badly?

Changes usually have some learning curve or adaptation from the user's perspective, but with the new-rules-GUI, you are not forced to change. Just stick to the well known rules-GUI. On the other hand, the best part of OPNsense is probably its active, participative and fast development, so I don't understand your anger with the devs about something absolutely new, and not forced until (at least) two more years (wow) of development.

You should always have a configuration backup (and best to add an snapshot) for your production firewall. If so, you simply recover the last good config are you are done, until you feel ready for the new-rules-GUI transition.

#2

26.1, 26,4 Series / Re: how to create floating (an...

Last post by passeri - Today at 05:36:27 AM

@defaultuserfoo, your experience may not be widely shared. For example, I clearly remember the advice and warnings in the documentation on 26.1, before I tested then fully migrated without issue. It follows that assaulting OPNsense and its documentation may not be the most fruitful path to assistance.

To your problem, it appears to me you are creating a global rule then trying to punch a hole in it. This may not be the best initial design. In a corresponding position, at the interface level I allow to any from my primary device, then in a subsequent rule use inversion to limit all others locally, with specific allows (NAT) then general blocks as desired for internet. No holes are punched in any prior rule. These migrated perfectly. I do also have a couple of floating rules covering DNS and NTP for everything. Again, no holes need be punched in that.

In general terms, my advice is first allow what you must, then block the rest. Design and review is a task prior to construction, like any systems design, so in my view your problem existed before your migration exposed it.

no more warning than to back up your configuration and/or to take a snapshot

If you are not taking a snapshot before any similar system modification then you are making a mistake with which I cannot otherwise help you.

[I]

#3

General Discussion / Re: How do IPv6 Router Adverti...

Last post by barney - Today at 04:59:52 AM

If the Dirigera has no internet access, how can devices behind it have internet?

Neither the Dirigera nor any of the devices behind have internet access (see note below) - all of my monitoring / automation is local using openHAB. If I want to access stuff remotely I can VPN in to my openHAB server and control it via that.

My problem was that the openHAB server on VLAN 20 could not access the individual devices on the VLAN 40 (IoT), so it couldn't commission / control the matter devices.

Note: I did need to allow the Dirigera internet access when first commissioning it as it wanted to check / download the latest firmware before letting me do anything. I'll also open that up again if later firmware is released. If specific device firmware updates are release I may need to allow the devices internet access at that time.

I have no real problem with connecting stuff to the cloud if they need it, but as a general approach I just don't let anything out unless I want it to - not because the manufacturer wants it! If I do ever get a device that really does require cloud access then I'll create a rule to let that out.

I shouldn't have assumed how your environment is.

No problem - I appreciate you taking the time help.

#4

Hardware and Performance / Re: "Intel CPU microcode updat...

Last post by drosophila - Today at 04:20:26 AM

Will installing both intel and amd microcode plugins break anything? It's obviously not going to do any good on any given system, but it would be nice to know that migrating an installation to another platform wouldn't be prone to lack of microcode updates that might keep it from booting up. IOW, similar to having assorted drivers installed that aren't used.

[is]

#5

General Discussion / Re: How do IPv6 Router Adverti...

Last post by OPNenthu - Today at 04:08:47 AM

Not sure what you mean here - the Dirigera is on the IoT VLAN?

I didn't notice that.  I'm sorry.

I don't generally 'constrain' anything directly. I log the default block rules and only create specific allow rules to pass the things I need. The only block rules I generally have are to intercept-and-not-log noisy clients before they get to the default block rule and get logged.

Understood.  In my environment all the local interfaces get internet access by default (I use a group level rule to allow egress), and for IoT that's just as well because they all need internet access.  I wouldn't try to block the Dirigera from the internet in the first place, but if I had to, I would need an interface level block specifically for that device.  Though I acknowledge that such a block can be circumvented with a spoofed MAC or a self-configured IP, so maybe not a great example. :)

I shouldn't have assumed how your environment is.

Also, just to note, the block rule you suggest would only capture traffic from the Dirigera itself, not from the thread devices behind it.

I'd like to understand this better.  If the Dirigera has no internet access, how can devices behind it have internet?  I assumed it's proxying their traffic but maybe I don't understand something.

Thank you, @barney.

#6

Hardware and Performance / Re: Gateway pings drastically ...

Last post by drosophila - Today at 03:52:10 AM

Sure is possible, there are all these QoS and fast path things that can be done on the ISP side. Also don't forget EEE and other power saving stuff that may kick in under negligible load.

#7

26.1, 26,4 Series / Re: how to create floating (an...

Last post by OPNenthu - Today at 03:47:44 AM

@defaultuserfoo - my response to @nero355's question really has nothing to do with your topic.  Apologies, we got off on a tangential discussion.  Nothing changed with regard to groups in 26.1 that I'm aware of.

AFAIK, the only impactful change is that floating rules now require more than one interface to be considered floating, else they move to the respective interface rulset.  That's nothing to do with the history of Floating as a concept.  Just a functional change in 26.1 (I'm not defending it).

You're a little bit all over the place with some of your interpretations and you're putting words in my mouth while trying to draw me in to your attacks against OPNsense.  For example I never said groups don't exist or that they cause chaos.

#8

26.1, 26,4 Series / Monit and STARTTLS Issue

Last post by Blackdragon83 - Today at 03:40:28 AM

Hello everyone,

I'm trying to set up a reporting system using Monit, with email alerts forwarded through my Hotmail account. However, the setup isn't working, and I'm receiving the following error:

SMTP: Mailserver response error -- 451 5.7.3 STARTTLS is required to send mail [DX0P273CA0003.AREP273.PROD.OUTLOOK.COM 2026-04-21T17:04:23.671Z 08DE9DD04CF197D8]

STARTTLS is mandatory for authentication, but it seems Monit isn't initiating a TLS connection properly. Has anyone successfully configured Monit to send emails via Hotmail/Outlook.com? If so, could you share the correct SMTP settings or any workarounds?

[is]

#9

General Discussion / Re: How do IPv6 Router Adverti...

Last post by barney - Today at 03:39:44 AM

By necessity of your design, since you split the hub off to a separate VLAN

Not sure what you mean here - the Dirigera is on the IoT VLAN?

if you really must constrain it and its downstream devices to the IOT network

I don't generally 'constrain' anything directly. I log the default block rules and only create specific allow rules to pass the things I need. The only block rules I generally have are to intercept-and-not-log noisy clients before they get to the default block rule and get logged.

Also, just to note, the block rule you suggest would only capture traffic from the Dirigera itself, not from the thread devices behind it.

Don't worry about the thread devices. They only know the thread network and can't get out.
...
One of the recent revisions of Matter introduced a feature to allow Matter devices to communicate with the world.

I think I must be using the latter... all of the matter devices in the thread network have a ULA IPv6 address that is routeable across the network (Dirigera supports Matter 1.4 if that makes a difference) - this is the address that is published in the mDNS message.

e.g. The Air Sensor has this:

Code (json) Select Expand

{
  "productName": "ALPSTUGA air quality monitor",
  "hardwareAddress": "c2be2a915b99fd5c",
  "iPv4Addresses": [],
  "iPv6Addresses": [
    "fde60a8291c018d8000000fffe002c00",
    "fd2cd79a65f90001a09ba0cb1f92985d",
    "fde60a8291c018d8d392333ab2732096",
    "fe80000000000000c0be2a915b99fd5c"
  ]
}
It has a link local fe80.. address and not sure what the fde6.. addresses are (Routing Locator maybe?), but the fd2c.. address is the one advertised in the mDNS message which OpenHab uses to control the devices - looks to me like the Mesh-Local EID that the OpenThread doco says "Does not change as the topology changes / Should be used by applications".

Anyway, it's all working as I wanted now: OpenHab can commission / control the matter devices and nothing on the IoT VLAN can start outbound connections other than to the OpenHab server (although I can see them trying to phone home and being blocked in the firewall logs). Just needed the gateway / static route and a firewall alias for the thread network (fd2c:d79a:65f9:1::/64) to write a couple of allow rules.

Appreciate you both taking the time to look at this.

#10

26.1, 26,4 Series / Re: how to create floating (an...

Last post by defaultuserfoo - Today at 03:20:50 AM

Please, read the release notes before upgrading. They are posted on a dedicated section of this forum and they are showed to the admin before upgrading, either by GUI or console.

I always read the notes that are being shown when I'm about to update.  I don't recall any mentioning of the new rules at all, though my memory isn't what it used to be.

Yet if there had been a suitable warning about the new rules like I suggested in my previous post, I would have remembered it.

I usually don't look into the forum.  One of the moderators drove me away by telling me to stop posting when I was trying to help, so now I only come here when I can't avoid it.

This just has been handled badly.