Topics

I noticed that the WOL widget always shows my WOL hosts as "online" instead of its true status.. I'm assuming this is because the widget is checking if the MAC is in the ARP table?  Is there any way to change this behavior to actually report if the host is up by pinging it?

Thanks

When going to Interfaces: Diagnostics: ARP Table, there is a hostname column..  However, on my system - exactly one host of around 120 in the table show a hostname .  Is this column supposed to populate with hostnames from someplace? 

I just updated to 21.1.7_1 but now, when I try to check for updates or install a plug-in, the System:Firmware Updates tab just displays a spinning circle and displays no output.. What can I do to fix this?

Thanks
Rick

Is it possible to fix the sort order when viewing the ARP tables and sorting by IP?

Mine go something like this:

Hi all.. I've been using Cloudflare DNS using DNS over TLS with Opnsense for quite some time now.. In previous versions, I was using the "Custom" field to specify the Cloudflare directives.. Now, I have that empty and I am using the "Miscellaneous" section of Unbound and using the "DNS over TLS Servers" section to specify 1.1.1.1@853 and 1.0.0.1@853.  At random times, clients on the LAN will not be able to resolve DNS entries.. Currently I only have the log level set to '2', but when the clients cant resolve these certain addresses, I am seeing this in the logs:

2020-09-07T10:03:26   unbound[23196]   [23196:0] info: query response was THROWAWAY
2020-09-07T10:03:26   unbound[23196]   [23196:0] info: reply from <.> 1.1.1.1#853
2020-09-07T10:03:26   unbound[23196]   [23196:0] info: response for www.tivo.com. TYPE65 IN
2020-09-07T10:03:26   unbound[23196]   [23196:0] info: query response was THROWAWAY
2020-09-07T10:03:26   unbound[23196]   [23196:0] info: reply from <.> 1.0.0.1#853

This seems to be an issue that pops up for many people at random times - just wondering if anyone has run into it and found any reliable workarounds.  The events are random, and often after a few minutes, they resolve properly.

This has been a problem.. Was doing this in 20.1 as well, a couple of people posted (including me) about how to resolve it and received no responses.  I have NetFlow turned off.. With NetFlow off, the firewall hangs up on reboot with the following when shutting down for at least a minute:
Cannot 'stop' flowd_aggregate. Set flowd_aggregate_enable to YES in /etc/rc.conf or use 'onestop' instead of 'stop'.


How do I resolve this when not using NetFlow? 

You used to be able to monitor the full status of the traffic shaper in the GUI which would dynamically display the queues along with how many packets were dropped, etc - similar to running ipfw sched show on the command line.. Is there any way to duplicate that functionality from the command line where it automatically refreshes, similar to how top works?

Is it possible to provide better options for zooming in to time periods on the Health graphs?  Especially on something like the quality graphs - being able to zoom in closer than a 20 hour period would be very helpful.. Or am I missing something? 

I upgraded my system from 19.7 to 20.1, I believe - on Friday last week.  Last night around 3:30 AM, it looks like the firewall rebooted for whatever reason and got stuck with these repeating "Damaged tar" messages.  I tried rebooting a couple more times with the same results.. I discovered that pressing CTRL-C allowed it to continue the boot and the firewall came back up.  I did one or two more reboots - but still got stuck with the damaged tar messages that required CTRL-C to finish booting.  I was getting ready to clean install and restore from a config backup when I rebooted one more time from the GUI, and this time it made it through the entire boot without issue. 

Any way I can figure out what this was/is?  I'm running on a Netgate RCC-VE2440 x64/serial with an Intel 30GB SSD.


Thanks
Rick

Hi all. I've had DDNS setup for quite some time to update Dnsomatic with Opnsense. I have several records in Dnsomatic that get updated, but ever since I updated from 19.1.3 to 19.1.4, I get an error from Cloudflare when Dnsomatic tries to update. This started with the first boot after the update where I immediately got an error. I have other services that update on the same Dnsomatic account, it just seems to be Cloudflare that complains. I get the error every 24 hours.
The error Cloudflare returns is "err A record with those settings already exists. (81058)"

Did something change with the DDNS client in 19.1.4?
Thanks
Rick

Earlier this morning, I changed from Prod to Devel and went from 18.7.10(3) to 19.1_r33.. I rebooted and changed my settings back to production and tried to use the unlock/upgrade button for 19.1.r1.. After two tries, those upgrades failed and it rolled back to 19.1_r33...  At some point, I think I tried "Update" instead of the "Unlock/Upgrade", and it pulled down this:

OPNsense 19.1.r2-amd64
FreeBSD 11.2-RELEASE-p7-HBSD
OpenSSL 1.0.2q 20 Nov 2018

Is this where I should be at this stage?  Is that RC2? 

Thanks,
Rick

Just got transparent proxy going here for the primary purpose of getting HTTPS Everywhere installed.. I followed the procedure detailed here:  https://medium.com/@privb0x23/minimal-cache-proxy-configuring-an-https-everywhere-squid-plugin-on-opnsense-80af717d40ab

I am not proxying HTTPS.. Only HTTP.. I wanted to also add some basic blacklisting for malware, phishing, and cryptojacking sites -- But when I enable remote blacklisting with the UT1 blacklist and those categories selected, Netflix stops working throughout the house.. Specifically, the following shows up in the Squid logs:

Code Select Expand

TCP_DENIED/403 6108 POST http://api-global.netflix.com/nq/nrdjs/pbo_logblob/%5E1.0.0/router - HIER_NONE/- text/html

Came across similar issues when searching for a solution related to pfSense where the fix is to uncheck "Do not allow IP-Addresses in URL" in pfSense.. Can anyone tell me how to set this configuration option for squid in OPNSense?

Thanks,
Rick

I was on 18.1.. Changed my settings to development and updated. Now I'm at r127... How do I get to RC2 from here?

Is it possible to make the tcptraceroute package available to install?

Thanks,
Rick

Can anyone tell me if there is a package for tcptraceroute - and if so, how can I install it on my OPNSense box?

Thanks,
Rick

Saw the upgrade available for 17.7.9... Did the required update to package manager, then did upgrade to 17.7.9... Crashed at end with message "An API exception occured
Error at /usr/local/opnsense/mvc/app/library/OPNsense/Core/Backend.php:95 - stream_socket_client(): unable to connect to unix:///var/run/configd.socket (Connection refused) (errno=2)"

Submitted the crash report to developers with above info.. Is the state of my system sound at the moment?

Is there a way to upgrade from 17.1.9 to 17.7.r1 from the command line in a stable way that will not mess up upgrading to the released 17.7 when it comes out?

Thanks
Rick

After updating my 17.1 machine to 17.1.1 this afternoon, I can no longer initiate an outgoing SSH connection to a remote server that listens for SSH connections on port 922.. If I try to perform the following from a shell connected directly to the router:

ssh remote-host.com -p 922 -l myusername

I get:
ssh: connect to host remote-host.com port 922: Operation not permitted

My LAN clients that attempt to connect to same timeout now.  I have a default outgoing LAN firewall rule that allows outgoing connections to all, and there is nothing being reported in the firewall logs that it is being blocked.

For the time being, I have changed the remote SSH server to listen on port 22, and that does work.  Likewise, if I attempt to change it to port 9222, it works. 

Did something change

It seems in the Details section of Insight, all of the dates are in European format (dd-mm-yy).  Is there any way to change that?

If, in the GUI, you delete pipes or queues from the traffic shaper, it appears that doing so does not actually flush them until a reboot is performed.  For example, if I delete a pipe from the GUI -- and then perform ipfw pipe show from a shell, the pipe I deleted is still there.  I can perform an ipfw pipe x flush to then actually delete it.  Is this expected behavior or is it a bug?