Messages

Hi,

I apologize if this has been asked already.  I did a search and didn't find anything that answered my question.

I'm testing the new 26.1.2 release.  As part of the rule migration assistant, the last step is to perform the "Remove all legacy rules" action.

I've imported the rules and compared what's listed under "Rules" vs "Rules [New]" and I don't see anything missing/different.  Beyond that, what other validation checks should I perform before I proceed with the last step of removing legacy rules?  

I assume "Remove all legacy rules" will clear out any rules seen under under Firewall > Rules.

Thanks

[except]

Yes, I do want to block all internet access to vmx1 (my MGMT network) except for the sites I've configured under Exclusions. 

When I was on Zen Armor 2.1.1 and earlier, it worked as described above.  After upgrading to newer versions of Zen Armor, I now have to disable the use of "Block all internet access" so that my computer on the same subnet can reach OPNsense, but what is so confusing about this is either:
A) Zen Armor wasn't working properly before the upgrade, and the upgrade "fixed" it, or
B) Zen Armor was working properly before the upgrade, and the upgrade broke it. 

I don't know which it is. 

EDIT: I reached out to Zen Armor support.  They confirmed that the version I was using previously, 2.1.1, in fact DID have an issue which was resolved in newer versions.  This is taken from their release notes page for v2.2: https://www.zenarmor.com/docs/support/release-notes

The issue allowing clients to access whitelisted domains unexpectedly, even with the No Internet option selected in the policy, has been resolved.

This means that when working correctly, with "Block all internet access" enabled, it takes precedence over the whitelisted URLs configured under Exclusions.  It doesn't matter that my computer is on the same subnet and not trying to reach the internet, it being blocked is by design when enabling "Block all internet access".  Personally, I think it should be renamed to "Block all network and internet access" to be crystal clear.  

Zen Armor support also suggested an alternative configuration.  On my policy, leave "Block all internet access" turned off.  On the same policy, under App Controls, turn on the block for Secure Web Browsing and Web Browsing.  This would block all HTTP and HTTPS traffic, except for any of the whitelisted addresses I defined under Exclusions.  

Hope this helps others.  

Hi, 

This is the block message:
You cannot view this attachment.

It says "Default policy block".  I think it's saying the Default policy which comes with Zen Armor out of the box is applying to my workstation?  I don't understand why though.  My MGMT_policy is specifically configured to apply to vmx1 and 192.168.2.0/24, both of which corresponds to the MGMT interface and MGMT subnet of OPNsense. 
You cannot view this attachment.

 If anything should be blocking my workstation (192.168.2.99), shouldn't it be whatever is configured within the MGMT_Policy, and not the Default policy?  The block message even shows "MGMT_Policy" under the Policy column.  

Hi,

Since December of last year, I've been troubleshooting what I originally thought was an OPNsense upgrade issue, but I have now instead determined to be a Zen Armor-specific upgrade issue. 

My current OPNsense setup:

• Multiple interfaces - LAN, MGMT, WAN
• Zen Armor has been installed since late summer 2025
• The MGMT network has its own Zen Armor policy assigned to it named MGMT_Policy, which has "Block all internet access" turned ON.
• I manage OPNsense through it's MGMT interface IP - https://192.168.2.251/

I was on Zen Armor version 2.1.1.  If I upgrade to the newest version available, currently 2.3.2, I can no longer reach the OPNsense web URL https://192.168.2.251.  I've included screenshots below which shows the live sessions page, before and after the upgrade.  Before the upgrade, you can see my workstation (192.168.2.99) is able to reach the web URL of .251.  After the upgrade, the workstation is blocked from accessing the same .251 IP.  Besides upgrading Zen Armor, nothing else changed.  I did not make any changes to the policy, the IPs, firewall rules, nothing at all. 
You cannot view this attachment.
You cannot view this attachment.

I don't think this is specific to the latest version of Zen Armor.  I only know that it began with a version after 2.1.1. 

Post-upgrade, if I turn off "Block all internet access" on my MGMT_Policy, my workstation (192.168.2.99) can once again access https://192.168.2.251. 

Can someone provide insight as to why an upgrade to Zen Armor would change the behavior of the policy? 

Thank you

[NOT]

The packet capture I performed was directly on the OPNsense VM.  I did it from Interfaces > Diagnostics > Packet Capture.  I captured it while trying to access https://192.168.2.251/ from the workstation.  The screenshot I shared was when I downloaded the pcap file and opened it in Wireshark.  It shows the client (192.168.2.99) sending a TLS hello to OPNsense, but OPNsense doesn't say anything in response. 

I think packet capture and tcpdump are the same unless I'm mistaken. 

EDIT: I think the culprit is Zen Armor.  I can see in Zen Armor's live session report my workstation is being blocked when trying to access https://192.168.2.251/.  It's being categorized as "Secure web access".   Looking at the specific Zen Armor policy attached to this MGMT interface, I did NOT specifically block Secure Web Browsing; it's actually enabled.  Rather, on the policy itself, I have enabled "Block all internet access (overrides all configured policy rules)".  If I disable this block, my workstation can then access https://192.168.2.251 successfully.  If I re-enable it, I lose access again.

How this Zen Armor policy has been configured has not changed.  I've had this set for several versions of Opnsense before without issue, meaning I've been able to access my MGMT interface no problem.  I guess something changed with the logic within a newer version of Zen Armor that was installed when I so happened to upgrade to a newer version of Opnsense.  

Thank you for your reply.  Correct, 192.168.2.251 is OPNsense.

To remove the possibility of the firewall rules influencing the issue, I removed my MGMT interface (which corresponds to the 192.168.2.251 IP) from opnsense and re-added it.  I did this under the Interfaces > Assignments section of the web GUI.  I then re-added it using the same device ID.  This removed ALL firewall rules previously associated with that MGMT interface.  Afte re-adding that interface, I was left with 0 rules attached to it.  I then created 1 rule seen below which allows all IPv4 and all protocols to access 192.168.2.251:
You cannot view this attachment.
On a computer (192.168.2.99) that's on the same MGMT subnet, I tried to access OPNsense via https://192.168.2.251 while performing the packet capture in opnsense.  The packet capture seems to show the computer sending a TLS client hello, but receiving no response back.  I think this is the root cause of my issue. 
You cannot view this attachment.
Again, I have my MGMT interface listed as a listening interface.  How else do I ensure that OPNsense responds to TLS communication?

You cannot view this attachment.

[only]

Hi, I'm still looking for guidance with this.

I performed the upgrade again.  Predictably, after the upgrade, I cannot login to the web GUI (site cannot be reached) and ssh attempts return a "connection closed by remote host" msg.  These were both working prior to the upgrade.  I _CAN_ ping the IP successfully though. 

I connected to the console.  Looking at /var/log/lighttpd/latest.log, I don't see any suspicious events that correspond to my attempts to access the web GUI.  I don't even know if this is the right log to look at. 

Google said to check lighttpd.  At the console, I ran "service lighttpd status" which said lighttpd is not running. 
I then ran 'service lighttpd start', which returned a msg lighttpd could not be started, and to set lighttpd_enable to yes inside /etc/rc.conf, or use onestart instead of start. 
I instead ran 'service lighttpd onestart' which seemed to start lighttpd.  I still can't access the web GUI though. 

EDIT:
My opnsense VM has 4 interfaces: Guest, LAN, MGMT, and WAN.
I've always locked it down so that only traffic from the MGMT interface can access the web logon of opnsense.   
I reverted to a snapshot I had take of the opnsense VM prior to having upgraded it to the latest version.  In the Settings > Administration page, I added my LAN interface as a listening interface for opnsense web GUI.  I did this just to see if by chance another interface suffered the same issue as MGMT.  I then performed the upgrade to the latest version of opnsense.  I still cannot access the web gui from the MGMT IP as I originally reported, but I can access it from the LAN IP.   
From my computer on the same MGMT network, I used arp to confirm that the MGMT IP of opnsense correctly matches the MAC address of the MGMT interface of opnsense, so it's not an IP conflict.

root@OPNsense:/conf # sockstat -4 -l |egrep '22|443'
root     lighttpd   31157 7   tcp4   127.0.0.1:443         *:*
root     lighttpd   31157 10  tcp4   192.168.20.251:443    *:*
root     lighttpd   31157 11  tcp4   192.168.2.251:443     *:*
root     sshd        3562 6   tcp4   192.168.2.251:22      *:*
root     sshd        3562 7   tcp4   192.168.20.251:22     *:*
root     sshd        3562 10  tcp4   127.0.0.1:22          *:*
root     ntpd       40964 22  udp4   192.168.66.250:123    *:*

Unless I'm reading this incorrectly, opnsense is listening on both my LAN subnet (192.168.20.251) and MGMT subnet (192.168.2.251) for both ports 443 and 22.

Again, please, can someone help direct me how else to troubleshoot this?

Thank you

Hi,

Yesterday, I upgraded from OPNsense 25.7.7.2 to 25.7.9.  Each time after it's done upgrading and finished rebooting, the web logon GUI becomes inaccessible.  The IP continues to respond to ping, but the web page doesn't return the login page in the browser.  It also stops accepting connections via SSH, whereas it worked prior to the upgrade. 

Prior to the upgrade, OPNsense was working fine.  I was able to initiate the upgrade through the web GUI portal. 

Troubleshooting steps I've tried to no avail (on top of reverting the OPNsense VM to backup)
-via CLI of the OPNsense VM as root and running 'configctl webgui restart renew' and 'service config restart'
-via CLI, confirming the correct IP is set, and changing it from HTTPS to HTTP
-via CLI, looking at /conf/config.xml, I see <interfaces>opt1</interfaces>, which I think references the interface it listens on for the webgui.  Opt1 is correct. 

Of the dozen times I've performed an upgrade to OPNsense  in the past via the web gui, it's never done this.  What am I missing? 

Looking for advice, thank you. 

[primary]

Hi,

Could you verify whether the hostnames appear in the Live Sessions - Connections report under the Source Hostname column?

I looked and the majority of them only show IP addresses.  For the ones that do show hostnames, I confirmed that they do not have an entry under Aliases in OPNsense, nor are they statically defined in Unbound DNS. 

I think I found the root cause of my issue:

• When I first reported my issue, I had 2 local DNS servers defined under DNS Enrichment.  I removed 1 of them. 
• The remaining DNS server is a domain controller, and it had its own primary DNS pointed at OPNsense under its NIC adapter settings.  I updated it so that it points to itself as the primary DNS. 
• Reading online, for domain controllers, the NIC adapter should not be used to specify which DNS to use for recursive DNS lookups.  Instead, a proper DNS forwarder should be configured via the DNS Manager.  I did this, and pointed the forwarder to OPNsense.

With how it was configured previously, I think it was causing a vicious loop of the DC and OPNsense querying each other and not going anywhere. 

Now with the changes I listed above, I see hostnames correctly populating in the Live Sessions view and Reports. 

Hope this helps others.   

I've already enabled real-tiome DNS enrichment in Zen Armor, under Settings > DNS Enrichment.  I've added DNS servers to the list as well.  However, when I look at the Recent Devices section, 99% of them show up as "Other Device" instead of showing its actual hostname.  In my Reports, I see MAC addresses for the vast majority of devices, instead of hostnames. 

To troubleshoot, I SSH'd to the server and performed an nslookup, specifying the DNS servers.  (nslookup <IP address of computer> <DNS server IP>) and it was able to resolve to hostname successfully, so this tells me opnsense can successfully reach the DNS server I had specified and process the lookup.  

Any ideas?

Thank you

I installed Observium and found the graph as you described.  I'm performing speedtests from a computer but Observium's graph do not reflect the same figures.

Here's my data path:
Workstation (LAN) using OPNSense as it's default gateway.
OPNsense using it's WAN interface to go to the internet.

On my workstation, I'm performing a Google speedtest which is reporting 765 Mbps download and 207 Mbps upload.

My expectation is that when I look at the traffic graph in Observium corresponding to the WAN port of the OPNSense firewall, I should see similar corresponding figures, since traffic has to leave the WAN port of OPNSense to actually perform the speedtest.  I should see a max of around 700 Mbps in, and a 200 Mbps out.  Instead, the graph shows only a max of 43 Mbps in, and 31 Mbps out.

Hi, is that feature part of the paid subscription of Observium?  Thank you

Hi Patrick, thanks for your response. 

Per your suggestion, I looked at both LibreNMS and Observium.  I appreciate how they both link to a live demo system for me to evaluate their software in action.  However, I don't see any report on min/max/avg. bandwidth speeds.  The closest I could find is the transfer graph in Observium which shows total bandwidth transferred, but no mention of speed.  In other words, I can see that on XYZ day, 5.3GB was transferred, but I don't know how fast it was, the peak, or avg, in Mbps.

Maybe this is due to my unfamiliarity with using either app?  I'm reluctant to invest the time and money to install a VM and learn the apps only to find out it still doesn't do what I need.

I found bandwidthd which may have what I need (minus the ability to select a start/end time to generate a report): https://bandwidthd.sourceforge.net/demo/.

Thank you again.

Hi everyone,

I work for an organization which is paying $$$$ for their WAN internet connection.  It would be beneficial to generate a report to show the org what their actual usage is.  My needs:

• Peak usage, in megabits/sec
• Avg usage, preferably with an interval that can be defined, eg: avg usage over 24 hours, avg over 5 days, etc
• Be able to specify a start/end date for report to evaluate historical figures
• Identify the src or dest. hostname, IP, or OPNSense interface, to categorize and include/exclude them from the report

This report would help us determine if we're overutilizing/underutilizing the WAN connection, on what dates, by which devices, and their use case. 

I've evaluated the following that's native to OPNSense:
Reporting > Traffic - This shows data only in real time.  There's no reporting option available to look at historical metrics. 
Reporting > Insight - This covers most of my asks, but the biggest downside is that the .csv reports it generates does not show speed in terms of bytes, but in packets.  The 'Details' tab in the web GUI shows bytes, but it's bandwidth usage, not bandwidth speed. 

VnStat plugin - This shows bandwidth speed.  I can see HH/DD/MM/YY stats, which is awesome.  I can't specify exact dates/times, which is fine.  The drawback is it doesn't list the hostname/IP of that traffic, so I don't know what is consuming the data. 

I *think* there's no perfect option that meets my needs, and I'm left to just take all the various reports and try to generate my own report manually.  I hope I'm wrong and someone here can suggest something that can answer my needs?

Thank you very much for your time.