Messages

I don't think I'm necro'ing this thread since I'm using identical hardware (APU2E4,) just on a later version of OPNsense which may have broken something.

My system:

Code Select Expand

root@myopnsenserouter:~ # uname -a
FreeBSD myopnsenserouter.mydomain.com 13.2-RELEASE-p10 FreeBSD 13.2-RELEASE-p10 stable/24.1-n254984-f7b006edfa8 SMP amd64

I installed turbostat, and after successfully loading the kernel module:

Code Select Expand

kldload cpuctl


when running turbostat it executes and appears to start OK, but after 5 seconds it core-dumps:

Code Select Expand

root@myopnsenserouter:~ # turbostat
turbostat version 17.06.23 - Len Brown <lenb@kernel.org>
CPUID(0): AuthenticAMD 13 CPUID levels; family:model:stepping 0xf:30:1 (15:48:1)
CPUID(1): SSE3 MONITOR - - - TSC MSR - -
CPUID(6): APERF, No-TURBO, No-DTS, No-PTM, No-HWP, No-HWPnotify, No-HWPwindow, No-HWPepp, No-HWPpkg, No-EPB
CPUID(7): No-SGX
NSFOD /sys/devices/system/cpu/cpu3/cpufreq/scaling_driver
Floating exception (core dumped)



Here is the dmesg output:

Code Select Expand

pid 65735 (turbostat), jid 0, uid 0: exited on signal 8 (core dumped)

My intuition is that the device tree or device names have moved & turbostat is simply crashing because it can't find the device to sample?

Any further hints or comments as to how to fix this, or if turbostat's functionality is broken by changes in OPNsense over the past couple years?

....But here I can't see the point as the traffic is checked but not blocked without IPS anyway, so I can't see why this would cut the download performance that hard.

What is the make,  model, & specifications (RAM amount, CPU speed, # of CPU cores, etc.) of the hardware your OPNsense instance (router) is running on?

What is the bandwidth of your internet connection, in Mbps or Gbps per second?  Fiber? Cable? Which provider?

If it's easy to customize that beep sound it'd be nice to be able to fully-configure the beep parameters, i.e. the number, tone, and spacing of beeps. Is there a config file that can be played with to achieve that or is it hard-coded?

Just chiming in here --

Thanks very much doing all the work on this How-To, OP, and for keeping it updated, etc.
I successfully implemented it in my modest OPNsense instances/networks, before realizing that for small networks where there may never be more than perhaps 1 to 3 people logging in to a given OPNsense instance, in fact it's far more secure to simply shut off all HTTP listening on external network ports, and instead use SSH tunnels / port redirects, i.e. ssh -L 9450:localhost:80 my.opnsense.host to connect directly to the opnSense instance and access the webgui that way.  Then it doesn't matter at all whether HTTPS is active as the entire connection takes place inside the highly-secured SSH network connection.  With SSL tunnels there is no need for a webgui process to be listening anywhere except localhost:80.

It avoids the major overhead and ongoing maintenance complexity of getting a public/real SSL certificate issued, emplaced, and dealing with ongoing renewals, etc.

Replying here because I also have a couple of pre-existing Wireguard tunnels.

In my case, upgrading from 24.1.1 --> 24.1.2 went smoothly, without errors, and the WG tunnels continue to work as-normal post upgrade.

My overall setup is 2 SOHO networks at different sites, each with a bare-metal OPNsense install on PCengines APU2E4 box, connected to a separate VLAN-capable switch. One site has WAPs running OpenWRT, the other with Unifi firmware. (Running as pure access points, no routing, firewalling, or services on the WAPs.)

One site also has 4 VLANs and 3 different wifi SSIDs associated w/ 3 of the VLANs. Everything seems to continue to work fine.

[squared]

Hook up any system to the legacy (IPv4) Internet and it will instantly be port scanned 24x7. So why care?

We populate our IPv6 address space sparsely. So every customer container gets a random address inside a common /64. That means all the customer containers (FreeBSD jails, actually) share one /64 or the entire legacy (IPv4) Internet squared.

No way to port scan that.

Nice way of conceptualizing that. Hadn't ever occurred to me but it's obvious when you point it out that way. An address space too large to port scan effectively, assuming sparse & reasonably random assignment within it.

[SOLVED]:
The file to investigate & edit is:

Code Select Expand

/usr/local/etc/inc/authgui.inc
Must restart webserver after editing for the changes to appear:

Code Select Expand

/usr/local/etc/rc.restart_webgui

NB: this almost certainly gets written over during major OPNsense upgrades, so be sure to keep backups of any customizations & plan to re-implement them post ugprade.

Where are the file(s) that create the user / password login banner for the web gui? I.e. the landing page when you go to http://192.168.1.1/:80 or  :443 (or whatever the instance's IP address is?)

Since I use SSH -L 9090:localhost:80 tunnels to connect to my various OPNsense instances I don't see the actual hostname or IP address in my browser nav bar. Thus I get easily get confused as to which instance I'm logging in to.

By putting a prominent host identifier right in the web-gui login page I can avoid this confusion.

Are you still experiencing this problem?

I'm having something similar crop up with pf: loose state and pf: bad state messages appearing in /var/log/system/latest.log.

If you're still around & dealing with this, let's compare notes further. Are there any wireless links in the network path between the router & remote device? (In my case the path is  Router --> VLAN-enabled ethernet switch --> WAP (running OpenWRT) --> Mac laptop.)

Already exists? Just add a loopback (Interfaces: Other Types: Loopback) with an (any) address and bind to that in the gui.

Right! Why didn't I think of that?!

A much simpler & cleaner method of going about it. Worst case, there's still direct CLI access via SSH or even the RS232 console.

Appreciate your reply.

EDIT: The solution to this need, helpfully pointed out by @AdSchellevis below, is to just add a new interface & bind it to localhost, then select only that interface for web-gui listening. No need to custom-edit any scripts under the hood, and preserves normal functionality of the web-gui remote access settings.



I'm sure this has been discussed at least a couple times in the forum but I can't find anything via search function --

I have a remotely-administered network environment where I don't trust any network interface, but I require remote web-gui administrative access. Rather than configuring a separate admin-only network interface or firewall rules to control web-gui access, instead I've restricted the web gui (e.g. lighttpd) to listen only on localhost:80.

I then use an SSH tunnel to connect to the Opnsense instance, and from there I can use (for example) http://localhost:9090 to access the Opnsense web-gui. Seems to work just fine, and it completely satisfies my security and convenience requirements. I don't have to worry about misconfigured firewall rules, interfaces going up or down (or being replaced,) or https certificates.

I accomplished this by just commenting out this line in the PHP script which gathers up the available interfaces while producing a lighttpd.conf file:

Code Select Expand

/usr/local/etc/inc/plugins.inc.d/webgui.inc

Code Select Expand

function webgui_configure_do($verbose = false, $interface = '')
{
    global $config;

    $interfaces = [];
    if (!empty($config['system']['webgui']['interfaces'])) {

        /* -----> LOCAL CUSTOMIZATION WILL NOT PERSIST THROUGH FIRMWARE UPGRADES.  */
        /* -----> Web GUI will listen ONLY on Localhost. This effectively allows WebGUI      */
        /* -----> access through an SSH tunnel ONLY.  */

        /* $interfaces = explode(',', $config['system']['webgui']['interfaces']); */

This works fine and persists across reboots. I'm aware that I'll need to manually re-do this work-around after major firmware updates. It's also a bit kludgey in that it breaks the web-gui functionality at System --> Settings --> Administration --> Web GUI --> Listen Interfaces.  (It no longer matters what interfaces are or aren't selected there, the PHP configuration script will only put localhost:80 into the actual lighttpd.conf file, which is what I want.)

I bring all of this up to suggest that there are cases where intermediate-to-advanced network admins might want to configure a localhost-only listener for the web-GUI in a convenient and fully persistent manner through the web-GUI. (Where said config would be included in backups of /conf/config.xml, etc.)

I'd like to encourage the dev team to consider adding "localhost only for web-GUI listener" as an advanced feature, of course with appropriate strong warnings, and with the ability to revert to default "listen on all interfaces" behavior via the usual command-line reset method.

I can also see why devs might say, "yeah, no thanks, it's an edge case & adding it to the main GUI is going to cause more problems with many users than it solves for the few who want it."  In that case, is such a feature something I could fairly easily implement if I wrote it up as an optional Opnsense plugin?

(I've never written a plugin but this might be a good & fairly simple use case to learn to write one.)

One other note regarding using an Opnsense "plugin" to run a Unifi Controller instance ON the same host as the Opnsense firewall --

I respect this guy's efforts to create and maintain such a plugin, but it's clearly an uphill battle. I think at some point he is likely to drop the work involved, leaving those using the plugin without a viable upgrade path:

https://forum.opnsense.org/index.php?topic=36641.0

VM instances just aren't all that resource-intensive, at least for a Unifi Controller that is only managing a <20-30 WAPs. I strongly suggest just spinning up a new VM or Docker container and using a well-supported Linux package-based Unifi Controller setup.

Lukkasss, I read your latest reply a couple of times, carefully, and couldn't get a clear picture of how your overall network is set up.

It sounds like there could be some confusion going on regarding firewalling on bare-metal servers, virtual machines, VM containers, and the Opnsense firewall itself.

If you go back to my earlier posts describing what is required for WAPs to locate and communicate with their Controller, it's not  complicated.

A) the WAPs need to have the correct set-inform host set.

B) There needs to be full 2-way communication permitted, at the network routing & firewall policy levels, between the WAPs and the Unifi Controller.  Both sets of entities need to be able to initiate new connections with eachother on TCP ports 8080 and 5514. WAPs need to make connections to the Controller, and the Controller needs to be able to make connections with the WAPs.


In a complex network environment with lots of zones / subnets and lots of firewall rules, there are a lot of policy decisions that could prevent the requirements of B), above, from being fulfilled. You simply need to hunt down whatever rule(s), policies, network & routing configurations etc. may be interfering with this.

If you can't get it sorted out I suggest dividing up services as much as possible into simple and discrete chunks, e.g. run the Opnsense instance on its own dedicated bare-metal device, or a dedicated virtual machine.

Don't try to use a third-party-developed Unifi Controller "plugin" on top of Opnsense. Just set up a separate VM or Docker container or whatever you want, and then set up a standard, Unifi-developed, Unifi-maintained  linux-package-based Unifi Controller.

I would perhaps approach this by using a separate local bare-metal device, connected directly or through a reliable and otherwise-unloaded GB or 10GB-capable switch, to test Opnsense's max bandwidth. (Using iperf & similar tools.)

You might be able to reproduce the issue with your local test setup, which would rule out anything to do with the ISP.

Or, if you can't reproduce it locally that might tend to point back towards something specific to the Frontier connection.

Do you have a baseline of earlier tests done on the same hardware & same connection, using older versions of OPNsense?

If yes, consider summarizing those tests here.
If no, try using a series of other speed testing providers for comparison. (Fast.com is one example, there are several others.)

It's possible that Frontier provides 'burstable' 900 Mbps downstream but after repeated bursts from a single host or within a certain time-frame they rate-limit your downstream connection temporarily.

One other thing that comes to mind --

You didn't say what kind of host your Unifi Controller is running on, i.e. Mac, Windows, Linux, etc.

If the Unifi Controller host has its own local firewall policies, as many machines do these days, be sure that policy also allows the necessary incoming port 8080 and port 5514 traffic.

In particular, Windows would be most-likely to have default client-side firewall/security policies that might block the necessary ports, but Macs and Linux boxes could also have host-resident local firewall policies set as well.