Messages

Something definitely went wrong somewhere. Just curious, what size environment is this installed in? I just installed the update in my home network yesterday and it has discovered 43 unique MACs. I've left the default settings alone on it. The log from yesterday is 25KB and only 223B from today.


When running "top" from the CLI, I did notice the hostwatch process near the top of the list with typical usage of 0.08% to 0.15% with occasional spikes to 0.35%
Still less that a whole percent, but still more than most processes.

EDIT: I should have read the post further down regarding similar issues. It has more info in there:  https://forum.opnsense.org/index.php?topic=50405.0

I am using community edition. I don't know what the business edition includes as far as pre-defined selections, but if the "blocklist.site" lists are not being maintained and stale, I would suggest researching others in the drop down list to use instead.

For what its worth, I did notice under Reports --> Unbound that the count of block sites remained the same after the upgrade even though the actual selections are now removed from the blocklist section, so what franco indicated probably was accurate and that the existing "blocklist.site" lists were still active just with no way to remove until you reconfigure. For me, I decided to research other lists and just rebuild my custom blocklist profile. Not a big deal, especially if it removes stale lists that I was unaware.

I've also been using the emerging threats feed list for many years before switching to Opnsense platform. It is maintained by Proofpoint, so I use the .txt links in the custom blocklist site list:  https://rules.emergingthreats.net

Whenever I set up the blocklist a while back, I had been using several of the "blocklist.site" entries. I didn't realize they had become stale over the past year as  this was a set-and-forget thing. I saw the release notes mentioned deprecating the "blocklist.site" entries, but didn't give it a thought to remove those before upgrading. Once I upgraded, I found remains of those entries in my list, but since they were removed I could not clean that up. I'm not sure if it caused any further issues, but I just deleted and reconfigured my blocklist under Unbound. You can see in my screenshot the remnants of the "blocklist.site" entries that I once had.

So if you are still using any "blocklist.site" entries, I recommend removing those from your list before upgrading to 25.7.10.
You cannot view this attachment.

My initial thought too was the bogon option being on by default is causing you issues. That article is a good reference for that. When I first set up my Opnsense box, I had it double NATed behind an old Fortigate 90D. I turned off the block private and bogon networks on the WAN port and had no issue completing my setup.

pfry, thank you for that link. I must have skipped over that part when going through the documentation. Most networks I set up I do just use a network management vlan as the untagged vlan between switches and firewalls, but I have seen others use vlan 1 as their untagged and then just disable vlan 1 on all the switches. I have not noticed any ill side effects yet. I have my Opnsense server connected to an Alcatel switch. I have just learned to live with the statistics showing ALL traffic combined for every vlan on the management untagged vlan, but I may now go back and redo this based on that recommendation.

Inxsible, that seems reasonable to just modify the xml file and reimport, but I would check to make sure you have your System -> Settings -> Administration "listen on interfaces" set to the appropriate interface / vlan you want to access it from. Also, make sure your firewall policy allows you to access the webUI, though the built-in anti lockout policies may have you covered.
When I mentioned having access to console, it was more for just updating the IP of your main interface just in case you do lose access you can easily change it back. As long as your PC is on the same vlan as your listening interface, you can always set your PC IP manually to match something in the same subnet as that interface.

You are correct in your assessment. With 192.168.40.0 assigned to the physical interface (seen as "lan" under your assignments), that traffic is untagged and will match to whatever your default vlan is on your switchport. Easiest way to change this would be to have console access to your Opnsense server. If that is not possible, put a PC in the same vlan as Opnsense, which sounds like that is already the case. Change the IP on Opnsense interface (assuming 192.168.50.1), then manually set your PC to something in that same subnet (192.168.50.2). You'll be able to reach your firewall now and then complete the vlan 40 setup. Just make sure your switches have an IP in the new vlan 50 and have that vlan 50 set to the default vlan between uplinks.

This seems like a pretty standard setup that you are proposing. If you ask 10 different network engineers, you'll probably get slightly different nuaunces between them. For me, I like having a dedicated network management vlan. This would be your default or native vlan between switches and firewall. This would be the address range to assign your managed switches and Opnsense. I threw my Aruba cluster APs on the network management scope also since I didn't feel a need to have them on their own AP management vlan. I would also suggest a server vlan since you mentioned having a NAS. I run a couple other servers (like Plex) so I created a vlan for just servers. My old Dell R210 (this runs my Opnsense) only has 2 ethernet ports, so I had to build all vlans under 1 port, but for home use and even small/medium office use 1Gb is plenty of bandwidth. You can get fancy and create a link aggregate (lagg) in Opnsense with eth1 and eth3 using LACP protocol and then create a port-channel (or linkagg depending on what vendor terminology you prefer) on the switch. That will give you 2Gb bandwidth for all vlans to route between one another if you feel like getting fancy. Again, 1Gb would be plenty, but since you have an unused port I threw that out there.

As for address space, your proposed 10.1.x.x as a /24 should suffice, unless you have more than 254 devices going into that vlan. In which case, I would suggest a 10 number like cookiemonster proposed so that you if you needed to extend a vlan's address range you can easily do so without running into the next. For example:
vlan 1 = 10.1.1.0/24
vlan 2 = 10.1.2.0/24

If you ever needed to extend vlan 1 to a /23, that address space would interfere with vlan 2. If you did this:
10.1.10.0/24
10.1.20.0/24

You would be able to extend your vlans subnet without interference. Just thoughts for future proofing.

Also remember that when creating your policies, think of the vlan just like an interface. Traffic coming in on vlan 1 is just like traffic coming in on a physical eth 1 interface.

I set mine up like this:
vlan 10 = network management 10.4.10.0/24
vlan 20 = servers 10.4.20.0/24
vlan 30 = hard wired PCs 10.4.30.0/24
vlan 40 = printers 10.4.40.0/24
vlan 50 = private wifi 10.4.50.0/24
vlan 60 = guest wifi 10.4.60.0/24

I didn't have to create vlan 10 on Opnsense since this is my native/default vlan - I just assigned IP 10.4.10.1 to my LAN facing port. I then created all vlans on the switches and used vlan 10 as the default/native on the uplink to Opnsense server and to each other switch uplink.

Good luck with your new build out!

I too am new to Opnsense, but not to FreeBSD. A base FreeBSD install is very light on disk usage requirements which it seems they've kept in mind when developing Opnsense. I too have 500GB storage (albeit spinning disks, but that doesn't matter here). If you go to shell prompt, run:

Code Select Expand

df -hThis will show how much space is actually being used. On my system, it is only using 1.3GB out of a formatted 440GB on root, which is less than 1% so it continues to show 0% on the dashboard. I do not have Netflow turned on, but if I did that usage would certainly change.