Topics

1

20.7 Legacy Series / Running as a test system in VM, can't access hosts on LAN?

« on: December 28, 2020, 06:50:04 pm »

I'm running a slightly unusual situation that *should* be easy,and I've installed OPNSense dozens of times, but I'm failing every time on this, and I've run out of ideas what I'm missing.


I want to test some dev things on OPNSense - doesnt really matter what. So I don't need it operational, I just need a bare install with internet and LAN access.  My LAN is IPv4 with a flat desktop switch using 10.0.0.0/9, so I installed using VMWare Workstation and the OPNSense install ISO (set at FreeBSD 12 x64 guest).


After first reboot I set WAN = em0/DHCP and no LAN (which according to the console menu would trigger full firewalling mode). It assigned 0.0.0.0. Fail. DHCP works on every other LAN device, but this wasn't picking up an IP. I checked with TCPDUMP on the main ("real") router and in its logs, I can see ARP who-has and replies, and DHCP discovery/offer as expected. But the VM OPNSense wasn't picking them up.


This isn't to do with name resolution, as it gets "host unreachable/down" even on IP pings.


So I set WAN as a static 10.x.x.x/9 IP, which let me into the Web UI from my desktop. I used the Web UI to create manual rules to pass all IPv4inward (and for avoidance of doubt, outbound) on WAN, then within the web UI, I set WAN to DHCP and disabled RFC1918 blocking (thanks Bart, forgot to mention this first time, just rechecked and it was unchecked) - and it still wasn't able to pick up an IP.

• It's definitely got access from the LAN, so networking is fine - I can reach the web UI.
• I can see DHCPDISCOVER/DHCPOFFER in my main router's DHCP log, and ARP who-has and replies via tcpdump on the LAN
• RFC1918 is unchecked on WAN
• The vm install can't ping anything, including the main router/DHCP server, even though other LAN devices can, and the ARP replies seen via tcpduymp aren't showing in its arp cache (arp -a)

What could be going on?


More generally, whats the simplest way to run OPNSense in a vm and have it able to communicate to the internet?


If needed, the config has no sensitive data and I can attach it. But I'm hoping there is an obvious answer Im missing.

2

Documentation and Translation / Permissions on certificate bundles

« on: August 26, 2020, 02:04:45 am »

The docs just state to set "some sane permissions" on certificate bundles for the internal web server.  Hardly specific.


What permissions are minimally recommended for the internal web server?


Would similar permissions be appropriate for other certs like SSH?


Thanks for answers, and if someone could update the docs with that info it could help others too

3

Development and Code Review / What is this snippet's effect, in the volt template?

« on: November 12, 2019, 02:31:13 am »

In layout_partials/base_dialog.volt, at lines 71-73 and again 104-106, there's a snippet I don't fully understand the implications/intent of. So I'm not sure how best to approach its issues either:
 

Code: [Select]

<table class="table table-striped table-condensed">
    <colgroup>
        <col class="col-md-3"/>
        <col class="col-md-{{ 12-3-msgzone_width|default(5) }}"/>
        <col class="col-md-{{ msgzone_width|default(5) }}"/>
    </colgroup>...  
The function and part of the intent is clear. At the top of the generated form HTML, it divides the standard bootstrap 12 cols into 3 "blocks" comprising { (3)  + (9-msgzone_width) + (msgzone_width) } bootstrap columns respectively. The default of 5 matches the 3-4-5 default values hard coded into base_form.volt. The param is rarely used; clearly from usage and code inspection, the left "Block" is the label for controls, the "message zone" is the right hand column which seems unused, the form controls and their help text fit into the middle "block". That much is clear.
   
What this does however is, give the popup dialogs created from this template, a huge white space margin, and forces the help text to wrap much sooner than it needs to. Attached is a screenshot of how it renders for me. Huge white space, no centring, gets worse as the window size varies. Text wraps poorly making the form long.
 
I'm looking at this and wondering, can something be done to improve this, or is there a functional reason it's set that way? Of course the default can be altered for specific forms, but I'm wondering if it's actuisally got poor choices of zsizing and things. But I don't fully understand the use of the 3rd column and the overall implications and how it fits into OPNsense UI, or the function of col class=.... in this snippet, to know what to make of that. Is this axctually doing what it's intended to, and could it do it better?
 
Insights or suggestions how to work with this (or even minimally modify it), so that dialogs can use a little more of the dialog horizontal whitespace without unforeseen layout issues elsewhere, really appreciated!

4

Development and Code Review / Implementing a better ICMP selector in filter rules

« on: November 06, 2019, 03:16:59 pm »

I'd like to enhance the filter rules page to allow (1) multi-select of ICMP subtypes within a filter rule, and (2) where an ICMP subtype can validly apply to both IPv4 and IPv6, such as echo request/reply, to allow that subtype to be used in rules with protocol = "IPv4+IPv6".
 
The aim is to allow a router admin to avoid pointless and distracting multiplicity of rules whereby several ICMP subtypes must be given in many otherwise-identical rules just because they can't go in one rule, and then *all* of these rules must be repeated a *second* time for both v4 and v6 because ICMP filters can't currently be used within IPv4+IPv6 rules. 
 
I already wrote this code for pfSense a while back, before I moved to OPNSense, so I know it's easy, and the code works.  It's been part of that project for years. But I'm not yet familiar with the way mvc works in the codebase (despite reading the wiki) - sorry, the details within OPNSense is just extremely unfamiliar - so I'd like to check "what will go where" with a view to writing and testing an OPNSense PR for this enhancement.
 
The working code I'm starting with looks like this:

• firewall_rules_edit.php (protocols list): ICMP and ICMP6 are replaced by a single entry "ICMP v4+v6". This is similar to how we have IPv4+IPv6 in the protocol field. (The pf.conf generated by filter.inc still of course contains icmp and icmp6 as needed). There are 2 copies of these tables in the codebase so they can probably be replaced by a single copy in some appropriate file.
   
• firewall_rules_edit.php + firewall_rules_edit.php (tables of ICMP+ICMP6 subtypes):  ICMP subtypes tables for v4+v6 are merged into a single table, which lists all subtypes, with each flagged as "valid for v4? valid for v6?". These tables are only used very few times in the codebase, so consequential changes are trivial.
   
• firewall_rules_edit.php:
  - the merged ICMP subtypes table is used to build a table with 3 subarrays giving the valid data for IPv4, IPv6 and IPv4+6 rules respectively
   
  - if $proto == 'icmp', the validation code checks that the selected ICMP subtypes are all valid for the IPv* selected
   
  - a multi-select rather than dropdown field is used for ICMP subtypes. Its contents+selection are initially populated by Javascript. They are also updated by Javascript, if IPv4/6/46 is changed by the user, to ensure the ICMP subtypes displayed+selected remain compatible.
   
• firewall_rules.php: the "long format" rules table lists all ICMP subtypes selected, whethere one or multiple. The "short format" table just shows the number of subtypes against ICMP rules (e.g: "ICMP (4)" ) which can be hovered/expanded to view the specific list of subtypes.
   
• FilterRule.php (rule generation for rules with protocol=ICMP):
  - As a first step, builds a subtype-string giving the actionable subtypes in pf.conf format. If an ICMP rule contained just one subtype, then this string would look like "subtype". If the rule contained multiple subtypes, the string would look like "{ subtype, subtype, subtype, ...}".
   
  - ICMP and ICMP6 are then handled trivially as part of IPv4 and IPv6 handling. Meaning:  as the code stands, inet46 rules result in two pf rules being created, one for IPv4 and one for IPv6. So for ICMP rules, if the IP type is inet then an "icmp-type [subtype-string]" clause will be generated.  If the IP type is inet6 then an "icmp6-type [subtype-string]" clause will be generated. If the IP type is inet46 then an "icmp-type [subtype-string]" clause will be used in the resulting inet rule and an "icmp6-type [subtype-string]" clause will be used in the resulting inet6 rule.

This all seems pretty simple.  What I'm not clear about is this: 
 
The code I created is 100% PHP with some HTML+JS. I can find equivalent PHP in OPNSense and adapt the existing code to work properly.   That's trivial.  But some of the above, mainly related to the GUI, its fields, and their validation, I'm not at all clear what's required.
 
Can someone kind, please help me a bit, by running through the 8 code bullets above, and let me know which bullets are a matter of finding+editing the equivalent PHP in OPNSense and just need pure PHP code work to bring into OPNSense, and which bullets will require totally reimplementing in OPNSense because they work totally differently (XML/Phalcon/validation/mvc/HTML/JS/??).
 
(And the bigger picture is, I have a number of enhancements I've done, and I want to continbute PRs more actively.  But I feel stalled by this aspect.  Hopefully what I learn from this small port will mean I can PR other useful work I've done, without needing to ask as much.)

5

19.7 Legacy Series / How to fully reset Let's Encrypt ACME plugin for a specific certificate?

« on: November 05, 2019, 07:31:03 pm »

I've been testing the Let's Encrypt ACME plugin in the staging envioronment.

I want to force the plugin to revalidate the DNS ownership, but can't figure how to do it.
I've deleted the private key and revoked the existing certificate in the GUI, I've deleted all the files I dare from /var/etc/acme-client in Console, but whatever I have tried, when I click the GUI button to forcefully (re-)issue the selected certificate, the log contains this:
"<MYDOMAIN.COM> is already verified, skip dns-01"
How do I reset the client so I don't get this, and so it's forced to reverify DNS-01?


 

6

19.7 Legacy Series / Tiny internet-facing service on OPNSense - run in jail, or something else?

« on: October 20, 2019, 05:41:05 pm »

I'm planning to.install a small public-facing service on my OPNSense router (doesn't really matter the details, djbdns and a tiny static-file-only httpd, both pretty much serving static data files only, and a few queries a day). I want to run these on the router itself  because I don't need a second server or VM for such tiny things, and so I'm sure they are up and running any time the router itself is. Other threads on this forum make it look clear that adding jails should be completely workable and not in conflict with OPNSense core/plugins.     

I came across this short thread from 2017 which gives a very clear step by step "recipe" for the exact same goal. So most of my questions have been answered.  I have only 2 crucial questions left before going ahead:   

• Are the instructions from 2017 still appropriate in 2019? Has anything changed? Is there anything else I should do, to ensure security isn't compromised, or cut off non essential system capabilities from within the jail? Is a jail still the right way to go?
• How do I configure the jail IP to be behind the router's own pf firewall, for example to rate limit attackers/spam, or to limit any IPs/networks able to reach the jail?

Any tips on those 2 questions, or other useful info, much appreciated, so I go ahead safely!

7

Development and Code Review / Correct command to reload unbound.conf from an ACME DNS-01 script module

« on: March 01, 2019, 12:05:56 pm »

I'm writing a short add-on for the ACME DNS-01 challenge.

The idea is that if you're using DNS alias/redirect, and a tiny "set and forget" type of domain (like one used just for your family website/email), and your provider doesn't provide an API for DNS record updates (web UI/email only), you could have an ACME challenge setup something like this, and not need to run BIND or anything else, if you're running unbound already as the main resolver.

Since many people could fall into that scenario, it seems a neat DNS-01 module to have, and its relevant to me as I'm squarely in that situation.

It also feels a neat solution from a security perspective, as it doesn't need any key or password, nor any software beyond unbound, since it's all based on local unbound.conf data that's secured by usual Unix permissions, and it doesn't risk exposing anything beyond the few text records, and then only for a few seconds (max 3-5 minutes) once every 2-3 months when DNS-01 is active. Note also, no external DNS provider API is involved or needs to propagate data, so the total start-to-end time for live data to be in the file should be the time taken for Let's Encrypt's queue to perform lookup after being notified of a DNS update, plus a fraction of a second.  The workflow is:

Done manually by the user:

• Create the couple of DNS records with their provider, to redirect _acme_challenge.domain.name to the IP that unbound will listen on, during the DNS-01 challenge.

In the ACME plugin:

• add a directive in unbound.conf, to include "/var/unbound/unbound-dns-01.conf"
• add a suitable one-line system startup script so this exists and is empty at unbound config load
  (these are probably too system specific to be in acme.sh itself and need to be in the acme plugin code or done manually. But they are trivial.)

In a new ACME DNS-01 challenge dnsapi shell module "dns_unbound_direct_access.sh"  (both add and remove parts):

• If Unbound isn't running, error + return (maybe an option to autostart/autostop if this isn't a problem for edge cases)
• before doing anything else, and regardless whether the call was to add or remove TXT records, set a cron job to empty the file of any records for that domain and autostop unbound if autostarted, in some amount of seconds (say 300 seconds). This is a failsafe to ensure the file is emptied and generally serves+contains nothing unless a DNS-01 query is actively in progress, which is only once every 60 - 90 days, even if something fails or exits prematurely within acme plugin or elsewhere, at any point. 
  
• Create /var/unbound/unbound-dns-01.conf which exposes a new custom view. The view is set to "deny_non_local" + "view-first:no" (ie refuses/denies anything except local-data explicitly defined within that view in unbound.conf and subfiles), and also rejects non_WAN IPs. The contents of the file are, obviously, the local-data: DOMAIN TXT 'DATA' records that Unbound should serve for DNS-01, or empty for that domain when no longer needed
• direct Unbound to reload its config (better than restarting service)
• verify that new config was loaded by unbound and exit success

I've got almost all of this prototyped, and working, with one exception, which is the dumbest thing - I can't seem to work out reliably, the best/correct way to reload unbound.conf.

From examining the codebase I've found it uses the old legacy system (.inc files) and I've played with the following commands seen in its scripts, which seem to be relevant:

• ...
  elif [ "${COMMAND}" = "load" -a -f "${CACHE}" ]; then
    cat ${CACHE} | ${UNBOUNDCTL} load_cache
  ...
   
• /usr/sbin/chroot -u unbound -g unbound /
  /usr/local/sbin/unbound-control -c "$unbound_main_conf_file" "$1"  2>&1
  (gets permission denied for port)
   
• /usr/sbin/chroot -u root -g wheel /
  /usr/local/sbin/unbound-control -c "$unbound_main_conf_file" "$1"  2>&1
  (no obvious permissions issue but seems to hang up a lot of the time)

I think the problem is that with unbound-control running in chroot, and potentially being called both from console (for testing) and also from a script run by ACME-plugin (presumably running as privileged user of some kind?), that there are nuances of the command, or the user/group, which I'm not getting right. Help appreciated, and once it's working here, code review time?

8

19.1 Legacy Series / Tearing hair out - packets passing fw but not being received by Unbound

« on: February 26, 2019, 06:01:51 am »

I am at a loss.  Getting a public IP to pass queries to Unbound should be trivially easy. It shouldn't need any customised NAT settings at all (Unbound is listening directly to the WAN), but Unbound never sees the queries. If I use NAT and port forward to localhost:53 instead (where Unbound also listens), Unbound still never sees them. In both cases, the firewall log shows they passed inbound correctly.  Only once they pass PF, they aren't showing up on the Unbound logs or being replied at all.

I've done a ton of debug, its 5 am and I'm still stumped, and honestly, I'm feeling frustrated and at a complete loss why it's not working.


Relevant background:

The router has a block of public IPs - call it 93.94.0.96/29. It's PPPoE so the WAN automatically adopts 93.94.0.97/32 as its IP, but that's okay AFAIK.  I have defined 6 virtual IPs on the WAN, one for each usable public IP address. I need the firewall to do 3 things, beyond any pass/block rules:

• If an unsolicited (new) packet comes in on one of my public IPs and isn't blocked, any outgoing responses have src=the same public IP.
  Example - incoming mail HELO from WAN on 93.94.0.102, response to PING from WAN should have src=93.94.0.102. Kinda obvious
   
  
• If a packet exits via the WAN and it's not a reply to an earlier packet, it always exits on 93.94.0.98.
  Example - outgoing http request from my desktop browser, public src IP should be 93.94.0.98.
     
• Unbound will listen and respond to queries from the WAN, on public IP 93.94.0.100 port 53 (but not other public IPs). Yes there are rules to prevent abuse

My laptop is connected to the external Internet via my Telco (phone->AP hotspot->GSM/LTE), and has been assigned an IP in the range 148.252.0.0/16 for now, which lets me test how my config  is working for external inquiries.

But none of these things is working for me, although they are basic and simple.

Outbound src IPs, trying to do 2nd bullet seems to break 1st bullet

The second bullets should just need outbound NAT with updated src =93.94.0.100. Unfortunately if I enable outbound NAT to achieve it, it *also* sets the src IP for all other egressing packets, including reply packets whose source IPs must remain as expected. I can't seem to get outbound NAT to do the one, without breaking the other.

Filter says it's passing packets to IPs where Unbound says it's listening, but Unbound never sees the packets:

This one really has me tearing out hair. I've tried from basic to esoteric, and can't find a way even to troubleshoot it.

For test purposes, Unbound is configured to accept inquiries from the WAN (both listening on WAN interface, and also specifically allowing access control set at 148.252.0.0/16 = allow.  NAT is manual only with no rules at present. I have these settings:

• In Firewall: Pass 93.94.0.100:53 with logging (log confirms packets are arriving and being passed)
• In Outbound NAT+ Unbound config: Tried unbound listening on 93.94.0.100. Also tried port forwarding 93.94.0.100:53 to 127.0.0.1:53 with associated filter rule, since Unbound is *definitewly* listening on localhost. I've tried outbound Nat (and outbound NONAT) on the public IP, as well + logging. Then tried a ton of options. Checked and logged rules by the dozen, nothing. Tried playing with reply-to, reflection settings, and a bunch of others.

Whatever I do, the firewall logs and tcpdump show the firewall is passing the queries on the IP alias with dst= 93.94.0.100:53 (or dst=127.0.0.1:53 if port forwarding to that IP/port is enabled). This is exactly what should ahppoen, but then.... the Unbound log remains stubbornly empty. It's not that the rewply isn't getting out to the client, or has the wrong IP, it;'s that it simply isn't responding at all, or even logging the query.

I don't know where to go from here.  I'm not seeing a clear reason in the logs or tcpdump, and RTFM + fiddling with settings + tools like logs, dig, tcpdump, even looking at the config directly in /var/unbound and /tmp (for pf),  are all failing to hint what's wrong. PF is plainly allowing incoming packets to either of 93.94.0.100:53 or forwarded to 127.0.0.1:53 if port forwarding is enabled for it. Unbound is listening explicitly to both of those interfaces and clearly allows both according to GUI and /var/unbound/access_control.conf, but when queried, and I have Unbound set up to log all queries and replies as received/sent, but still... Unbound never sees any of these queries even though they are shown as passed to IPs it's listening, in pf logs.
I just don't understand. Whatever I try, unbound log contains nothing and Unbound never responds. I've tried all the obvious things, and moved to esoteric ones, and still Unbound is silent.


What's needed in my config, to get my IPs working as I want? What else can I do, to troubleshoot and resolve these 2 issues?

9

19.1 Legacy Series / I thought I understood mDNS/Airplay, but now having HP dns_sd - how to handle?

« on: February 10, 2019, 05:20:45 pm »

I thought that I understood the way that Apple services, HP printers with Airplay implemented, and other such services worked on a segmented LAN.  The LAN here has a transparent WIFI AP that bridges wireless devices to OPT3, and filter rules on OPT3 allow access to the local resolver (Unbound: it's a small LAN with maybe <12 devices needing a static IP) and the LAN itself.

As I've understood it, devices broadcast requests/discovery announcements to their segment (bridged if needed by mdnsrepeater/avahi), and discover other devices on the LAN that way.  Irritating to have to bridge, but okay, doable.

Just now I hit a completely new thing in the zero-config realm, and I'm trying to understand how to integrate that into my LAN. I tried to use my printer from my mobile phone. The HP print service couldn't find the printer, but I could easily reach its built-in web UI from my phone, so TCP/UDP all work fine between the phone and printer. Intrigued, I ran tcpdump and found the HP Android print server plugin was sending odd DNS requests, which I now know are dns-sd packets, to the local LAN resolver, to try and find presumably statically coded or dynamic discovery records of local services.

The domain's it's looking for(initially at least) are: lb._dns-sd._udp.MY.DOMAIN and b._dns-sd._udp.MY.DOMAIN

This has thrown me on many levels. Please help me work out what to do!

I take a guess that it's piggybacking on (or similar to) Apple Airplay, and HP uses this as a kind of subnet-aware zeroconf autodiscovery, where device details are dumped into DNS TXT strings by local dns-sd aware devices, and DNS can be interrogated for them by service users. That leaves me 3 questions:

• I don't want to have to manually add TXT strings to Unbound any time a new service is offered by a friend's device.  But Unbound is generally read-only on DNS records, once running.  Is there a way to make this dns-sd discovery method work without ditching Unbound as the LAN resolver?  (I've never used Dyn DNS for anything but could use it if it helps)
• The HP print plugin seems to only look for dns-sd records. If it knew the device IPs, would it be able to interrogate them directly, or does it need that middleman DNS service to log them and serve them? Like, is there a way I could tell the HP thing to just add a printer at some IP or another, or is that unlikely to work?
• Should I just use different (non-HP) software? But then, friends with Apple iThings will want to print and share services on the LAN, and print software won't solve it for those. Will a fix for dns-sd combined with some kind of mdnsrepeater, finally fix all common zeroconfig discoveries, or are there others that are popular and I need to handle?

10

19.1 Legacy Series / 1:1 NAT not forwarding - checking what the NAT entry should look like

« on: February 02, 2019, 04:59:33 pm »

I understand the principles and have read various man pages + posts, but I'm still not geting 1:1 NAT working in this scenario.
 
I have two LANs - one trusted (office) and the other untrusted (domestic/family).There's a a single device that unavoidably has to be physically connected via the untrusted network, but needs to behave as if it's connected to the trusted network's subnet.
 
Getting the device to behave as if on the trusted LAN should be easy (virtual IP + 1:1 NAT) but isn't working for me.
 
To make it simple, let's give some hypothetical IPs:

• The "trusted" LAN is on NIC <em0> "OFFICE_NET", which has subnet 10.20.0.5/16, and the "untrusted" LAN is on NIC <em1> "HOUSE_NET", with subnet 10.50.0.5/16.
   
• Devices on HOUSE_NET are all forced onto VLAN 6 by the switches, except for the device I'm trying to fix, which is forced onto VLAN 7.   Filter rules block any traffic at VLAN 6 from reaching VLAN 7.
   
• The device needs to be accessible from OFFICE_LAN via IP 10.20.0.100. (I don't care if it has a different IP locally on VLAN 7).
   
• At the router, I've created VLAN 6+7 and their interfaces for . I've set up rules so that VLAN 6 traffic can't reach VLAN 7. I've assigned VLAN 7 the subnet 10.51.0.5/16, and enabled DHCP on that interface to issue the device with IP 10.51.0.100. I've created a virtual IP for 10.20.0.100 on OFFICE_NET.
   

In theory, all that's left is creating a 1:1 BINAT (symmetrical) entry on OFFICE_NET, so that

• any packets from OFFICE_NET with source in 10.20.0.5/16 and destination 10.20.0.100 that arrive at the router, are NATed to appear as destination=10.51.0.100 and arrive at VLAN 7 where they are forwarded to the device.
   
  and
   
• any packets from VLAN 7 with source 10.51.0.100 and destination in 10.20.0.5/16 that arrive at the router, are NATed to appear as source = 10.20.0.100 and arrive at OFFICE_NET where they are forwarded to their destination. (This is less common but possible, eg ping, syslog, snmp, spanning tree protocols, etc)

But I can't get this to work - meaning, I can ping the virtual IP at 10.20.0.100 from the LAN, and I can access http://10.51.0.100 from the LAN, but I can't access http://10.20.0.100 from the LAN.
 
I'm not sure what I'm doing wrong, or what else might be needed.  It shouldn't have a routing problem, as I can reach the device via its VLAN 7 IP 10.51.0.100. It's just that when I access the virtual IP, whether or not it's NATing it to dest=10.51.0.100, it's not then forwarding it to VLAN 7, as it does when I enter that IP directly.
 

What should I have in my NAT config, to make this last step work?

11

18.7 Legacy Series / Adding kld + loader tunables: sanity check before going ahead

« on: January 31, 2019, 06:31:15 pm »

I've got my monitor working how I want it, with FreeNAS, and it looks like the same settings should work well on OPNSense as the OS is clearly compatible.

Since errors in loader config can be a real problem, I want to sanity check before going ahead, even though reading the forums it looks OK.
I want to load the vt driver and a couple of others, and then set some loader tunables related to them.

• Do I just add them to "tunables", and OPNSense middleware will figure which to apply as loader / rc / sysctl?
• Does the order matter?
• How would I recover if I find I've made a mistake and it won't boot properly, or is the system resilient against user errors in loader/rc tunable entry?

Thanks for any quick answers on this, so I can go ahead. If it works, I'll add it as a request or forum post, so others can benefit too.

12

18.7 Legacy Series / Limiting root login for security - possible?

« on: November 16, 2018, 02:23:17 am »

In case of attempts to brute force a login on a password-secured system, it adds a layer of security for an attacker to have to guess an account name, not just a password. The "root" login name will be a "well known login" for OPNSense. It's possible to create an arbitrary named user in the admin group, that is actually used for console or webUI logins, but I'm stuck there and wondering if more is possible in two areas:

• The root account can still login via web, remote SSH (if enabled) or console. if the sysadmin does not believe that accidental lockout is a problem (e.g., they have a backup config and can happily reinstall), they might want to limit the root account's login to just console, or just some specific method/source IP, or block it completely other than locally as needed for OPNSense's own operations. But I can't find a way to reduce any of the root account's login rights.
   
• Similarly, I can set up other admin accounts, but even allowing login group = "wheel,admins", I can't get my alternative admin to directly login to the opnsense shell. The best I can do is login to csh and then su, which gets me there, but as a member of "admins" shouldn't it gain access to the main opnsense shell as well?
   
• Lastly, I can't find any way to specify which login routes a specific account can use - for example I might want to allow "dailyadmin" (a member of "admins") to use web + SSH from specific IP ranges, but not the system console, or allow root to use local console only as a kind of "emergency user" rarely used if locked out all other ways, that can't login from any remote system.

Can any of these be done? If not, are there good reasons why enhancement in this area would be a bad idea?