Add GUI IP Access Restriction feature

[Codex-v]

Summary

Implement IP-based access control for the web GUI to restrict access to non-whitelisted IP addresses.

Changes

• authgui.inc: Added check_security_ip_acl() enforcement function that validates every request against configured IP whitelist
• system_advanced_admin.php: Added UI configuration page (System > Settings > Administration > IP Access Control) with form inputs, validation, and JavaScript for user experience
• ACL.xml: Registered audit log page to allow non-root users access to view IP restriction events

Features

• ✅ IP whitelist enforcement on every HTTP request (not just login attempts)
• ✅ Support for single IPv4/IPv6 addresses and CIDR subnets
• ✅ Comprehensive audit logging with [GUI-ACL] tagged events
• ✅ Lockout prevention validation on both server and client side
• ✅ Integration with existing Audit log viewer (System > Log Files > Audit)
• ✅ Disabled by default - only blocks when explicitly enabled and configured

Testing

1. Enable feature in System > Settings > Administration > IP Access Control
2. Add 127.0.0.1 to allowed networks and save
3. Access should be granted from 127.0.0.1
4. Test with subnet notation (e.g., 192.168.1.0/24)
5. Test blocked access from non-whitelisted IP - should see "Access denied" page
6. Verify audit log entries appear with [GUI-ACL] prefix

Log Output

• Blocked: [GUI-ACL] BLOCKED access from X.X.X.X (not in whitelist)
• Allowed: [GUI-ACL] ALLOWED access from X.X.X.X (logged once per session)

[AdSchellevis]

just add a firewall rule, optionally with an alias to lock out (or lock-in) only specific networks on the network layer.

[Codex-v]

Thanks for the suggestion! I understand the point about using firewall rules + aliases at the network layer - OPNsense
already has that built-in feature available under Firewall > Rules and Firewall > Aliases.

However, the GUI IP Access Restriction feature I added is complementary and serves a different purpose:

Network Layer (Existing in OPNsense):

• Firewall rules block traffic to the entire device
• Works at packet level

Application Layer (This new feature):

• Blocks access specifically to the web GUI interface
• Works at HTTP request level
• More granular control - users can still access other services
• Audit logging specifically for GUI access attempts
• Easier management for admins who only want to restrict web interface access

Both can be used together for defence in depth:

1. Firewall rules lock down network access (network layer)
2. GUI IP restriction as additional security (application layer)

This gives admins flexibility - they can restrict just the GUI without blocking entire device access.

[Monviech]

core/src/opnsense/mvc/app/models/OPNsense/Auth/Group.xml

Line 30 in 016f66c

<source_networks type="NetworkField">

[AdSchellevis]

@Monviech good point, almost forgot about that one :)

Group access controls are documented in https://docs.opnsense.org/manual/users.html#users-groups-privileges

[Codex-v]

So this feature is not a valid point to add one, as we have other ways to deal with it, right?

[Monviech]

You could also use a reverse proxy (there are a few, OPNWAF https://docs.opnsense.org/vendor/deciso/opnwaf.html for example which is apache based and in our business core product) or caddy, ha-proxy etc, and then use them for e.g. certificate auth or IP address restrictions when reverse proxying the WebGUI.

Inside core, the user group privileges (so API access) can have individual IP access ranges defined, the WebGUI will still show, but you are not allowed to log in. API restrictions are quite common on other platforms as well.

As there is enough flexibility with other available options already, your proposal does not fit in that well.

(Also something like this is way better security wise, nobody can spoof a certificate, source IP restrictions is essentially a bit like smoke and mirrors.)
https://docs.opnsense.org/vendor/deciso/opnwaf.html#protect-a-local-server-with-certificates