error

Generate an error into the pipeline

error

The error action generates an error that immediately stops pipeline execution. Use it to signal failure conditions or to just test how errors are handled in your configuration. The error message can be a static string or a dynamic expression that evaluates to a string.

Syntax

error <expression>;

The expression is evaluated and its result becomes the error message. It supports format strings with %{...} variable substitution.

Examples

Generate a simple error

error "Something went wrong";

Generate an error with variable substitution

error "Authentication failed for user %{aaa.identity}";

Use with try-catch for error handling

try {
    error "Simulated error";
} catch {
    accept "Caught an error: %{aaa.caught_error}";
}

Fallback with first and try

When combined with first and try, the error action serves as a final fallback when all preceding actions fail:

first {
    try backend "PRIMARY_AUTH";
    try backend "SECONDARY_AUTH";
    error "All authentication backends failed";
}

Mark unreachable code

Place error in a final else branch to catch unexpected execution paths:

if all {
    user.group == "admin";
} then {
    accept;
} else if all {
    user.group == "guest";
} then {
    reject "Guests not allowed";
} else {
    error "Unexpected group: %{user.group}";
}

error vs. reject

While both error and reject stop pipeline execution, they serve different purposes. Use reject to indicate a controlled denial of a request (e.g., authentication failure), while error is meant for unexpected conditions or testing error handling.

Errors are logged and counted in the handler and policy error counters. The protocol-specific behavior differs from reject:

RADIUS: The response is discarded and no reply is sent to the client. This causes the client to retransmit or time out. If reject_errors on is configured, the server sends an Access-Reject instead.
TACACS+: Same as RADIUS - no reply is sent by default, unless reject_errors on is configured.
HTTP: The server responds with HTTP status 500 (Internal Server Error).

In contrast, reject always sends a definitive denial response to the client (e.g., Access-Reject for RADIUS, HTTP 403 for HTTP).