RADIUS and TACACS+ — protocol-level authorisation for the fleet

LDAP is a directory: the firewall looks up operators and their groups. RADIUS and TACACS+ are protocols for authentication and authorisation that often use LDAP (or a similar store) on the back end but add features LDAP alone does not give a firewall: shared secrets per device, accounting records of every command, and protocol-level authorisation policies.

This lesson covers how RADIUS and TACACS+ work at the protocol level, how to configure OPNsense to authenticate against each, how to map protocol attributes to OPNsense roles, and the failure modes that lock operators out.

RADIUS vs TACACS+

RADIUS (Remote Authentication Dial-In User Service, RFC 2865) and TACACS+ (Terminal Access Controller Access-Control System Plus, RFC 8907) are both AAA protocols — authentication, authorisation, accounting. The differences matter for a firewall.

RADIUS encrypts only the password in the Access-Request packet; the username and other attributes are in cleartext over the wire. TACACS+ encrypts the entire TCP payload, so usernames and authorisation attributes are also encrypted.

RADIUS authorisation is typically attribute-based: the server returns attributes (Filter-ID, vendor-specific attributes) that the firewall interprets as role membership. TACACS+ authorisation is command-level: the server can return “permit” or “deny” for specific commands, enabling fine-grained control like “this operator can run pfctl -s rules but not pfctl -f”.

Configuring RADIUS on OPNsense

The RADIUS configuration lives under System → Access → Servers. To add a RADIUS server:

1. Click Add server.
2. Set the Type to RADIUS.
3. Set the Hostname or IP of the RADIUS server.
4. Set the Port (default 1812 for authentication, 1813 for accounting).
5. Set the Shared secret — the pre-shared key between OPNsense and the RADIUS server. Must match the server’s configuration.
6. Set the Authentication port (1812) and Accounting port (1813) if non-default.
7. Optionally configure RADIUS NAS-IP and other NAS attributes for the server’s accounting records.
8. Save and test.

OPNsense sends a RADIUS Access-Request with the operator’s username and password (password encrypted with the shared secret). The RADIUS server responds with Access-Accept (with attributes) or Access-Reject.

$ echo "User-Password=secret" | radtest jdoe secret 127.0.0.1 0 testing123

Sent Access-Request Id 41 from 0.0.0.0:0 to 127.0.0.1:1812 length 73
Received Access-Accept Id 41 from 127.0.0.1:1812 length 32
Filter-Id = "admins"
Reply-Message = "Welcome"

Mapping RADIUS attributes to roles

The RADIUS server returns attributes in the Access-Accept. OPNsense can use these to map operators to groups:

• Filter-Id (attribute 11): the canonical attribute for group membership. The firewall looks up the OPNsense group whose name matches the Filter-Id.
• Class (attribute 25): alternative for group membership.
• Vendor-Specific Attributes (VSAs): vendor-specific attributes (e.g. Cisco, Juniper) for finer-grained mapping.

The mapping is configured under System → Access → Groups → [group] → Member of RADIUS group. When the RADIUS server returns Filter-Id = "admins", the operator is added to the OPNsense admins group with the corresponding privileges.

Configuring TACACS+ on OPNsense

OPNsense supports TACACS+ via the os-tacacs-plus plugin. After installing:

1. Open Services → TACACS Plus.
2. Add a TACACS+ server with hostname/IP, port (default 49), and the shared key.
3. Configure the Service name (typically opnsense) and Protocol (typically ssh).
4. Save and test.

The TACACS+ client sends an Authentication Start packet with the username; the server responds with Authentication Reply asking for the password; the client sends the password; the server responds with Authentication Pass (or Fail). On pass, the server returns authorisation attributes that OPNsense interprets as group membership.

RADIUS and TACACS+ failure modes

The protocol-level failure modes for both:

1. Shared secret mismatch. OPNsense and the server have different shared secrets. RADIUS silently rejects (the Access-Request fails signature verification); TACACS+ fails the encrypted session. Fix: ensure the secrets match; rotate via documented procedure.

2. Server unreachable. Network partition, server down. Fix: configure redundant servers in OPNsense; monitor reachability.

3. Attribute mapping missing. The server returns the correct attribute (e.g. Filter-Id = "admins") but OPNsense has no group named admins configured, or the mapping is wrong. Fix: verify the group mapping under System → Access → Groups.

4. Packet encryption fails. TACACS+ fails to establish the encrypted session. Fix: check shared key, server certificate, network MTU.

5. Authorisation policy too tight. The TACACS+ server’s command authorisation denies the operator’s commands. The operator can authenticate but cannot perform their job. Fix: review the TACACS+ authorisation policy.

Choosing RADIUS vs TACACS+

The choice between RADIUS and TACACS+ is mostly a function of what the existing identity infrastructure already runs. Most production estates have one or the other. The trade-offs:

• RADIUS: broader vendor support, simpler server configuration, weaker encryption. Suitable when the management network is fully trusted and command-level authorisation is not needed.
• TACACS+: stronger encryption, command-level authorisation, more granular accounting. Suitable when the management network is not fully trusted or when command-level policies are required (PCI-DSS, regulated environments).

Both integrate with LDAP (or another directory) on the back end — the protocol is the wire-level concern, the directory is the data-level concern.

Summary

• RADIUS and TACACS+ are AAA protocols for network devices. RADIUS is UDP with partial encryption; TACACS+ is TCP with full encryption and command-level authorisation.
• Configure RADIUS under System → Access → Servers with the shared secret and attribute mapping. Filter-Id maps to OPNsense groups.
• Configure TACACS+ via the os-tacacs-plus plugin. The server returns command authorisation attributes.
• Both have protocol-level failure modes (shared secret mismatch, server unreachable, attribute mapping missing) that lock operators out. Local break-glass accounts remain essential.