Topics

1

General Discussion / [SOLVED] How to customize the OPNsense webgui login banner?

« on: February 20, 2024, 11:57:04 pm »

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

Code: [Select]

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

Code: [Select]

/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.

2

General Discussion / Securing WebGUI access - restrict to localhost:80 only for SSH tunnel use

« on: February 17, 2024, 01:46:15 am »

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]

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

Code: [Select]

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.)

3

General Discussion / opnsense forums themes - please add one or two dark themes

« on: December 08, 2023, 06:14:04 pm »

The various themes available for the forums now are all light & some of them are low-contrast.

Please consider adding a couple of dark themes for the forums.

Thanks.

4

General Discussion / Nothing major, just moved from pfSense to OPNsense. Very satisfied so far.

« on: December 07, 2023, 07:52:54 pm »

Just a "hey, I switched! (from pfsense to opnsense)" post.

Registered for this forum 5+ years ago & asked a couple questions re: hardware compatibility back then. In the intervening 5 years I ended up running pfSenseCE, and then (briefly) pfSense "plus", on my PCengines mini-system.

pfSense worked fine & met all my basic SOHO network/WAN needs but I got tired of the cash creep and very low/laggy cadence of security updates on the community edition. Even the "plus" edition isn't updated anywhere near enough.

Took the plunge last night, crossed my fingers & just booted an OPNsense 23.7 serial image from a USB stick, wiped out my entire pfSense install on the main SATA drive inside the mini-system, clean-installed 23.7 "Restless Roadrunner," selecting config/install options via the serial console port.

Everything went perfectly smoothly, basic 192.168.x.x LAN / DHCP WAN / NAT setup, back up and running & internet / Wifi restored within 15 minutes.

Donated $50 to OPNsense and am relieved to be out from under the weirdness and lack of transparency in the land of pfSense.

5

Hardware and Performance / New user, new hardware - advice sought on Pentium N4200-based setup

« on: November 27, 2018, 10:29:20 pm »

I'd like advice & comment on proposed hardware for a SOHO / single-user OPNsense-based firewall/router. Single user in a home-office setting. I don't have demanding requirements for high WAN throughput or VPN use -- currently only 25MBps ADSL -- but I'd like to future-proof in case gigabit fiber comes to my location sometime in the next 5 to 10 years. My main reason for upgrading to OPNsense is to improve my network security.

I'm looking at using one of these:
 http://www.mitxpc.com/proddetail.php?prod=NML-NF692 --
Intel Pentium N4200  (has AES-NI support)
Jetway NF692G6-420 Thin Mini-ITX Motherboard
4GB RAM
120GB 2.5" SSD (SATA)
6 x Intel GB Ethernet ports

My budget is anywhere from $250-$500 USD.

Do I need to worry about FreeBSD or OPNsense putting excessive wear on the SSD, or are they now optimized to use SSDs without excessive wear (i.e. say from swap files or some such)?

Any other comments or suggestions?